iT邦幫忙

DAY 22
3

PMP的敏捷之路系列 第 22

PMP的敏捷之路-還是風險

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

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

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

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

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


上一篇
PMP的敏捷之路-再談風險
下一篇
PMP的敏捷之路-eXtreme Programming簡介 (1)
系列文
PMP的敏捷之路30

1 則留言

我要留言

立即登入留言