估的準，因為我加班？！

Nov. 025 10:02~10:50

 

有人問Teddy關於Scrum的問題…

有人：我們在估算story point的時候遇到很多問題。

Teddy：什麼問題？

有人：因為團隊成員經驗不足，所以story point估不准。

Teddy：何謂估不准？

有人：就是預估得太樂觀，story會做不完。

Teddy：然後哩？

有人：然後大家只好「主動加班」把story做完，以便在sprint review的時候可以demo這些原本預計要完成的story。

Teddy：為什麼要加班完成所有story？

有人：如果沒做完，團隊成員會覺得自己「辦事不力」，可能會被主管拿出來檢討。應該說，大家「責任心太重了」。

Teddy：嗯，很特別的觀點。所以…你說你們在採行Scrum？

有人：對啊。

***

上述「有人」跟Teddy對話的情境，剛好讓Teddy想到另外一個案例。有位主管告訴Teddy，他想到一個「考核」員工有沒有認真實施Scrum的方法：「只要連續兩個sprint沒有完成所有預估的story，這個團隊就要解散。」這種規定讓Teddy想到以前很多台灣的大專院校都有著「連續兩學期被當學分達1/2就要勒令退學」的規定一樣，拿來套用在Scrum團隊上面，真的是太有創意了。

有創意歸有創意，但這樣行得通嗎，有辦法解決所謂的「估不準」的問題嗎？

談到「估不準」，要先判斷一下，「估不準」到底是一個「問題」，還是一個「症狀」。Teddy認為「估不準」只是一個症狀，隱藏在此現象背後的問題，可能是：

• PO根本沒來參加sprint planning meeting，或是沒有充分準備好story就來參加會議。因此，無法當場解答團隊成員對於需求的疑問。
• 在估算的時候團隊成員根本沒有溝通，出牌變成一種形式，大家只想趕快結束sprint planning meeting。
• 估算過於樂觀，低估了風險與不確定性。
• 團隊的領域或技術能力不足，但卻又沒人願意承認這個事實，大家都假裝沒有問題，不願意向團隊成員求助。
• Sprint進行中團隊成員遇到需求的問題找不到PO可以詢問。
• 工作環境太差，過於吵雜、電腦太慢、螢幕太小、測試設備嚴重不足。
• 敏捷開發實務做法沒有做到位，例如根本沒有撰寫單元測試，也沒有實施持續整合。
• 跨部門溝通難如登天。
• 團隊根本沒有訂定DoD（Definition of Done），所以團隊成員不知道到底怎樣才算「做完」。
• 在sprint進行中，團隊成員一直被中斷，難得有完整的時間可以用在開發上面。
• 其他另外100種理由…

***

Teddy認為，估算的目的主要在於凝聚共識，儘量消除團隊成員腦袋裡的眾多的「問號」，讓團隊成員知道接下來一個sprint要做什麼（what）以及要怎麼做（how）。既然是「估算」，和最後的「實際狀況」多少一定都有誤差。如果一開始導入Scrum就不想去面對這些「誤差」，而是一味的粉飾太平，假裝「估算=實際」，如此一來就失去了改善的機會，只是穿上Scrum外套但骨子裡還是用傳統方式來進行軟體開發的活動。

關於估算的問題，也可以參考〈這是電腦估的喔〉這一篇。

***

友藏內心獨白：一種Scrum，百種解讀。