敏捷小班～估不估計是學問

11th鐵人賽鐵人賽敏捷開發 agile scrum

文思不藏私

2019-09-17 00:19:58

1509 瀏覽

分享至

也許你會聽過『敏捷不需要估計』？也許你也聽過『敏捷也需要估計』？但是其實『估不估計』都是學問。

先下個結論

估計不是為了精準，估計也不是為了承諾。
估計是為了學習，估計是為了溝通，估計是為了理解，估計是為了共識。
估計不是結果導向，估計是過程導向。
估計不是一種目的，估計是一種手段。

估計的好與不好

先來說個小故事，某一天剛加入團隊的新人（New）問我『為什麼我們的開發團隊在 Sprint Planning 時都沒有進行估計呢？』

以下用 N 代表新人、V 代表 Vince

V：『你過去的經驗，有估計嗎？用什麼方法估計呢？當時團隊的組成有誰呢？』
N：『有啊！我們有在 Sprint Planning 時會估計，用 Scrum 的 Planning Poker 作估計，我們團隊組成有一位 Android, 一位 iOS, 兩位 Backend, 一位 PM，我們五位一起估計』
V：『聽起來很不錯啊！當時估計的過程你有什麼發現嗎？』
N：『我們希望估計能準確，但卻一直不準』
V：『不準的原因是？』
N：『Android, iOS, Backend, PM 專業不一樣，很難理解對方正在做的細節，當事人也不想學對方的專業，造成估計都只是亂估的。』
V：『首先，估計比較合適的時機是衝刺精煉會議，團隊透過討論充分的了解需求的範圍，然後透過估計確認是否夠小、夠明確可以帶到下一個衝刺進行。』
V：『其次估計的目的，不是為了準確，而是為了溝通理解、討論交流，讓不熟悉的夥伴了解還不知道的技術細節，幫助團隊產生共識，這是一種促進學習的手段。』
V：『再者，估計準不準確不該成為團隊的壓力，而是一種對衝刺的自我期待，每日站會的訊息同步就該提早讓團隊了解有些工作項目可能無法在這次衝刺如期完成。』
V：『因為我們團隊的組成包含了 Android, iOS, Web, Backend, Designer, PM，我期望大家對於需求本身有充分的討論與理解，至於估不估計就不是那麼重要。但是如果 Android 小組願意對技術細節進行估計，我也樂觀其成。我希望團隊對最優先的工作項目先討論，而不是一次將所有的工作項目都一次討論完，然後把所有的人花兩小時綁在同一個會議中。』
V：『我個人的想法是 Story 層級可估可不估，但切成 Task 後可以刻意練習的估計預期工時一下，雖然下一次不一定會遇到相同的 task，但是估計的過程也是幫忙自己理解自己對 task 了解程度的一種方式。』

因此，我認爲

好的估計：充分理解需求的估計、自我期許的估計、團隊參與的估計、幫助跨職能的估計、允許模糊的估計、沒有外部壓力的估計。
不好的估計：沒意義的估計、造成壓力的估計、沒有參與感的估計、無法跨職能的估計、過度精準的估計、外部壓力強迫的估計。
有目的的估計：為了開發時程安排、為了幫助客戶了解風險、為了促進團隊溝通、為了充分理解需求達到共識、為了有效運用資源。

不估計的好與不好

N：『所以你不喜歡估計，對吧？』
V：『並不是，我不喜歡沒目的性的估計，也就是說估計只是一種形式上的作法，但是團隊彼此間對彼此的工作沒興趣，團隊間的功能也無法互相備援時，估計就是一種浪費。如果團隊成員願意透過估計來幫助了解，我就很贊成。』
V：『我喜歡的方式是 #不估計，所謂的 #不估計，並不是完全不估計，而是盡可能將不清晰的需求釐清完整，把過大的需求切分到夠小，不僅僅讓工作項目能在一個衝刺內完成，如果可以讓工作項目小到可以在每天都能 Commit 到測試環境，就是夠小的工作項目。』
V：『我相信團隊的成員對工作都是全力以赴的，如果估計後某一個工作項目需要開發五天，我相信就算不估計開發時程也是依然是五天。何必要浪費兩小時進行估計呢？除非不估計需要五天，但估計後可以減少到四天，但這問題並不是估計不估計啊？而是對需求沒有充分理解或者對本身的專業技能或技術細節的不熟悉啊！』
V：『我也不建議一直有估計的團隊，聽到了 #NoEstimates 就啟動了不估計。如果估計是有價值的，就不該輕易放棄。反之，如果不估計對團隊也沒什麼不好，不仿嘗試一下吧！每個團隊的成熟度不盡相同，每個團隊對估計想獲得的價值也不一定相同，找到適合自己團隊的做法可能比較重要。』

因此，我認爲