功能做不完怎麼辦？

Feb. 07 13:31~14:46

前兩天在《這是電腦估的喔》Teddy提到現在大部分的軟體專案管理方式，老闆與專案經理關心的課題在於「預估工時必須等於實際完成工時」。在這個大前提之下，管理階層大可放心採用「黑箱管理模式」，把開發團隊看成一個黑箱子，只要盯緊「輸入」（誰做什麼工作與預估工時）和「輸出」（預估時間到了東西看起來有做出來），不必在乎團隊內部的運作方法，也不管開發流程是否遭遇阻礙、人員素質是否能夠應付被分派的工作。

***

路人甲：好啦，就算我相信Scrum是比較好的軟體開發方法，但是依據Scrum對於釋出時程規劃的精神，如果釋出時間到了尚有做不完的需求，就要把這些需求移到下個版本，這種時程規劃方法很難說服管理階層採納耶。

Teddy：「時程到了將做不完的需求移到下個版本」這只是最後一道防線，並不表示專案進行的過程中，團隊成員矇著眼睛不管時程延後的問題，在最後產品釋出之前反射性地把做不完的功能移到下一個版本就沒事了。

路人甲：不太理解，除了把做不完的需求移到下個版本，難道還有其他方法？

Teddy：請看下圖…

在Scrum框架之下，每個sprint planning meeting結束之後，團隊會得到一個estimated velocity（EV），也就是這個sprint預計可完成多少sprint point。在sprint結束時，團隊會知道實際上這個sprint完成多少個sprint point，也就是actual velocity（AV）。這個actual velocity就是團隊真正的開發速度，當我們問「團隊的velocity是多少」，指的就是actual velocity。

在產品釋出之前，團隊會經過若干的sprint。假設產品在半年後要釋出，sprint長度為兩週，則團隊至少有12個sprint從事開發活動。在每一個sprint結束之後，團隊若是發現EV不等於AV，則在自省會議中（或是Daily Scrum），團隊可以提出遭遇到的阻礙，檢討原因以求改善之道。例如：

• 這個sprint我們花在debug的時間太多了，導致原本安排的story做不完。
• 每次建構（build）一次產品都要花3個小時以上，萬一建構失敗要重做一次，很浪費時間。
• 測試的機器太少了，大家程式寫好後要排隊等測試機，開發自然快不起來。
• 我們寫的測試案例好像都沒有發揮作用，一些很明顯的bug都沒找出來。
• 手動測試花掉我們太多時間了，但是不測又不放心。
• 硬體部門答應要給我們的機器一直沒有送過來，導致和硬體相關的story都無法開工。

***

Teddy認為Scrum的回饋機制提屬於「白箱管理模式」，讓團隊與組織可以定期檢視開發流程與人力素質所遭遇到的困難與阻礙。只要團隊開發能力能夠持續改善，假以時日則EV與AV的差距可以逐漸縮小，小到：

• 這個差距可以被專案的buffer或是slack給彌補。換句話說，可以在預估的時程內不加班且有品質做完預估的工作。
• 在多重防護機制之下（sprint planning、daily scrum、sprint review、retrospective、product backlog refinement、buffer、slack），如果時程到了還有尚未完成的需求，只要Product Owner隨時都有注意product backlog裡面的需求有依照優先順序排列，而且每次sprint施工所選出來的需求都是優先順序比較高的，至少可以確保未完成的需求的重要性都是比較低的，已完成的功能還是有足夠吸引人的賣點可以準時上市。這年頭，time-to-market還是很重要的。

***

友藏內心獨白：假以時日是需要多久啊 ？