敏捷開發的道與術---MPD軟件工作坊培訓感想（上）

注：由麥思博(MSUP)主辦的2013年亞太軟件研發團隊管理峰會(以下簡稱MPD大會)分別于6月15及6月22日在北京、上海舉辦，葡萄城的部分程序員參加了上海的會議，本文是參會的一些感受和心得。

這次MPD軟件工作坊培訓，最大的收獲就是培訓者引導你了解了為什么，而不是直接告訴你該怎么做。其實只要清楚目標在哪，無論怎么走都是可以到的。

隨便百度一下，我們可以了解到項目管理的定義是“在有限資源限定條件下，實現或超過設定的需求和期望”。一句話形成了項目管理的鐵三角，需求是范圍，資源包括時間和成本。

這傳承多年的“定義”是對的嗎？摩托羅拉的銥星計劃，計劃發射77顆衛星，最后只發射了66顆衛星就“圓滿“完成了目標。可謂成本的項目。電影泰坦尼克號拍攝過程多次拖期，預算超出很多，可謂是個徹底失敗的項目。

可是結果呢？好像哪里不對？銥星項目發射的衛星現在全成擺設，而泰坦尼克至今仍然是世界的票房神話。

到底哪里不對呢？

我們的項目管理鐵三角里忽略了價值。

就是這里了，我們的目標是創造價值，實現共贏。

好，目標在這里了，到達目標的方法有很多，每個人都會找到方法。敏捷有很多的流派，有很多的實踐來幫助人們達到這個目標。了解別人怎么做，最重要的是理解別人為什么這么做。

要創造價值，第一問題就是做什么是有價值的。換句話說怎么樣才能獲得有價值的需求。

來自客戶? 客戶永遠要更快的馬車。

客戶往往講不清楚需求，但這些講不清楚的需求有些甚至是影響整個結構的關鍵。

來自產品人員的策劃？ 沒人能說明下面的設計放在網頁上更受用戶喜歡。

來自領導，業務顧問，運營團隊？

貌似都不太對。

敏捷項目管理說，來自市場的真實反饋。要得到市場的真實反饋我們需要持續不斷的及早的交付有價值的軟件。通過市場反饋來獲取新的價值。

這點做的就好的應該屬于各大互聯網公司了。每月每周甚至每天的發布新功能到市場上，搜集用戶反饋和反應，除了用戶的主動反饋，還包括點擊率、瀏覽量、用戶停留時間等訪問記錄。根據反饋迅速移除沒有價值的功能，增強有價值的功能以創造更大的價值。（關于移除功能，甚至關閉一個沒有價值的項目，這正是敏捷的魅力所在，它不但可以讓項目迅速創造價值，也可以讓本不能創造價值的項目迅速失敗。個人觀點：讓一定會失敗的項目快速失敗可以節省大量的資源，給系統帶來的價值甚至更高！但這一點卻往往被忽略。認為敏捷必須把項目帶向成功，想想銥星項目，如果早早發現沒有價值，世界可能都會不一樣，至少摩托羅拉公司會不一樣吧。）

聽起來很美，聯系我們的實際卻很困難。我們不能立即發布新功能到市場上，我們不能隨意的移除沒有價值的功能，我們甚至很難從市場獲得功能的價值信息。聽起來很沮喪。但是，幸運的是，我們知道我們的目標是什么，我們可以千方百計地收集用戶反饋，我們可以通過我們的聲音影響一些決定，讓我們做的事情更有價值。這本身就是雙贏的事情，應該會被逐漸的接納。

回到主題，持續交付很好很強大，但它帶來了新的問題。如何保證交付質量，如果交付到市場的軟件由于質量問題根本不可用或者幾乎不可用，是不可能得到正確反饋的。敏捷答，持續集成，測試驅動開發。

持續集成不說了，我們做的很好。測試驅動開發無論何時何地，一提出都是一個爭議性話題，因為這看起來太不敏捷了。一連串的問題，寫測試腳本會拖慢進度怎么辦？測試腳本的質量又如何保證？測試腳本會對變更產生格外的工作量，怎么辦？等等。其實，這也是我心中的疑問。通常得到的答案都是，測試驅動開發產生的工作量都是值得的！好吧，還是那句話，目標在那里，為了實現高質量持續交付的目標我們可以選擇的方法很多。加強代碼審查，對關鍵功能，關鍵模塊做自動測試覆蓋。甚至包括遺留一些bug但是得到用戶反饋之后及時修復。雖然理論上沒有測試驅動開發有效，但是我們可以根據自己的實際情況，在投入和收益上找到平衡點，步子小一點也行更不容易跌倒。

綜上，敏捷項目的“鐵三角“：      

更強調了價值和質量。

當然質量是很重要的，但質量并不是越高越好。比如，招聘網站一兩個小時不工作，和證券交易系統一兩個小時不工作，對用戶的影響肯定是不一樣的。所以質量的要求要依賴產品和需求的背景。

不可忽視的是，鐵三角里沒有提到，但是卻在敏捷項目管理中至關重要的一環——人。

價值是人創造的，為人服務的，很多敏捷實踐是圍繞人展開，試圖找到一種（一系列）通用的方法來最大限度的發揮人的能量。例如計劃游戲，組建自組織團隊，信息公開透明化，集體承諾目標。都是調動團隊積極性，消除可能影響團隊成員貢獻的因素。

對于敏捷實踐，林林總總，有如十八般兵器，各門武功，都是名家大師的智慧精華。但是如果只知道招式不知道招式的目的，很容易被人一招打倒的。