今天繼續談剩下的三項核心風險
人力流失
俗話說的好「錢都老闆在賺，肝都員工在賣」，再怎麼號稱人是公司最重要的資產，看在員工眼裡都是放○。人力流失會導致知識斷層，交接最重要的事是留下離職者的手機號碼，其他再怎麼交怎麼接也沒辦法不會在短期造成生產力內下降。因此為了應對人力流失，敏捷方法強調以團隊作戰的方式來開發專案，首先，所有的工作皆是由團隊成員自由認領的，而非由主管指派的方式，工作細節的討論也是所有團隊成員一同參加的。如此一來，便不會出現僅有單一的人才懂這部份的情況發生。另外，敏捷團隊會推行Pair programming、Coding standards及Collective code ownership，Pair programming不僅能讓程式碼的品質更好，其附加的價值就是這段程式碼至少會有兩個以上的人看的懂。另外，由於程式碼是共有的，每個人都會查看及修改別人開發的程式，因此一旦真發生了人員異動，便能將知識斷層的情況降至最低。

除此之外，敏捷團隊還會打造一個公開透明的良好工作環境，由於固定了每個Sprint的工作量，使得工作能夠定速定量地完成，減少了死亡行軍的發生機會，在身體健康快樂的情形下，人員便不會像草莓一樣一捏就爛。

規格崩潰
規格崩潰指的是專案一開始時，由於政治因素的原因，利害關係人的利益衝突擺不定，所以只好在規格文件上保留許多模糊的空間，然後再加上業務的三寸不爛之舌隨意解釋，以求讓所有的利害關係人都願意簽名畫押，以求讓專案可以繼續執行下去。這麼做的結果就是這些模糊的空間總有一天還是要搞清楚細節的，一旦到了要翻牌來引爆地雷的時候，通常也到專案的後期，使得中止或繼續下去都會造成莫大的損失。

為了避免此一情況發生，Scrum營造透明開放的溝通管道，讓問題能在每次Sprint planning meeting當中，能夠盡早的被識別及討論，再者User stroy是由最重要的項目先實作，並且是完整的功能特點，因此就算問題是到後期才引爆，也會是非主要功能的需求。

低生產力
造成低生產力的因素有很多，像是過多的重工，技術能力不足，長期的加班，甚至是團隊成員心情不好都會造成低生產力，Scrum的流程在架構上，皆有避免或改善這些障礙發生的機率，如用短周期的Review來讓客戶確認系統是否符合需求，好避免重工的情況發生，或是透過Retrospective meeting不斷地改善開發流程，並且提升團隊的生產力。