PMP的敏捷之路-再談風險
根據軟體專案風險管理的名著-與熊共舞記載，軟體專案的核心風險共有以下5項
- 先天的時程錯誤(schedule flaw)
- 需求膨脹(requirement inflation)
- 人力流失(employee turnover)
- 規格崩潰(specification breakdown)
- 低生產力(poor productivity)
以下分別就這5項來說明敏捷開發是如何降低這些風險的。
先天的時程錯誤
在傳統專案中，時程通常都是被客戶硬押著決定的，專案經理只能依客戶靈機一動得到的deadline，往回推每項工作所能利用的時間。當然，這種做夢訂出來的時程當然不可能準確，但是卻又沒有人敢面對這事實並且反抗客戶。大都抱著反正距離deadline還很久，說不定大家努力點，多加點班還是能趕上時程，因此專案從一開始便注定了時程延遲的命運。再者，軟體開發是腦力活動，就算由實際的開發人員來做時程的估算也沒辦法準確。但在傳統專案中，一般卻是由專案經理或是資深的系統分析人員依本身經驗估算。只不過人類的記憶其實十分的不可靠，依我個人經驗(XD)，這種單純用經驗來估算時程的方法，往往會過於樂觀，造成原本已經難以達成的時程再次進化成不可能的任務。
因此在Scrum中，改採用客戶及團隊一同討論及協調的透明方式來決定時程，由團隊估算每個User story的point和Task工時，再由PO決定哪些Story要在這個Sprint中實作。並且因為Sprint有Timebox的限制，使得再也無法隨意地壓縮時程，來避免估不準的時程更加雪上加霜。
需求膨脹
客戶通常並不了解需求變更的成本有多少，常聽到的說法是這功能不是應該設計的很有彈性，做一下設定就可以用了吧。再加上從頭到尾用「經驗」來擲骰子估時程的專案經理，不懂得生孩子就一定要10個月，只會不斷地認為再努力點就能趕上。一旦少了對時程的危機意識，自然會一直接受需求。
而在Scrum當中，PO雖然可以不停地變更Product backlogs中的項目，但是卻因為有Sprint的Timebox和凍結Sprint backlogs的機制來防止需求在Sprint期間膨脹。由於估算需求時程的方式，是在Sprint planning meeting時，先由PO解說Story的細節，再由團隊根據PO的說明來估算。而在溝通協調的過程當中，除了能讓團隊了解實際需求，亦能讓PO了解估算的基礎為何，團隊為了完成需求要花費多少時間來做哪些工作。因此在公開透明的協同合作下，讓生孩子這件事能得到10個月的時間，讓需求膨漲所帶來的傷害能盡量歸零。
人力流失
俗話說的好「錢都老闆在賺，肝都員工在賣」，再怎麼號稱人是公司最重要的資產，看在員工眼裡都是放○。人力流失會導致知識斷層，交接最重要的事是留下離職者的手機號碼，其他再怎麼交怎麼接，也沒辦法避免在短期之內造成團隊的生產力下降。因此為了應對人力流失，敏捷方法強調以團隊作戰的方式來開發專案，首先，所有的工作皆是由團隊成員自由認領，而非由主管指派的方式，工作細節的討論也是所有團隊成員一同參加的。如此一來，便不會出現僅有單一的人員才了解這部份功能的情況發生。另外，敏捷團隊會推行Pair programming、Coding standards及Collective code ownership，Pair programming不僅能讓程式碼的品質更好，其附加的價值就是這段程式碼至少會有兩個以上的人看的懂。另外，由於程式碼是共有的，每個人都可查看及修改別人開發的程式，因此一旦真發生了人員異動，便能將知識斷層的情況降至最低。
除此之外，敏捷團隊還會打造一個公開透明的良好工作環境，由於固定了每個Sprint的工作量，使得工作能夠定速定量地完成，減少了死亡行軍的發生機會，在身體健康快樂的情形下，人便不會像草莓一樣一捏就爛。
規格崩潰
規格崩潰指的是專案一開始時，由於政治因素的原因，利害關係人的利益衝突擺不定，所以只好在規格文件上保留許多模糊的空間，然後再加上業務的三寸不爛之舌隨意解釋，以求讓所有的利害關係人都願意簽名畫押，好讓專案可以繼續執行下去。這麼做的結果就是這些模糊的空間總有一天還是要搞清楚細節的，一旦到了要翻牌來引爆地雷的時候，通常也到了專案的後期，使得中止或繼續下去都會造成莫大的損失。
為了避免此一情況發生，Scrum營造透明開放的溝通管道，讓問題能在每次Sprint planning meeting當中，能夠盡早的被識別及討論，再者User stroy是由最重要的項目先實作，並且是完整的功能特點，因此就算問題是到後期才引爆，也會是非主要功能的需求。
低生產力
造成低生產力的因素有很多，像是過多的重工，技術能力不足，長期的加班，甚至是團隊成員心情不好都會造成低生產力，Scrum的流程在架構設計上，皆能避免或改善這些障礙發生的機率，例如用短周期的Review來讓客戶確認系統是否符合需求，好避免重工的情況發生，或是透過Retrospective meeting不斷地改善開發流程，並且提升團隊的生產力。