Scrum - 務實的彈性，千萬不要削足適履

夫所以養而害所養，譬猶削足而適履，殺頭而便冠 ......除小害而致大賊，欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單，能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。

形式主義的削足適履

某些形式主義分子在執行Scrum上，會嚴守大部份framework的要求：每日站立會議，燃盡圖更新，user story和PM確認...等等。達成基本要素，似乎就是必要的事。

但是實際檢視其內容，偶爾會有怪異之處，而這些怪異之處，總是自然生出個理由：「因為我們team比較不一樣，所以有不同作法」。但其實以軟體開發來說，每個team統統都不一樣，而是否能有不同的做法，乃是看有沒有掌握agile的精神而定，而非把不一樣當作理由。

常見的怪異之處有：

* 每日會議除了堅持站著開之外，其他完全不堅持，會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後，仍然無法得知專案團隊的速度，因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目，但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實，因為「要Scrum」而做出怪異的行為，還不如乾脆不要使用Scrum作為開發方法論。

務實彈性的例子：以功能為sprint

sprint的基本精神在於每個sprint之後，都會產生可「交付」的結果。一般情況而言，專案的每個sprint時間長度是固定的，以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版，功能趨於穩定，未來的挑戰，其實在於更快速正確的回應市場變化，則其實可以將time-boxed改為feature-boxed。

上圖取自：http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說，每個sprint的開始，由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個，不多也不少。接下來的流程，和一般的Scrum相同，break down開發細項之後，由專案成員評估時間。

略有不同的地方在於，評估確切完成時間之後，就是這個sprint需要的時間。因此，可能是2週，也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成，決定是5週，之後就和一般Scrum一樣，在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場，看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」，可能會花2週，也可能會耗時8週。

對於已經成熟軟體產品，這樣調整的最大好處是，快速取得市場反應，而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬，畢竟，如果幾個sprint都交付了產品經理認定的最最最高優先項目，而是市場反應卻不怎麼好，那麼產品擁有者當然要負起責任，花更多的精神來瞭解市場，並且將市場需求轉化為適當的user story。


每一種務實的調整，都有其優點和缺點。

「以功能為sprint」的例子中，最大的缺點在於，稍微控制不當，就會變成傳統瀑布開發模型。而時間估算稍有不當，就會容易延長專案難以收拾。因此每一次務實的彈性調整，都應該在sprint之後的檢討會議上，確實檢討改善。


參考：Scrum的缺點