敏捷開發大家談（一）

  敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。簡言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

      敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑑了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。

      改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。“在敏捷軟體開發的過程中，我們每兩週都會得到一個可以工作的軟體，”Fowler介紹，“這種非常短的迴圈，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。”

      也許是因為時間關係，Fowler只說出了這些優勢中的一部分。允許開發過程中的需求變化、通過早期迭代可以較早發現風險、使程式碼重用變得可行、減少專案返工……借鑑了眾多先進方法和豐富經驗，擁有的眾多優勢使得敏捷開發看來已經成為解決軟體危機的標準答案。

      問題與思考
      然而，我們不得不面對的現實卻是，模式與方法的優化並不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。

      大專案的拆分意味著更多子專案的出現，協調這些同步或非同步推進的子專案，合理的資源調配都將變得更加複雜。另外，在當前專案和專案組普遍“增容”的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和專案變更對整個專案造成的影響也將成為一大挑戰……新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。

敏捷開發（agile development）概念從2004年初開始廣為流行。Bailar非常支援這一理論，他採取了"敏捷方式"組建團隊：Capital One的"敏捷團隊"包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務資訊指導（實際上是業務部門和IT部門之間的"翻譯者"）；另外，還有一個由專案經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過"敏捷開發"的培訓，具備相關的技能。

      每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支援。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個專案階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT專案會被拆分成多個子專案，安排給各"敏捷團隊"，這種方式在"敏捷開發"中叫"蜂巢式（swarming）"，所有過程由一名專案經理控制。

      為了檢驗這個系統的效果，Bailar將專案拆分，從舊的"瀑布式"開發轉變為"並列式"開發，形成了"敏捷開發"所倡導的精幹而靈活的開發團隊，並將開發階段分成30天一個週期，進行"衝刺"--每個衝刺始於一個啟動會議，到下個衝刺前結束。

      在Bailar將其與傳統的開發方式做了對比後，他感到非常興奮--"敏捷開發"使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。"不過，有些需求不能用敏捷開發來處理。" Bailar承認，"敏捷開發"也有侷限性，比如對那些不明確、優先權不清楚的需求或處於"較快、較便宜、較優"的三角架構中卻不能排列出三者優先順序的需求。此外，他覺得大型專案或有特殊規則的需求的專案，更適宜採用傳統的開發方式。儘管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓CIO受益匪淺。

      敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為：

個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
並提出了以下遵循的原則：

我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。
工作的軟體是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單是最根本的。
最好的構架、需求和設計出於自組織團隊。

每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-269186/，如需轉載，請註明出處，否則將追究法律責任。