發表文章

目前顯示的是 2017的文章

2017 agile tour 高雄 心得

圖片
今天參加了 agile tour 高雄 ,這也是高雄第一次加入 agile tour 的行列,簡單分享一下心得跟投影片~

2017-devops-taiwan-x-agile-kaohsiung-心得

寫在這裡了: https://hackmd.io/s/rJAdUY8O-

怎麼讓工程師們願意學習?

圖片
這是我覺得很重要的問題,因為我覺得太多人選擇蹲在自己的舒適圈了,還有太多人擠進了相對穩定的公司,每天就是日復一日,年復一年的做重複的事,變成了 IT 業界的公務員。當新創事業的工程師是拿命在拼,那些穩定的公司的工程師卻是佔好了位置,準備養老。 我覺得這很糟糕,當我們在抱怨台灣低薪、不尊重專業、不懂軟體的時候,我們的軟體工程師又拿出了什麼態度、什麼專業來交換呢?

Automation tests 6 — conclusion

圖片
我花了大概一年吧,在眾多不同語言不同平台的 automation solution 中,選了 cucumber 系列,然後,用OO 的概念,把整個架構架了起來。 其實就是這張圖: 因為我們有三個平台要弄,而這些平台的操作是很類似的,所以我希望能 reuse 越多越好。 如同圖中所示,Gherkins 語法可以完全共用、step_definition 可以部分共用、page_definition 可以完全共用,其他就必須依照各平台的 driver 與 framework 去實作各自的 page_objects 了。 然後,我們把下面的各個 page object 做好後,就可以使用一些 design pattern 去自動產生要測試的組合;甚至我們可以再去進行優化,讓 feature 檔是可以由程式產生的,讓 simulator 不要一直重開等等,但那就比較機密,不方便說了。 做了這麼久,其實我覺得自動化測試或許由 programmer 來寫會比較好,因為現在個平台都有各自平台的自己的自動化測試的解法與框架了,甚至,使用的語言會是跟 production code 一樣的,所以由 programmer 來寫,會又快又好。但是一般而言,通常 programmer 都在努力的衝刺 production code,不太有時間寫自動化測試,所以由 QA 人員來寫,好像是一種不得不的做法。 然後,在 page_definition 的那邊,好像不應該用 module 來實作,這邊我做得不好,讓整個程式看起來很沒有魯味 ( ruby 的味道 ),一看就知道是個 java 的人寫出來的... 0rz 但,自動化測試很好玩 :) 謝謝 Joseph, Jackson 跟 柴叔 教我自動化測試,我也的確把它用出來了。或許還有可以做得更好的地方,但我盡力了就是。 還有就是,我只是把這個架構的骨頭立起來,很多人幫我填了肉進去,在這邊也要謝謝 Jason, Tony, Peter, Regina, River,希望我們在各自的工作崗位上各自加油,都一定會有很不錯的發展的。 繼續加油!

Automation tests 5 — Code Architecture 之三

圖片
再承上,來講這張圖的最下面

Automation tests 5 — Code Architecture 之二

圖片
承上,繼續來講這張圖的中間:

Automation tests 5 — Code Architecture 之一

圖片
以下從上到下介紹:

Automation tests 4 — run

圖片
那要怎麼跑起來咧?

Automation tests 3 — installations

圖片
當然,先把東西裝一裝吧...

Automation tests 2 — Choose Framework

其實 automation tests 就是寫程式去測試程式,而目前做 automation tests 的框架有很多,搭配的語言也不一樣,比如說: cucumber cucumber-JVM SpecFlow Capybara Fit Fitness selendroid Robotium UIAutomation 最後我們選擇的是 cucumber 系列。他的好處是:泛用、無腦,乍看之下他不是程式。

敏捷小筆記

圖片
1. 把開發團隊視為是一個運動團隊,比如說籃球隊,這樣一來主管就不會想要去 micro-manage 每個人了。 你無法規定控球後衛要運幾下球過前場,然後在哪個位置傳給哪個人,等等。 2. 這世上已經沒有標準答案了,只有好的答案跟爛的答案,但大家都不希望你給出爛的答案,所以這世上只剩下好的跟更好的答案了。 3. 人不是一味的變強就好,還要有選擇。但要對做出的選擇負責任。 4. programming is about thinking, not typing. 所以要邊寫邊想,不可能先寫好 spec,然後大家照著 spec 打字。

Automation tests 1 — Why Automation

一開始,先用一點篇幅來聊聊,為什麼要做 automation tests。 一般導入自動化測試,無非有以下幾點原因: 把重複性的動作自動執行 把需要人工輸入的動作自動執行 以較低的成本做 regression tests 以較低的成本做壓力測試 但這樣就... 沒什麼了不起。

敏捷小筆記

圖片
1. 把開發團隊視為是一個運動團隊,比如說籃球隊,這樣一來主管就不會想要去 micro-manage 每個人了。 你無法規定控球後衛要運幾下球過前場,然後在哪個位置傳給哪個人,等等。 2. 這世上已經沒有標準答案了,只有好的答案跟爛的答案,但大家都不希望你給出爛的答案,所以這世上只剩下好的跟更好的答案了。 3. 人不是一味的變強就好,還要有選擇。但要對做出的選擇負責任。 4. programming is about thinking, typing. 所以要邊寫邊想,不可能先寫好 spec,然後大家照著 spec 打字。 5. Games: spec game, 4 格 game. 6. Product 與 project 不同,Product 的定義決定了開發團隊的組成。

[翻譯] Questioning if Agile Works in Asia

隨手翻翻,有錯的話... 那就有錯吧,趕快跟我說,我自己好好 retrospective 一下~ 原文來自 InfoQ https://www.infoq.com/news/2016/06/agile-asia# 翻譯已得到作者 Savita Pahuja 及 InfoQ Community Manager Rozana Bacila 同意及授權 =======================================

聊聊 scrum master 帶團隊的階段 (下)

圖片
當團隊自己慢慢有互信了、有節奏了、會互相提醒了,我們就可以慢慢把注意力從團隊身上分一些出來了。 那分去哪裡呢?

聊聊 scrum master 帶團隊的階段 (上)

其實 scrum master 是個很有趣的職位,比如說: 他不能管人 (不打任何人的考績) 他要移除團隊遇到的障礙 他要幫助團隊成長 他要保持中立 其實這些事情,是跟傳統的公司的重視的價值相反的。 我自己也當了幾年的 scrum master 了,大部分都是剛開始敏捷的團隊,我覺得面對到這種團隊與組織架構的 scrum master,應該具備以下心態:(假設你已經排除萬難,組合出一個 cross functional team 了)

敏捷式計畫旅遊(or蜜月)

圖片
簡單一句話:Don’t do that. 不要用敏捷來計劃你的旅遊或蜜月。

[敏捷內湖] Agile UX interaction

圖片
在內湖敏捷的第四次活動,我公器私用的請到了 Jerromy 來分享 UX、UI 跟工程實踐上的態度。 Jerromy 很厲害,2005 年 (好像吧?) 自幹出我覺得很像是 PS 二代的等級的遊戲,然後又用數位與程式的技巧在各個藝術展裡面展出人機互動的作品,現在在 App 上,不管是 iOS、Android 都很有自己的想法與實作經驗。 時間市集:http://timemart.friday.tw/home/

怕失敗,怎麼會成功...?

今天在公司樓下,被母企業的一個朋友攔住,問我最近有沒有機會去幫忙他的專案導入 scrum。 聊了大概 10 分鐘,大略知道了他們的人數、專案類型、目前遇到的困難跟多久 release 一次,我就跟他說,假如我去的話,一定是天翻地覆,把現在的 SA、SD、 release manager 全部打散變成 scrum team 裡面的一個 member,然後一開始幾個 sprint 應該是會很不順,會失敗,之後就會很順了。 他就說,可是我們這個東西是不能失敗的啊,假如是新的 service,那或許可以這樣玩,可是我們目前是已經上線的東西,是不能出差錯的... 等等。 我就覺得很可惜,很多團隊總是讓 PM 或是工程人員的 SA、SD 或是 release manager 在保護著團隊、保護著專案,看似很安全,不容易失敗,但就是大家做得很辛苦啊。因為當然這個專案最強最強,就跟以上的這一排人其中一位一樣強而已,而這還是上限,就是所有成員不玩政治、不搞小圈圈、溝通都沒有掉球的前提之下,也就是說,這 20 個人在最好的狀況下,變成了一個人,你讓一個人去面對 20 個人的那麼大的專案,他當然做得很辛苦啊!而且 20 個人怎麼可能不玩政治、不搞小圈圈、溝通都沒有掉球? 這樣怎麼會發生好的化學作用呢,怎麼可能團隊大於個人呢,怎麼可能三個臭皮匠勝過一個諸葛亮呢?更何況,我們一起面對現實,摸著良心講,你的團隊內根本沒有諸葛亮,真正的諸葛亮都去 google、臉書或是其他大公司了,假如你覺得你的團隊內有諸葛亮,那可能要再想想喔... 所以啊,不讓團隊失敗,團隊就找不到節奏。不讓團隊失敗,團隊就不知道怎麼成功,只能傻傻的跟著管理者走。靠杯的是,管理者也不知道怎麼成功。 所以,怎麼辦? 要來失敗一下嗎?

228 連假上課與敏捷啤酒 party 心得

因為70年前的一件慘事,讓我們有了這四天的連假。 第一天,我下午練了 TDD,晚上去呂毅老師的分享會。 第二天,聽了一個故事。 第三天,去看了金剛狼本人跟電影。 第四天,去CSM與CSPO的 after party。 除了第三天的 Hugh Jackman 之外,我覺得都有記錄一下的必要。

[假如你在台灣的企業] 什麼時候導入 agile 比較容易成功?

我換過很多工作,其中一段時間我在外商待過,對當時的我來說,那是一間敏捷的公司 (雖然現在看起來他們也不太敏捷),那時候我覺得很快樂,後來離開了以後,陸陸續續換了幾間公司,有愉快的有不舒服的。總之,可以說我從來沒有直接加入過一個敏捷的團隊,我好像沒那麼幸運。我都一直在傳統的台灣公司中,試圖推動敏捷轉型,我不是敏捷顧問,我也沒有顯赫的戰功,也沒有很多經驗,所以我撞了很多壁,犯了很多錯,今天突然心血來潮,來跟大家分享一下我自己的看法,大家參考參考。