David Ko的學習之旅

有些朋友打算開始實施敏捷, 問我說怎樣做會比較好. 老實說, 每家公司背景不同, 我也不是待過各種環境, 沒有所謂的銀製子彈, 可以適用所有地方的. 因此只能提供一堆祕籍(誤) 淺薄的建議:

 

1. 知道為何戰
首先要知道, 你們為什麼要實施 agile, 是因為遭遇到了什麼問題, 然後你打算用什麼方法解決, 最後想達到什麼目標. 需知道只有問題是不變的, 解決方法會因時間或是環境, 有所變化或演進. 千萬不要為了 agile 而 agile.

幾天前遇到一個討論, 讓人印象深刻. 

在 agile 中有個 practice 叫做 continuous integration, 它能幫助你, 及早發現系統整合上的問題, 以及讓你可以保持隨時可以有運行的系統, 或是可以發佈的系統.

身為開發人員的我們, 在列 user story 時, 常常會做出功能拆解的事情, 而不是找出一個 end to end, 對使用者有意義, 可以單獨展示的功能. 

例如高鐵訂票系統. 當你要訂購一張高鐵票時, 你要選擇要定哪一班, 接著填客戶資料, 然後再輸入付款方式.這些都完成後才能買到票.

大家在做估算(estimation)時, 最就要的是要有人跟你討論, 問問看他們對你的結果是不是有意見, 他們可能會想到一些你沒注意的面向, 讓你的估算變得比較準確.

這個道理, 其實已經有很多估算的方法採用. 例如Delphi Method. 便是這個概念的始祖. 但是今天我不是要講這個方法, 如果你對 delphi method 有興趣, 可以去看下面這篇文章, 寫得十分詳細.
http://wiki.mbalib.com/zh-tw/%E5%BE%B7%E5%B0%94%E8%8F%B2%E6%B3%95

我要談的是 playing poker, 敏捷社群常用的一種評估方式. Agile 很多方法並不是新創, 但是常常會把它改的更好玩, 更簡易, playing poker 便是如此. 它也是利用了眾人的智慧, 來評估這些功能需要多時間完成. 因此在使用 playing poker 時, 有幾件事情要特別注意的:

最近在看 David J Anderson 所寫的 Kanban, Successful Evolutionary Change for your Technology Business. 裡面描述到了, 當初 David 為什麼會想提出新的做法, 最主要是他遭遇到了兩個問題

 

1. 如何維持可持續的步調
在敏捷宣言中的原則, 提到了希望可以維持可持續的步調, 在 XP 中的意思, 就是要維持 40 工時. 我想這件事情, 對很多軟體工程師來說, 是很遙不可及. 大家常常要工作的很晚, 無法兼顧家庭與工作. David 希望能有方法, 讓成員不要這麼辛苦.