關于敏捷開發方法(Agile Software Development)的閱讀筆記

　　對“敏捷開發”（Agile Software Development）這個詞，我是在這學期鄒欣老師《現代程序設計》課上第一次聽到的，剛聽到時并不知道其具體指什么，只是從字面上直覺其意思應該是快速開發之類的。這次從 Agile Guide?、?The New Methodology?以及其他一些中文資料上較為詳細地了解了敏捷開發方法及其與傳統開發方法相比的優勢所在，收獲頗豐。下面談談在這次閱讀中所學習到的東西。

一、什么是敏捷開發方法

　　通常而言，敏捷開發方法是一種以人為核心的、循環的、迭代的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態（來自百度百科）。我想，其關鍵之處在于迭代。

二、敏捷開發方法的核心思想：適應變化（Adaptive）和以人為中心(people-oriented)

　　軟件開發方法的發展經歷了從沒有、到繁重的工程方法、再到敏捷開發方法的過程。早起軟件開發方法沒有完整的規劃，是一個短期的、即時的、邊寫邊改的、組合的過程，當系統很小時這種方法可能很有用但是當系統較大時就無能為力了；為了改變這種狀況，引進了”方法論“（methodology）的概念，借鑒工程領域的實踐提出了規劃驅動的方法（plan-driven methodologies）或工程方法（engineering methods）。為了讓軟件開發更具可預測性（predictable）和更有效率(efficient)，強調在軟件開發前制定詳細的規劃來約束開發過程，但成效也并不顯著；后來誕生了敏捷開發方法，這種方法企求在無過程和繁重的過程（no process and too much process），也就是上述兩種方法中找到一個平衡點，以不多的步驟過程獲得合理的剛剛好的結果。其核心有兩方面：

　　※　強調適應性（adaptive）而非預測性（predictive）：不是先制定詳盡的需求計劃然后按著計劃按部就班地做，而是先做出個雛形，然后根據需求的細化或變化進行迭代開發，對需求做出充分的響應。從某種程度上說，這種開發方法不僅不忌諱需求的變化甚至在開發的過程中需求變化得越細越明確，其產品結果越好。

　　適應性不僅指在開發過程中修改軟件來適應需求的變化，更包括自適應的過程，即通過每個階段的回顧和總結來（What did we do well? What have we learned? What can we do better? What puzzles us?）來發現自身的問題，繼而選擇一個更合適的方式或過程來進行開發工作，從而不斷完善開發過程。

　　※　強調以人面向人而不是面向過程（people-oriented rather than process-oriented）：工程方法強調事先制定詳盡的過程（process）以便讓參與進來的人都能按照計劃按部就班地做好工作，而敏捷開發方法斷言制定過程不能作為一個開發團隊技能的組成部分，其角色是支持團隊的開發工作。在開發過程中，應以人為中心，讓他們與應用領域的業務專家充分接觸來汲取業務方面的專業知識，合理安排成員的工作，合理評價、衡量每個人的工作成果，從而成為一個高效的、有責任的開發團隊。

三、敏捷開發的價值觀

　　在極限編程四個價值觀的基礎上擴展到五個：Communication（溝通）, Feedback（反饋）, Simplicity（簡易）, Courage（勇氣）,?Respect（謙遜）

四、具體的敏捷開發方法

　　xp(extreme programing)極限編程、Scrum、Crystal、Context Driven Testing、Lean Development精益開發、(Rational) Unified Process等

五、對敏捷開發方法與傳統工程方法的對比的一些看法

　　讀完這篇文章?（The New Methodology）?，我覺得這兩種開發方法最大的不同在于著眼點的天壤之別，即 adaptive process 與 predictive process 的區別。

　　對于敏捷開發來說，強調適應性

“It is adaptivity in the context of a project adapting its software frequently to meet the changing requirements of its customers.”

　　而對工程方法來說，著重通過完整的需求制定具有預測性的計劃

“Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.”

?　　1、開發過程的差異。

　　傳統的工程方法（或如文章中所說，成為規劃驅動方法）強調先詳細了解客戶的需求，然后分析需求并制定周密的開發計劃，可稱之為 “規劃編程”。但是想了那么多、那么全面、那么復雜值得嗎？要知道，計劃是趕不上變化的。相反，采用敏捷開發的方法，關鍵是先搭出個總體的框架，不要太在意與細節；然后在實踐的過程中不斷補充、添加細節，在實踐的過程中不斷完善，一有新的兩點就可以加進來，這樣不僅能完成任務，而且靈活性很大，給開發過程中產生的很多奇思妙想以實現到項目中的機會，大大提高了項目的質量，從某種程度上也大大減少甚至避免了規劃編程的一個很大的缺點——deadline的壓力。積少成多，日積月累、集微致盛的哲理在這里得到現和運用。

　　2、需求變化所帶來的影響的差異。

　　通常，在開始的時候，客戶并不真正知道自己想要什么，他們只是有個相當模糊的想法說自己想要個什么樣的、能干什么事的軟件，傳統開發方法在開始前需要想法設法地去探尋客戶到底要什么，在這方面它們投入很多，但是結果往往是他們的產品并不是很貼近用戶所需，更甚，這時用戶不可避免地有新的需求補充，這對開發者來說是致命的打擊，不管是在精神上還是在精力上、開發過程上。敏捷開發則不同，它先把一次兩次迭代開發的產品拿給用戶初步體驗，用戶在使用這個產品的過程中越發清晰地體會到了哪些功能是有價值的哪些是可以舍棄的，越發明白他們自己到底想要什么樣的東西。與此同時，開發者也越來越清楚地知道用戶要什么，在下次迭代中應該側重于哪些方面的開發，這樣就達到了 ”雙贏“ ！這可以說是對用戶需求會不斷變化這一令人頭疼的現實的充分利用，在這里，！"A late change in requirements is a competitive advantage"，用戶需求的變化成為了一個優點，與傳統開發方法害怕用戶需求變化形成了鮮明的對比！！！

　　3、產品偏離用戶需求的程度的差異

　　

　　傳統工程方法design在整個開發時間中所占的比重很大，一旦制定完規劃后便付諸實踐，這個實踐所占的比重一般比 design 少。只要做好design，其開發速度便可以變得很快，因為每一步都規劃好了，只要按部就班就可。但也正因為其按初期的需求分析進行開發，在開發過程中缺少與用戶需求方面的繼續溝通，導致了一個致命缺點——這時，初期需求分析的失之毫厘很可能導致最后產品與用戶的需求差之千里，導致”徒勞一場“；而迭代開發則是 ”In an adaptive process“—— 在最后定稿前的每個迭代過程都充分與客戶交流，一有偏差就改正，這樣就更早地發現了不符合需求的地方并及時解決，把產品與需求的差異扼殺在搖籃中，可以說開發的過程就是不斷解決現實與需求之差異的過程，就是不斷修正的過程，最后自然而然地非常接近用戶真正想要的東西，從這方面來看，敏捷開發甩傳統的開發過程幾條街！

　　4、產品的衡量標準的差異

　　傳統開發方法由于是按需求分析來做的，因此衡量一個產品是否成功在于是否很好地符合根據需求做出的計劃，是否準時和物符所值（on-time and on-cost）;

而敏捷開發則看中經濟效益——對客戶來說產品的價值是否比其投入更多，即是否物超所值。如問文章中所說：”?A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.“

　　

就個人的理解，我想或許我們可以說，迭代過程中體現出來的適應性（adaptive）是敏捷開發方法的精髓，也是它如此備受推崇的核心優勢之所在！

附：敏捷宣言的十二條原則??? ?敏捷宣言遵循的價值觀