再來談談軟體專案的核心風險...
根據軟體專案風險管理的聖經-與熊共舞記載，軟體專案的核心風險共有以下5項
1.先天的時程錯誤(schedule flaw)
2.需求膨脹(requirement inflation)
3.人力流失(employee turnover)
4.規格崩潰(specification breakdown)
5.低生產力(poor productivity)

先天的時程錯誤
通常在傳統專案中，時程都是被客戶硬押著決定的，專案經理只能依客戶占卜得到的deadline，往回推每項工作所能利用的時間。當然，這種做夢訂出來的時程當然不可能準確，但是卻又沒有人敢面對這事實反抗客戶，反正距離deadline還很久，說不定大家努力點加點班還是能趕上，因此專案從一開始便注定了時程延遲的命運。再者，軟體開發是腦力活動，由實際的開發人員來做估算也沒辦法準確。但在傳統專案中，一般卻是由專案經理或是資深的系統分析人員來依經驗估算，但其實人類的記憶十分的不可靠，依經驗(咦？)，這種單純用經驗來估算時程的方法，往往會過於樂觀，造成原本已經難以達成的時程進化成不可能的任務。

因此在Scrum改以讓客戶及團隊一同討論協調的透明方式來決定時程，由團隊估算每個User story的point和Task工時，再由PO決定哪些Story要在這個Sprint中實作。並且因為Sprint有Timebox的限制，使得再也無法隨意地壓縮時程，來避免估不準的時程更加雪上加霜。

需求膨脹
客戶通常並不了解需求變更的成本有多少，常聽到的說法是這功能不是設計的很有彈性，應該設定一下就可以用了吧。再加上從頭到尾用「經驗」來擲骰子估時程的專案經理，不懂得生孩子就要10個月，只會不斷地認為再努力點就能趕上。一旦少了對時程的危機意識，自然會一直接受需求。

而在Scrum當中，PO雖然可以不停地變更Product backlogs中的項目，但是卻有Sprint的Timebox和凍結Sprint backlogs的機制來防止需求在Sprint期間膨脹。由於估算需求時程的方式，是在Sprint plan meeting時，先由PO解說Story的細節，再由團隊根據PO的說明來估算。而在溝通協調的過程當中，除了能讓團隊了解實際需求，亦能讓PO了解估算的基礎為何，團隊為了完成需求要花費多少時間來做哪些工作。因此在公開透明的協同合作下，讓生孩子這件事能得到10個月的時間，自然也就達到Timebox限制。

後面三項，明日再續XD