1. 程式人生 > >敏捷開發中對進度的把握

敏捷開發中對進度的把握

51CTO推薦專題:初探敏捷開發

專案經理被問到最多的問題就是,“這個專案什麼時候才能完成?”

被問的時候,可能專案才定下來,僅僅知道大概的功能模組,非功能性需求還模糊不清,甚至團隊成員都沒到位。但是上級、銷售、客戶急切地要知道,這個專案什麼時候才能完成?

被問的時候,也可能專案已臨近結束,或者說臨近當初計劃的交付日期。然而待完成的功能還有一堆,測試出來的bug有一大堆,客戶又提出了新的需求,團隊正有人要離職 …。但是上級、銷售、客戶非常急切地要知道,這個專案到底什麼時候才能完成?

這還不算糟糕。更頭疼的問題是:“再有三週,專案應該完成了吧?”

因為後者根本不是問題,而是命令。專案經理必須要能夠合理解釋為什麼三週不能夠完成專案;或者說明在三週內,能夠完成什麼。

我們都用過MS Project, 但是那上面的漂亮表格對這樣的困境毫無幫助。相反,正是Project 中的甘特圖和日程表,埋下了陷阱。因為,在Project 中無法預估需要多少工作日才能完成模糊不清的需求,也無法體現實際情況發生變化後對進度的影響。

當我們討論進度的時候,其實包含了兩個未知的變數。第一是完成需求所要的工作量,包括需求定義、開發內容邊界;第二是團隊的工作能力,包括成員的行業知識專業技能,成員之間、成員和外部的溝通能力,等等。

關鍵就在於,這兩項都是變數。如果任務是搬一千塊磚頭,每分鐘每人能搬10塊,那麼結果是顯而易見的。

在敏捷開發中,採用相對估算和迭代求精的方法來處理專案進度的問題。

首先是工作量。用估算程式碼行數或者介面元素的方式,就像論斤賣書一樣,只適用於粗製濫造的軟體生產過程。使用者需要的並不是程式碼或者按鈕,而是可靠易用的功能。

在敏捷開發方式中,先由使用者和設計人員粗略估計各個功能模組的相對規模和難度,給出一定的分值。分值不代表具體人月,起相對比較的作用。例如有查詢、顯示、修改三個模組,如果實現顯示模組的工作量是10分,那麼查詢模組可能是15分,而修改為20分。

下一步,選擇一個工作量估分最低的模組,例如這裡是顯示模組,然後進一步考量其工作量。例如要準備資料庫、設計介面、執行查詢,顯示內容等等。假設這輪估算得出此模組需要10人天,從而得出單位分值對應的人天為1;那麼,整個專案就需要45人天。

這個估算建立在對專案的初步瞭解上,主要依賴專案經理的經驗。有偏差?沒關係。接下來通過迭代來求精。先來實現顯示模組,如果事實上花費了12人天,那麼根據比例關係,剩餘內容的估算大約就是42人天。

當然,比例關係也不是一成不變的。隨著模組的逐個完成,專案經理對專案的認識也在加深,他可以再調整剩餘模組的相對分值。

在實際操作中,專案經理首先按照優先順序排列功能模組。然後把高優先順序的模組儘可能地細分,再選擇分值最小的模組開始開發。統計總工作量時,按比例累加其他模組的工作量,並加一定的調整係數,因為模組的複雜度不是線性增長的。每次迭代開發完成後,逐步降低調整係數。通常4~5次迭代後,可以將調整係數歸零。

在上面的例子中,第一次估算的初步結果是45人天,因為完全是憑經驗,因此要給較大的調整係數,比如說0.4,因此給出的估算工作量區間為[45*0.6,45*1.4],即27到63人天之間。為保險起見,專案經理上報的工作量為70人天。

第二次估算,剩餘內容的初步估算為42,調整係數下降為0.3,因此給出估算區間為30到50人天之間。依此類推,通過不斷迭代,對剩餘工作量的估算將越來越精確。

這樣估算的好處在哪裡?

首先,工作量變數的很大一部分因素,存在於非功能需求,例如介面的美觀程度。而同一專案的不同模組之間,非功能需求往往是一致的,相對估演算法過濾了這一層複雜度。團隊能力這一變數因素也是如此。當然,隨著專案的進展,成員的開發能力應該有一定的上升,但隨著加班出差等因素,投入程度也可能下降,因而會相互抵消。總之在週期6個月以內的專案中,很少出現團隊工作能力戲劇性變化的情形。因此相對估算也過濾了這個複雜度。

其次,迭代求精的方式讓專案經理對估算時間更有把握。最初出現偏差是必然的,但只要團隊穩定,沒有大的需求變動,估算範圍將迅速收縮。這比一次性報數更準確。

它的額外好處是,敏捷開發是遵循優先順序的,即使對剩餘時間(即低優先順序模組的開發時間)的估算不十分準確,影響也不是非常大。

對比一下甘特圖方式,在開發初期就要把各個模組的開發時間估算出來以統計總量,這就是瀑布開發的模式。

進度問題的另一方面,是專案經理如何瞭解團隊以及每個開發人員的開發速度。當任務分配之後,專案經理如何做到心中有數,估算任務實際完成時間。

敏捷開發過程中,由開發人員自己來估算完成該任務所需要的時間。當然,每個人的能力不同;每個人的心態也不同,有的人保守,有的人樂觀。沒關係,還是靠迭代來逐步求精。

在每天的例會上,開發人員被要求對當前任務的剩餘開發時間做重估。不同於Project 統計每人每天在任務中花費了多少時間,敏捷方式只關心這項任務還需要多少時間去完成,直到歸零,然後再來統計實際的工作時間。

為什麼?因為統計開發過程中的花費時間是毫無意義的。這和搬磚頭不同,也許昨天用了8個小時沒有一點進展,今天一旦想通了就事半功倍。我們真正關心的,就是到底還需要多少時間來完成任務,而不是已經花費掉不可恢復的時間成本。

在每天例會中,專案經理需要注意時間曲線保持水平的成員,他是不是遇到瓶頸了,是否需求幫助?也要留意時間曲線下降幅度過大的成員,他發現了什麼好的辦法,有沒有低估需求?這樣,專案經理會更面向結果,只要按計劃保證質量完成任務就行,成員到底花了多少時間是個人的事。傳統做法記錄每個人每天的工作內容,第一是因繁瑣而失真。其次,一旦上級發現某人工作時間不夠(即便他完成了任務),忍不住會派新任務,從而造成越幹活越多,反過來打擊程式設計師的積極性。

敏捷估算的關鍵之處,是把成員能力這個變數的估算,交給最合適的人去做,即程式設計師本人。然後通過比較歷次迭代時的預估和實際時間,給出校正係數,以避免程式設計師過於保守或過於樂觀。這肯定不是絕對準確的,但效果往往比專案經理自己拍腦袋估算,然後強行指定deadline 要好得多。

在敏捷開發中,做計劃比計劃本身更重要。專案經理需要時刻向前考慮,考慮各種動態因素,而不是死報著計劃本身。在進度估算的時候,專案經理應該在不同階段,根據實際情況,給出合乎情理的回答。