[轉] 敏捷軟件開發 Agile Software Development

敏捷軟件開發 Agile software Development

　　敏捷開發是一種軟件開發方法，基於迭代和增量開發，經過自組織,跨團隊，溝通協做完成開發工做。

　　敏捷宣言的誕生：
　 　2001年2月11日到13日，17位軟件開發領域的領軍人物彙集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。通過兩天的討論，「敏捷」 （Agile）這個詞爲全體聚會者所接受，用以歸納一套全新的軟件開發價值觀。這套價值觀，經過一份簡明扼要的《敏捷宣言》，傳遞給世界，宣告了敏捷開發 運動的開始。

　　敏捷軟件開發宣言

　　咱們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此咱們創建了以下價值觀：

　　個體和互動 高於 流程和工具

　　工做的軟件 高於 詳盡的文檔

　　客戶合做 高於 合同談判

　　響應變化 高於 遵循計劃

　　也就是說，儘管右項有其價值，咱們更重視左項的價值。

　　We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
　　Individuals and interactions over processes and tools
　　Working software over comprehensive documentation
　　Customer collaboration over contract negotiation
　　Responding to change over following a plan
　　That is, while there is value in the items on the right, we value the items on the left more.

　　敏捷開發的12條準則:
　　準則1：Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
　　咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。
　 　準則2：Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
　　歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。
　 　準則3：Deliver working software frequently, from a couple of weeks to a couple of mouths, with a preference for the shorter timescale.
　　要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
　　準則4：Business people and developers must work together daily throughout the project.
　　項目過程當中，業務人員與開發人員必須在一塊兒工做。
　 　準則5：Build projects around motivated individuals. Give them the environment and support they need, and  trust them to get the job done. 
　　要善於激勵項目人員，給他們以所須要的環境和支持，並相信他們可以完成任務。
　　準則6：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
　　不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。
　　準則7：Working software is the primary measure of progress.
　　可用的軟件是衡量進度的主要指標。
　 　準則8：Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
　　敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該可以保持恆久穩定的進展速度。
　　準則9：Continuous attention to technical excellence and good design enhances agility.
　　對技術的精益求精以及對設計的不斷完善將提高敏捷性。
　　準則10：Simplicity -- the art of maximizing the amount of work not done -- is essential.
　　要作到簡潔，即盡最大可能減小沒必要要的工做。這是一門藝術。
　　準則11：The best architectures, requirements, and designs emerge from self-organizing teams. 
　　最佳的架構、需求和設計出自於自組織的團隊。
　 　準則12：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 
　　團隊要按期檢討如何可以作到更有效，並相應地調整團隊的行爲。

　　敏捷方法 Agile

　　Scrum：http://zh.wikipedia.org/wiki/Scrum

　　Scrum Role 角色

　　Product Owner, Team, ScrumMaster, Chicken and the Pig

　　產品經理，團隊，ScrumMaster，雞和豬，有一則小故事

　　Scrum Meetings

　　Sprint 計劃會議 Sprint Planning Meeting

　　需求澄清，肯定那些用戶故事須要在接下來的迭代裏完成

　　根據Product Owner制定的產品或項目計劃在Sprint的開始時作準備工做。

　　他要準備一個根據商業價值排好序的客戶需求列表。這個列表就是Prodct Backlog[需求池]，一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先級。

　　商業價值"公式"：As a <type of user> I want <some functionality> so that <some benefit>

　　每日站立會 Daliy Meeting

　　在會議上每一個團隊成員回答三個問題（During the meeting, each team member answers three questions）

　　1. 昨天你完成了那些工做?（What have you done since yesterday?）

　　2. 今每天你打算作什麼?（What are you planning to do today?）

　　3. 完成你的目標是否存在障礙?（Do you have any problems that would prevent you from accomplishing your goal?）

　　會議準時舉行（The meeting starts precisely on time.）

　　任何人均可以參加,，但只有團隊內部人員發言（All are welcome, but normally only the core roles speak.）

　　會議時長限制爲15分鐘（The meeting is timeboxed to 15 minutes.）

　　會議時間地點應該固定（The meeting should happen at the same location and same time every day）

　　評審會議（Sprint Review Meeting）
　　評審會議在每一個迭代結束後舉行，在會議上團隊演示這次迭代中完成了那些工做，通常會有相關的DEMO演示。
　 　At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

　　這個會議演示的內容應該是啓動會議上肯定的那些內容

　　During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting

　　回顧會議（Sprint Retrospective Meeting）
　　衝刺回顧會議通常限時爲3個小時（The sprint retrospective meeting is timeboxed to 3 hours.）

　　僅團隊成員參加，產品經理和ScrumMaster，產品經理選擇性參加（It is attended only by the team, the scrum master and the product owner. The product owner is optional.）。

　　會議上團隊中每一個成員須要回答兩個問題（Start the meeting by having all team members answer two questions）：

　　1. 這次衝刺中那些地方作得好?（What went well during the sprint?）

　　2. 下個迭代中那些地方能夠改進? （What could be improved in the next sprint?）

　　scrum master記錄每一個成員的答案（The scrum master writes down the team’s answers in summary form）。

　　團隊爲這些改進意見評定優先級（The team prioritizes in which order it wants to talk about the potential improvements）。

　　scrum master在回顧會議中不容許給出答案，但要鼓勵成員本身找到較好的辦法（The scrum master is not in this meeting to provide answers, but to facilitate the team’s search for better ways for the scrum process to work for it）。

　　這些改進工做能夠添加至下個迭代中，做爲一個非功能性工做，回顧會議最不擔憂的就是變化（Actionable items that can be added to the next sprint should be devised as high-priority non functional product backlog. Retrospectives that dont result in change are sterile and frustrating.）。

　　測試驅動開發（TDD/Test-Driven Development）

　　測試驅動開發不是指測試人員驅動開發人員搞開發，一開始我真這麼認爲了，實際上測試驅動開發指以測試用例爲出發點，不寫一行代碼的狀況下，編寫 單元測試，從而沒法經過，而後開始編寫代碼使之經過測試。這樣作的好處是直指目標，達到目標被視爲最高優先級，TDD的執行離不開重構，由於這種開發方式 徹底漠視設計。因此設計在開始時必定不好，經過不斷的重構達到最優的代碼，毫不會過分設計，也不會作偏。網上多半會說實踐後你會喜歡上它，它的大概流程如 下圖所示：

　　極限編程XP

　　XP是一個輕量級的、靈巧的軟件開發方法；同時它也是一個很是嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣。即任何一個軟件項 目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比 較簡單的小週期；經過積極的交流、反饋以及其它一系列的方法，開發人員和客戶能夠很是清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際狀況及 時地調整開發過程。

　　結隊編程Paring Program -即時反饋

　　http://kb.cnblogs.com/page/91650/

　　http://www.blogjava.net/moxie/archive/2006/09/14/69714.html

　　流模式（Flow）——兩個程序員共同從事一個有趣又有挑戰性的問題。

　　指導模式（Coaching）——老練的程序員在解決問題方面有經驗和知識，能夠與其餘不能有效地獨自解決問題的程序員分享。

　　看板Kanban - 工做可視化，專一於當下

　　很是軟的軟廣告：國產開源敏捷工具 - fKanban

　　http://www.cnblogs.com/a311300/archive/2010/11/18/1880776.html

　　ToDo, OnGoing, Done, Impediment

　　敏捷估算撲克 - 合理的任務分解
　　http://community.techexcel.com.cn/010DevSuite/070Agile_Scrum/010Posts/010Agile_Poker

　　http://www.csaipm.com/cost/201005101141211188.htm

　　敏捷方法中的估算應該是由團隊成員共同進行，而不是由項目經理「閉門造車」式地得出。這樣作的緣由之一是由於開發團隊是由不一樣經驗的同事組成， 對於同一個問題，經驗不一樣的人每每會給出不同的解決方案。若是能夠將全部人的能力集中到一塊兒,那麼最後對問題的求解也就八九不離十了。

　　持續集成（Continuous Integration）- 團隊協做的基礎

　　http://blog.csdn.net/tony1130/article/details/1876819

　　http://www.hansky.com.cn/cn/dokuwiki/doku.php/corp/case/digitalchina

　　什麼是持續集成（Continuous Integration）?

　　這個名詞已經在軟件開發領域持續了N年，一個比較簡單的定義以下：

　　持續集成（CI）是一種實踐，可讓團隊在持續發佈的基礎上收到反饋並進行改進，沒必要等到開發週期後期才尋找和修復缺陷。

　　單元測試Unit Test - 重構的保障

　　http://www.hudong.com/wiki/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95
　　單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。

　　敏捷測試 Agile Test

　　http://subject.csdn.net/agile-testing.htm
　　所謂敏捷測試，就是指測試遵循敏捷宣言進行，把開發做爲顧客看待。與敏捷宣言中的「個體和交互比過程和工具更有價值」同樣強調人的做用。

　　代碼重構（Reconstruction）

　　Duplicated Code（重複代碼）

　　Long Method（過長函數）

　　Large Class（過大的類）

　　Long Parameter List（過長參數列）

　　Divergent Change（發散式變化）

　　Shotgun Surgery（霰彈式修改）

　　Feature Envy（依戀情結）

　　Data Clumps（數據泥團）

　　Primitive Obsession（基本類型偏執）

　　Switch Statements（switch驚悚現身）

　　Parallel InheritanceHierarchies（平行繼承體系）

　　Lazy Class（冗贅類）

　　Speculative Generality（誇誇其談將來性）

　　Temporary Field（使人迷惑的暫時字段）

　　Message Chains（過分耦合的消息鏈）

　　Middle Man（中間人）

　　Inappropriate Intimacy（狎暱關係）

　　Alternative Classes with Different Interfaces（殊途同歸的類）

　　Incomplete Library Class（不完美的庫類）

　　Data Class（純稚的數據類）

　　Refused Bequest（被拒絕的遺贈）

　　Comments（過多的註釋）

　　Extract Method（提煉函數）

　　Inline Method（內聯函數）

　　Inline Temp（內聯臨時變量）

　　Replace Temp with Query（以查詢取代臨時變量）

　　Introduce Explaining Variable（引入解釋性變量）

　　Split Temporary Variable（分解臨時變量）

　　Remove Assignments to Parameters（移除對參數的賦值）

　　Replace Method with Method Object（以函數對象取代函數）

　　Substitute Algorithm（替換算法）

　　Move Method（搬移函數）

　　Move Field（搬移字段）

　　Extract Class（提煉類）

　　Inline Class（將類內聯化）

　　Hide Delegate（隱藏"委託關係"）

　　Remove Middle Man（移除中間人）

　　Introduce Foreign Method（引入外加函數）

　　Introduce Local Extension（引入本地擴展）

　　Self Encapsulate Field（自封裝字段）

　　Replace Data Value with Object（以對象取代數據值）

　　Change Value to Reference（將值對象改成引用對象）

　　Change Reference to Value（將引用對象改成值對象）

　　Replace Array with Object（以對象取代數組）

　　Duplicate Observed Data（複製"被監視數據"）

　　Change Unidirectional Association to Bidirectional（將單向關聯改成雙向關聯）

　　Change Bidirectional Association to Unidirectional（將雙向關聯改成單向關聯）

　　Replace Magic Number with Symbolic Constant（以字面常量取代魔法數）

　　Encapsulate Field（封裝字段）

　　Encapsulate Collection（封裝集合）

　　Replace Record with Data Class（以數據類取代記錄）

　　Replace Type Code with Class（以類取代類型碼）

　　Replace Type Code with Subclasses（以子類取代類型碼）

　　Replace Type Code with State/Strategy（以State/Strategy取代類型碼）

　　Replace Subclass with Fields（以字段取代子類）

　　Decompose Conditional（分解條件表達式）

　　Consolidate Conditional Expression（合併條件表達式）

　　Consolidate Duplicate Conditional Fragments（合併重複的條件片斷）

　　Remove Control Flag（移除控制標記）

　　Replace Nested Conditional with Guard Clauses（以衛語句取代嵌套條件表達式）

　　Replace Conditional with Polymorphism（以多態取代條件表達式）

　　Introduce Null Object（引入Null對象）

　　Introduce Assertion（引入斷言）

　　Rename Method（函數更名）

　　Add Parameter（添加參數）

　　Remove Parameter（移除參數）

　　Separate Query from Modifier（將查詢函數和修改函數分離）

　　Parameterize Method（令函數攜帶參數）

　　Replace Parameter with Explicit Methods（以明確函數取代參數）

　　Preserve Whole Object（保持對象完整）

　　Replace Parameter with Methods（以函數取代參數）

　　Introduce Parameter Object（引入參數對象）

　　Remove Setting Method（移除設值函數）

　　Hide Method（隱藏函數）

　　Replace Constructor with Factory Method（以工廠函數取代構造函數）

　　Encapsulate Downcast（封裝向下轉型）

　　Replace Error Code with Exception（以異常取代錯誤碼）

　　Replace Exception with Test（以測試取代異常）

　　Pull Up Field（字段上移）

　　Pull Up Method（函數上移）

　　Pull Up Constructor Body（構造函數本體上移）

　　Push Down Method（函數下移）

　　Push Down Field（字段下移）

　　Extract Subclass（提煉子類）

　　Extract Superclass（提煉超類）

　　Extract Interface（提煉接口）

　　Collapse Hierarchy（摺疊繼承體系）

　　Form Tem Plate Method（塑造模板函數）

　　Replace Inheritance with Delegation（以委託取代繼承）

　　Replace Delegation with Inheritance（以繼承取代委託）

　　Tease Apart Inheritance（梳理並分解繼承體系）

　　Convert Procedural Design to Objects（將過程化設計轉化爲對象設計）

　　Separate Domain from Presentation（將領域和表述/顯示分離）

　　Extract Hierarchy（提煉繼承體系）

　　代碼Review

　　不想重複說了，同單元測試同樣重要。

　　總結

　　以上是我的通過理論學習，實踐檢驗後總結的一篇文章，其中大部分觀點、素材皆來自網絡和公司敏捷活動中所得。我想要說的是，我是支持這些觀點的，我認爲這些方法論能夠很好的指導平常開發工做，可以解決實際問題，That's All。