談談軟體項目管理——靈活開發

　　一、前言

　　agile是指企業能夠對外部環境做出速捷、有效的反應，是未來企業的必備素質。21世紀企業面臨的競争環境将是一個不斷變化、不可預測的環境。由于高新技術的出現和更疊越來越快，産品的生命周期日益縮短，企業要面對這樣的新的競争環境，抓住市場機遇，迅速開發出使用者所需要的産品，就必須實作靈活反應。

　　狹義地講，靈活企業就是将柔性的先進制造技術、熟練掌握生産技能、有知識的勞動力以及促進企業内部和企業之間的靈活管理三者內建在一起，對千變萬化的市場機會做出快速、有效的響應。靈活企業強調人、組織和技術的有機結合。通過這三者的緊密結合，靈活企業可以發揮最佳的整體效益。評價一個企業靈活性的具體名額是時間、成本、穩健性（robustness）和适應範圍。對靈活企業的廣義了解，可以認為靈活企業是一個cims（計算機內建制造系統）、動态聯盟、并行工程、仿真制造、高素質員工等多方面的系統內建，是一個基于cims、在cms基礎上發展起來的一個更高層次的內建大系統。

　　二、變味的靈活

　　另外，關于實施靈活的效果也是充滿置疑之聲。我們經常看到一些号稱agile的國内項目，按照菜單、操作指南和教父語錄的提示，采用了許多花哨的技巧和實踐（做法），是啊，表面上确實agile了，那麼結果呢？項目還是不能按時完成，甚至嚴重超支和逾時，這能叫“靈活”嗎？

　　三、靈活十戒

　　1、天報制度

　　就算是進行遠端開發或是兩地使用開發，項目組的成員每天至少碰一次，不管是當面的，還是通過其它方式，如通過電話、email、skype或其它。進行靈活開發的時間，任何團隊都不能以任何理由進行孤立的開發。

　　2、例會制度

　　即使每天通過email給主管彙報工作，但有時主管還是無法及時準确的掌握項目組成員的狀況及工作量。此時，通過每周一小時左右的例會将會有效的解決此問題。通過例會，大家面對面的就某些問題進行共同的探讨與讨論，找到共同的解決方案。

　　3、版本控制

　　如果沒有一台幹淨的電腦來進行團隊代碼管理的話，則很有可能導緻代碼的混亂。而每天隻須花很少的時間，哪怕一天一次，進行及時的資料送出與代碼送出，則可以有效的保證團隊之前代碼的同步及代碼的備份。

　　4、需求失靈

　　即使手裡拿着30頁且客戶進行了簽字的需求說明，有可能仍然不知所措。相對起那些良好的設計、精确的分析等，與客戶持續的溝通、及時的回報、不斷的示範這些工作顯得更加的有效果。可以有效的獲得需求變化，減少誤解，更加準确的把握使用者的需求。

5、單元測試是qa的工作

　　很多開發人員，甚至一些進階的軟體開發人員，對于單元測試沒有足夠的認識，在行動上也沒有足夠的注意。大家都一緻的認為那是qa的事情。就開發人員來講，單元測試應該是一種白箱測試，能從功能上充分的測試軟體的功能性。而對qa來說，隻能是一種黑箱測試，無法深入的去分析代碼的優勢，隻是從使用者的角度進行功能上的測試而已。

　　6、品質保證是qa的責任

　　自從有了品質管理這個詞以及後來産生的品質管理部門後，很多開發人員就理所當然的認為品質保證是qa的責任了。其實每一個人都需要對軟體的品質負責，特别是開發人員。bug越最早發現，那麼解決它的成本就越低。

　　7、項目進度風險控制

　　也許一個項目需要18個月左右才能完成，但在沒完成之前，誰也無法進行比較準确的時間估計。無法确定需要多長的時間進行設計、編碼及軟體元件的組合。但進行項目設計、實作及融合的人應該相對比較準确的掌握與估計項目的時間。是以，需要進行項目進度的風險控制，風險總是存在的，但要進行有力與及時的控制。充分意識到項目中可能會存在的風險因素，在制定計劃時預留一定的時間，如果在項目進行中出現了沒有想到的問題，根據其重要性，考慮壓後解決，要在計劃的時間内把計劃的事情完成好，并為後續解決問題争取更多的時間。

　　8、架構師身體力行

　　很多軟體架構師基本上不寫代碼，這也許是好事。軟體架構師嘛，當然是比較進階的，他們對環境、語言、類庫方面都可能比軟體開發人員要更加在行，但他們一般不編碼。這樣的架構師是危險的，特别是那些基本上不與首席開發人員進行溝通或咨詢的架構師，離項目失敗可能已經不遠了。

　　9、牽一發而動全身

　　很多時間，在功能上做了一個很小的變動，往往導緻花費好幾天的功夫來進行軟體的內建與整合。如果沒有持續的整合、及時的回歸測試、可靠的整體設計，一些看起來非常微小的修改都有可能導緻很大的麻煩。

　　10、加大管理執行力

　　目前項目中，開發者或者說參與人的狀态是混亂的，或者說是慌亂的。那問題在哪裡呢？是工作流程出了問題？不應該啊！在項目啟動前已經定了一個看似美好的流程，而且是經過參與人讨論一緻通過的。那麼問題在哪裡呢？原來是溝通、傳達出了問題，執行力不夠。那麼，就必須加大執行力，今日事今日畢，這是必須的。

　　另外，在一些産品級的軟體開發中，覺得要實施靈活式開發，我覺得也有一個不好解決的問題：沒有具體的客戶！沒有具體的客戶，那你的溝通去哪裡尋找呢？一般的做法也是給一些有興趣的使用者釋出alpha版本，或者是beta版本的軟體。可是當軟體都到了alpha/beta版本的時候，軟體還有疊代的餘地嗎？未必！從我個人了解的角度來看，靈活開發的适用範圍還是很有局限性的。個人認為最适合使用靈活開發的軟體必須要有非常明确的客戶才能進行，而有明确客戶的情況以定制型軟體為主。是以，我覺得最适合用靈活方式開發的軟體應該是——定制軟體！

　　四、小結

　　記得jim highsmith在他的《靈活項目管理》一書中這樣寫道：靈活是指在動蕩的業務環境中，适應變化并創造變化，進而獲得價值的一種能力。同時靈活是平衡靈活性和穩定性的一種能力。由此可見，望文生義地把“靈活”了解為“做得快”也頗可商榷。如果缺乏有效的實施指導、忽視嚴格的靈活實踐，單憑着高層面的了解甚至“文化”就開始盲目前行，往往會因為缺乏對品質的有力保障而失去平衡，最終欲速則不達。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/