自從編程界的領袖們發表旨在通過接受需求變更，加強同用戶合作，縮短軟件提交周期來改善軟件開發過程的敏捷軟件開發宣言至今已近10年之久了。

　　敏捷宣言制定2001年2月，當時一群軟件開發者聚集在猶他州，他們希望能找到一種可以替代那些由文檔驅動的、“重型”的軟件開發模式(如當時的被當作金牌標準的瀑布模型方法)的新方法。
　　盡管早在猶他州會議之前，敏捷開發方法就已經出現，但這次會議卻被當作這種方法論推廣進程中的一次分水嶺事件。十年以來，敏捷開發已被眾所周知，很多軟件公司采納了Scrum和XP(極限編程)等敏捷開發實施方案。盡管還存在著不可預知的問題，敏捷方法領域里的專家都認為，總的來說，敏捷方法的實施會給軟件開發活動帶來益處。

　　“我說過，我們改變了這個行業，”一位宣言的簽署者、目前在Tektronix工作的Ward Cunningham這樣說。由于敏捷的出現，關于計算機編程的沒落和編程危機的討論逐漸消失，他說：“我們已經再也聽不到人們談論這個話題了。”

　　敏捷宣言比實際預期要成功的多，IBM Rational部門的首席敏捷和Lean方法論導師Scott Ambler這樣說。

　　“它對我們整個行業有著重大的影響，”Ambler說。“如今你已經很難找到有不想去試試敏捷方法的人了。跟傳統的開發方法相比，人們希望使用敏捷開發和迭代開發來使項目獲得成功的愿望要強烈的多。“

　　但是Kent Beck，同樣也是一位宣言的簽署者，并且是XP的創始人，在宣言簽署的10年后，對敏捷開發所帶來的好處去并不是那么認可：“對于這個問題我沒有一個幾句話的答案。”

　　“敏捷開發是讓人們更加認真仔細的思考如何開發軟件，”Beck說。然而，并不是每個人都在敏捷開發上走對了路，他提示說。“仍然有很多人喜歡把讀來的一些建議指導應用到他們的項目上，其實那些根本不是所謂的敏捷開發，“Beck說。

　　敏捷開發的條件

　　敏捷開發很難學，Cunningham說；”在你能夠使用這套方法論前你必須掌握精通各種技巧。“

　　敏捷開發需要你扎實的技術功底，Cunningham強調道。”有很多人闖進這個領域后發現編程枯燥乏味，不再想學。“Cunningham說:”你要有興趣做它，想把它做好，這樣才有助于你成功。“

　　“來自企業組織的阻礙會在敏捷方法論的實施過程中顯現出來。敏捷開發鼓勵更加頻繁的交付軟件，鼓勵把事情分解成小塊，而不是把整個項目看成一塊。”Skip Angel — 工作于BigVisible Solutions的一位敏捷顧問這樣說。”我想這些對于一些企業是個挑戰，這些企業的運營方式并不能使他們可以做敏捷的交付。“

　　項目在一些耗時的過程中很可能會陷入泥潭，Angel補充道，開發人員應該使用持續集成來避免這種瓶頸。

　　敏捷開發不是銀彈，Ian McLeod–做應用軟件生命周期管理工具的SmartBear Software公司的執行副總裁這樣說。”你需要把事情做對 … 你的敏捷開發可能做的很失敗，“ 他說。

　　Beck回憶起1997年用敏捷開發方法成功的開發出JUnit Java單元測試工具。他們團隊使用短周期迭代，大量的單元測試，緊密和客戶進行溝通。

　　”它使我們開發的更快，使我們更好的清楚需要去做的事情，“Wade Weston — 開發標準化交流系統的AttainResponse公司的CEO 這樣說。”AttainResponse每周進行開發工作的sprints。我們的sprints周期很短，我們把精力高度的集中于本周要做的工作。“Weston說。

　　“‘可是讓每個人都能上手仍然是個問題，’我的一個兄弟經常對我這樣說，他喜歡更詳細明確的需求。我一直告訴他，我們之所以開發的這么快，就是因為我們沒有明確的需求，”Weston說。等待核心的需求說明基本上是浪費時間。他補充道。

　　”有些時候，一些開發人員說他們在做敏捷開發，可事實他們根本不是，“Damon Poole — 提供敏捷開發項目管理軟件的AccuRev公司的CTO 這樣說。“有些開發人員2周都不能把開發的東西(或“故事”)完整的編譯集成，”他說。“如果你真的是做敏捷開發，那2周的時間足夠把用戶故事發布了。”Poole說。

　　敏捷編程的多種實施方案

　　Scrum 和 XP 是兩個最具有代表性的敏捷方法論。Beck把XP描述為更注重開發的技術方面的方法。“XP說的更多的是告訴程序員應該做什么，相對比，Scrum是一種項目管理方法論”他說。

　　”XP的與眾不同之處在于它是一種體系，而不是一種解決方案。“Cunningham — 一位推動XP發展的貢獻者這樣說。”它是一種有計劃的編程方式。“

　　Scrum專注于如何管理和交付你的產品，而XP卻是考究于如何去做你的工作，Angel說。

　　Poole指出，”很明顯Scrum和XP是目前兩種主要的方法論，你經常能看到Scrum團隊會采納XP技巧，而XP團隊也會使用Scrum概念。“

　　另外一種敏捷方法論是Kanban，它起源于制造業生產流程和Lean軟件開發概念，Poole說。Kanban里的約束很少，它關注于如何使價值反饋給客戶的過程，他解釋說。Lean關注于組織效能優化，價值優化，降低浪費，確保正確的好的生產過程，Angel補充說。

　　RUP(Rational Unified Process)也被人們稱作為一種敏捷方法，盡管這種說法有待商榷，McLeod說。RUP的特點是有一大堆的文檔，它可能是針對敏捷方法中的各個步驟的，他解釋說。RUP可以是一種敏捷方法，Ambler說：”RUP給予我們的是流程上的架構準則。它完全依賴于你是如何制定的。“

　　Ambler同時提到了DSDM — Dynamic Systems Development Method — 一個敏捷領域里的失敗的案例。SDSM有點像RAD [rapid application development]，但在里面增加了一下額外的處理。RAD跟敏捷開發的不同之處在于它只關注開發迭代，而不考慮促進合作，他指出。

　　McLeod認為各種敏捷方法論和迭代開發過程很相似。”它們之間沒有太多的區別，“他說。

　　“敏捷”這個術語，Cunnigham說，是在猶他州會議上選出的一個詞，人們通常把它引用為”輕量級“的方法，他回憶到。但”輕量級“這個詞從表面意思上看也承載著一些負面的含義，他說。

　　[英文出處]：Agile programming 10 years on: Did it deliver?

NET技術：敏捷十年，成效幾何？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。