Scrum 是什麼（14）：好問題

February 11 10:08~11:36

 

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
• 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
• 〈Scrum 是什麼（7）：Daily Scrum〉
• 〈Scrum 是什麼（8）：Sprint Review Meeting〉
• 〈Scrum 是什麼（9）：Retrospective Meeting〉
• 〈Scrum 是什麼（10）：時程估算〉
• 〈Scrum 是什麼（11）：不信邪之流程改善精神〉
• 〈Scrum 是什麼（12）：不要再用focus factor與unplanned items了〉
• 〈Scrum 是什麼（13）：為什麼不建議使用focus factor？〉

 

昨天有一位鄉民在部落格上留言問Teddy一個關於採行Scrum（廣義的說應該是敏捷方法）的大問題，由於這個問題很具代表性，有心想要採行Scrum的團隊應該都會遇到類似的問題，所以特別 蓋一樓 寫一篇來回答。以下是鄉民的留言：

***

您好:

可以請教個關於scrum的實務問題嗎?
因為其進行方式是由列出story
然後就按照重要性
分解出task進行開發
且成員的安排也強調無分析師、架構師

那麼是否就完全不需要全面性的系統分析、系統設計的階段？
關於物件或Table都是有人需要就新增？

如此在分工進行下
不會造成相同或相近的東西重複出現嗎？

雖然知道觀念上有持續整合與重構
但還是好奇每個人在開發一個功能時
怎麼能知道是否要共用、修改現有的物件或table
還是另外增加一個？

因為是嘗試敏捷式開發的新手
觀念上若有誤，還請提供一點思考方向

謝謝

***

在回答之前Teddy先聲明一下以下的回答是Teddy個人的經驗，並不保證和Scrum或是其他敏捷方法書本中所建議的方法完全一致（先撇清一下責任…XD）。

Q：那麼是否就完全不需要全面性的系統分析、系統設計的階段？

A：當一個新的專案開始的時候，基本上還是需要花「相對來講」比較多一點的時間在做所謂的系統分析、系統設計的工作，但是儘量要避免變成傳統waterfall所謂的「全面性的系統分析、系統設計（big up-front design）」。這樣講可能還是太抽象了，因為依據傳統的作法，專案一開始如果沒有花時間「徹底的」做需求分析與軟體架構設計，那等專案開始之後在去改需求或是架構所付出的成本是很高的。這個問題Teddy在之前部落格的文章中有提過，請參考「〈萬事起頭難：如何開始第一個 Sprint？〉、〈Iteration 0 要幹麼？〉、〈你的軟體架構有多軟〉看看能不能解答鄉民們的疑惑。

***

Q：關於物件或Table都是有人需要就新增？

A：這個問題的答案基本上Yes，有需要就新增。Teddy很少遇到developer跑來問Teddy說；「我可不可以新增某某物件？」這樣的問題，通常會遇到的問題比較類似「這個問題套個XXX pattern合不合適？」或是「這個物件我這樣設計好不好？」。換句話說，developer大部分的情況都是自己有了一個想法之後，如果需要找人 背書 確認，才會 跑 走過來找Teddy討論。如果某個工作是採用pair programming的方式施工，那麼很多時候developers自己就可以把問題搞定，不需要動用到Teddy…XD。

但是資料庫的table就需要小心謹慎一點（因為改table比改code要麻煩啊…XD）。假設在某個sprint中的某個story所實作的功能需要動到資料庫，那麼在sprint planning meeting時，這個story就會有一個設計database schema的task。認領這個task的developer要先設計出第一個版本出來。如果是設計一個或多個全新的tables，那麼設計好第一個版本之後，這個developer會再找其他人幫他看一下設個設計有沒有問題，有時候甚至整個team需要開個會，花1-2小時的時間來一起確認這些新的schema有沒有問題。

***

Q：如此在分工進行下，不會造成相同或相近的東西重複出現嗎？

A：會，而且機率還可能不低…Orz。

***

Q：每個人在開發一個功能時，怎麼能知道是否要共用、修改現有的物件或table還是另外增加一個？

A：在sprint planning meeting估算story點數與task時數的時候，從每一個developers所出的牌就可以相當程度的解決這個問題。假設有一個developer對於某個task出了13點，另一個出了5點，經過討論之後，原來要完成這個task的某些工作已經有共用的物件可以用，所以就不需要花那麼多的時間去施工。關於資料庫表格的新增或是修改也是經由估算點數的活動來達到溝通與「情報交換」的目的。

當然光是靠sprint planning meeting的互動還是不夠的，因為有很多細節是要等真正coding開始的時候問題才會浮現出來。所以像是持續的pair programming與朝向shared code的目標努力就顯得很重要。請參考「Teddy的Pair Programming之旅」、「Pair Programming 成本太高，嗎？」、「Pair Programming 沒人性？」、「Shared Code：讓我們變成博格人吧」。

這樣就沒事了嗎？當然不可能，還是會遭遇相同或相近的東西重複出現的問題，此時就只能靠最後的法寶：

• Developer要養成做新功能的時候如果懷疑所需要的物件或是table是否已經存在，就快速問一下其他team members。
• 當發現有重複的物件或資料時，安排時間實施refactoring（可在retrospective meeting中提出）把重複的東西合併（當然一定要有自動化測試做起refactoring才不會心虛）。
• 定期安排refactoring或code review的活動來改善軟體設計（改善程式碼的品質）。

***

寫到這邊不免又想起之前寫過的幾篇文章：「Scrum 是一種制度」、「傻的願意相信」、「Scrum 不會幫你解決問題」、「Scrum 不會幫你解決問題（2）」，還沒看過的鄉民趕快去看一下吧。

***

下一集：〈Scrum 是什麼（15）：誰適合當Scrum Master？〉

***

友藏內心獨白：肯問問題就是好現象。