問誰很重要

June 03 09:43~10:21

▲問Eiffel顯然沒用

 

學習一項新知，如果可以把新知識與舊知識體系建立關聯，不但大幅加速學習過程而且學會之後不容易忘記。但是，這種關聯如果建立在「錯誤的認知」之上，不正確的知識連結不但無助學習，還會讓學習者誤用新知而不自知。

〈鄉民的Scrum〉所提到的現象就是典型將Waterfall與傳統專案管理的舊知識錯誤套用在Scrum的結果，所以導致：

「16個人一起開sprint planning meeting，經常開個2~3天，其中光是估工時就花了兩天。應該在15分鐘內結束的Daily Scrum卻花了40分鐘，因此進公司一小時後才可以開始工作。原本估算一天8個小時要作的事，實際只7小時可用。」

***

這種例子非常多，像是〈沒有文件〉所提到的狀況，團隊成員還是習慣於用傳統的書面文件做為紀錄與溝通的媒介。

昨天在北科上課的時候，學生提到希望能夠製作sprint planning會議紀錄文件，一方面可以讓與會者（PO和開發團隊）確定當次討論內容，另一方面也可以讓無法參加會議者有資料可參考。Teddy告訴學生：「你這是傳統Waterfall用文件溝通的想法。」學生反問：「製作會議紀錄有什麼不對？難道敏捷開發就不用寫文件嗎？」

「難道敏捷開發就不用寫文件嗎？」這個問題很好，也很常見。敏捷開發當然可以寫文件，問題是鄉民們知道敏捷開發怎麼「寫文件嗎？」很多人或許不知道，也或許知道但當下卻沒想到，而又回到Waterfall的老習慣上。要確認PO與開發團隊對於需求的共識，首先，必須要參加會議，而不是不參加會議卻想依靠「書面溝通」來獲得知識。其次，藉由撰寫user story的「驗收測試」可以讓PO與開發團隊對於需求達到一定程度的共識。更棒的是，驗收測試自動化之後可以放在持續整合系統上重複驗證。

敏捷開發看似簡單，但並不是把Waterfall直接切成若干個iteration或sprint就搞定了。專案不一定要採用敏捷開發，但如果想用，遇到問題要優先詢問：「這個問題在敏捷開發中要怎麼處理？」而不是回頭找老朋友Waterfall。

***

友藏內心獨白：誤以為正在做也許比不做更可怕。