《敏捷宣言》

2001年2月，17名軟件專家在美國猶他州瓦薩奇山雪鳥滑雪勝地相聚，經過幾天的討論和辯論，共同起草了《敏捷軟件開發(fā)宣言》，簡稱《敏捷宣言》。這些專家包括來自于極限編程、Scrum、DSDM、自適應軟件開發(fā)、水晶系列、特征驅動開發(fā)、實效編程的代表們。許多人已經有了自己創(chuàng)建的方法論，并開始傳播，他們都具有編寫軟件的豐富經驗，并且都在尋求文檔驅動的重量級軟件開發(fā)流程的替代方案。

敏捷宣言四大價值觀

• 個體和互動高于流程和工具。
• 工作的軟件高于詳盡的文檔。
• 客戶合作高于合同談判。
• 響應變化高于遵循計劃。

也就是說，盡管右項有其價值，但更要重視左項的價值。

伴隨著四大價值觀，敏捷宣言提供了12條原則：

1、我們最重要的目標是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意(價值優(yōu)先)。

2、欣然面對需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，通過敏捷過程掌控變化(擁抱變化)。

3、經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期(短迭代交付)。

4、業(yè)務人員和開發(fā)人員必須相互合作，項目中的每一天都不例外(業(yè)務參與)。

5、激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖?。提供所需的環(huán)境和支援，輔以信任，從而達成目標(以人為本)。

6、無論團隊內外，傳遞信息效果最好、效率也最高的方式是面對面的交談(面對面溝通)。

7、可工作的軟件是進度的首要度量標準(成果導向)。

8、敏捷過程倡導可持續(xù)開發(fā)。發(fā)起人、開發(fā)人員和用戶要能夠共同維持其步調穩(wěn)定延續(xù)(保持節(jié)奏)。

9、堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強(追求卓越)。

10、以簡潔為本，它是極力減少不必要工作量的藝術(簡單務實)。

11、最好的架構、需求和設計出自于組織團隊(團隊自組織)。

12、團隊定期地反思如何能提高成效，并相應地調整自身的行為(持續(xù)改進)。

盡管這些價值觀和原則源自于軟件行業(yè)，但至今敏捷方法的應用已擴展到許多其他的非計算機軟件開發(fā)行業(yè)，并將其發(fā)展為一種思維模式，在許多不同的實踐中體現。

敏捷軟件開發(fā)

“敏捷”是一個囊括了各種框架和方法的涵蓋性術語。它指的是符合《敏捷宣言》價值觀和原則的任何方法、技術、框架、手段或實踐。敏捷軟件開發(fā)簡稱敏捷開發(fā)，是從20世紀90年代開始逐漸引起廣泛關注的一些新型軟件開發(fā)方法，以應對快速變化的需求。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業(yè)務專家之間的緊密協作、面對面溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重人的作用。

敏捷開發(fā)的發(fā)展過程中，出現了多個不同的流派，比如：極限編程(Extreme Programming，XP)、自適應軟件開發(fā)(ASD)、動態(tài)系統(tǒng)開發(fā)方法(DSDM)、水晶方法、特性驅動開發(fā)(FDD)等，但其中的基本原則是一致的。從開發(fā)者的角度，主要特點有站立會議、看板、小版本發(fā)布、較少的文檔、注重合作、客戶參與、自動化測試、適應性計劃調整、結對編程等等。從管理者的角度，主要關注點有測試驅動開發(fā)(TDD)、持續(xù)集成(CI)、重構等等。在具體項目中，各團隊可選擇適合其項目和組織文化的不同方法和實踐。

還可以將敏捷方法視為精益方法的子集，它們都是精益方法的具體實例。

敏捷是許多方法的一個總稱

看板方法雖然是精益陣營中的一種重要方法，但人們也通常將其視為一種重要的敏捷框架，廣泛地應用于敏捷環(huán)境中。

所有這些方法都具有以下共同特征：

1、迭代式開發(fā)。即整個開發(fā)過程被分為幾個迭代周期，每個迭代周期是一個定長或不定長的時間塊每個迭代周期持續(xù)的時間一般較短，通常為一到六周。

2、增量交付。產品是在每個迭代周期結束時被逐步交付使用，而不是在整個開發(fā)過程結束的時候一次性交付使用。每次交付的都是可以被部署到用戶應用環(huán)境中被用戶使用的、能給用戶帶來即時效益和價值的產品。

3、開發(fā)團隊和用戶反饋推動產品開發(fā)。敏捷開發(fā)方法主張用戶能夠全程參與到整個開發(fā)過程中。這使需求變化和用戶反饋能被動態(tài)管理并及時集成到產品中。同時，團隊對于用戶的需求也能及時提供反饋意見。

4、持續(xù)集成。新的功能或需求變化總是盡可能頻繁地被整合到產品中。一些項目是在每個迭代周期結束的時候集成， 有些項目則每天都在這么做。

5、開發(fā)團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發(fā)團隊，是每個敏捷項目必不可少的條件。人是敏捷開發(fā)的核心。敏捷開發(fā)總是以人為中心建立開發(fā)的過程和機制，而非把過程和機制強加給人。

敏捷開發(fā)過程

敏捷開發(fā)過程

敏捷開發(fā)過程通過對頻繁交付的可交付成果的評審，團隊將能獲得更多的信息，從而在此基礎上進行計劃和重新計劃。從業(yè)務角度看，敏捷就是創(chuàng)建組織更快(早)地交付有價值的產品和靈活地響應變化的能力。

結構化的需求管理

Epic、Feature、Story、Task是用來劃分需求顆粒度的標簽，需求根據顆粒度大小按分為不同的層級。

• Epic：史詩，是項目的愿景目標。通常是對整個項目的概括性描述。
• Feature：可以帶來價值的產品功能或特性。Feature比Epic更具體形象，用戶可以感知，具有業(yè)務價值。
• Story：我們通常所說的用戶故事，User Story的簡稱。是從用戶角度對產品功能的詳細描述，承接Feature，并放入項目的待辦事項列表，動態(tài)調整。始終讓高優(yōu)先級的Story優(yōu)先交付給客戶。Story要符合INVEST原則：Independent(獨立的)、Negotiable(可討論的)、Valuable(有價值的)、Estimable(可估算的)、Small(顆粒度適中的)、Testable(可測試的)。
• Task：是團隊成員要完成的具體任務。通常將Story分配給開發(fā)人員，然后開發(fā)人員將Story分解為Task并估算相應的工時。

Epic-Feature-Stroy-Task是一種將需求進行結構化管理的方法，從上到下逐層分解并形成自下而上的依賴。在實際開發(fā)過程中，需要變換而動態(tài)調整時，要避免偏離目標方向，保證所添加的Story和Task和它們上層是有關聯的。從而保證團隊的工作是在朝著目標前進。

敏捷團隊

敏捷團隊注重快速開發(fā)產品。在實踐中，最有效的敏捷團隊往往由5到9個成員組成。理想情況下，敏捷團隊應該集中在一個團隊工作場所工作，團隊成員都為專職成員。敏捷提倡自我管理型團隊，敏捷團隊與仆人式領導一起成長，領導充分信任并支持團隊的工作方法。

特點一：自組織自管理

自組織自管理是指當團隊遇到問題的時候，團隊成員需要自己研究解決方案，自己解決問題，不需要領導的監(jiān)督，實現自我驅動。例如：如果一個團隊成員承諾8個小時完成某一項開發(fā)任務，并認領了該任務，就不需要其他人去監(jiān)督他了，自己可以主動完成任務，主動反饋問題，主動尋求幫助等等。

特點二：自適應

通過對以往項目的研發(fā)流程、技術方案、團隊協作、交付成果、客戶反饋、存在的問題等進行回顧、復盤、反思，團隊自行優(yōu)化調整，以更好地進行下一次迭代過程。

特點三：完全透明

項目進行過程中，團隊成員每天在做什么，遇到了什么問題，完成了什么任務，彼此都是清晰了解的?？梢栽诿咳照緯袀鬟f這些信息，或是在看板中展示。

常見敏捷實踐

敏捷開發(fā)過程有一些常用實踐，在實際開發(fā)過程中可以參照或有選擇性執(zhí)行。

回顧

回顧也經常稱作“復盤”、“階段性總結”，是最重要的一個實踐，原因是它可以幫助團隊從之前的產品開發(fā)工作及其過程中學習、改進和調整其過程。敏捷的原則之一是“團隊定期地反思如何能提高成效，并相應地調整自身的行為”?；仡櫩梢栽陧椖恐虚g進行，也可以在項目結束時進行。通?？梢赃x擇在這些關鍵時刻進行：

• 當團隊完成一個發(fā)布或者加入一些功能時。不一定是一個巨大的增量，可以是任何發(fā)布，無論它有多小。
• 自上次回顧以來，又過了幾周時間。
• 當團隊出現問題時，以及團隊協作完成工作不順暢時。
• 當團隊達到任何其他里程碑時。

通過回顧，針對定性的或定量的數據為依據，然后利用這些數據找到根源，設計對策，并對所有的需要改進的事項進行優(yōu)先級排序和制定行動計劃，然后團隊選擇合適數量的事項加入下一次迭代計劃。

重要的是，回顧并不是責備，而是讓團隊學習并改進。

待辦事項列表

待辦事項列表可以理解為一個需求池，我們收集到的客戶需求和反饋意見，以及團隊內部的產品規(guī)劃和反饋意見，都可以存放到需求池，并給每一項需求標注優(yōu)先級和計劃版本，以顯示預期的可交付成果序列。根據實際情況，優(yōu)先級和計劃版本也可以動態(tài)調整。依據待辦事項列表，就可以劃定下一個迭代開發(fā)的范圍。

每日站會

團隊成員利用每日站會對彼此做出小的承諾，發(fā)現問題，并確保團隊工作順利進行。需要為每日站會規(guī)定時間，比如不超出15分鐘。可以通過某種形式“過一下”看板或任務清單，團隊中的任何人都可以主持站會。

通常，在基于迭代的敏捷中，每個團隊成員都輪流回答下列問題：

• 上次站會以來我都完成了什么?
• 從現在到下一次站會，我計劃完成什么?
• 我的障礙(或風險或問題)是什么?

從這些問題得出的答案能夠讓團隊自我組織，并讓團隊成員為完成之前和整個迭代中承諾完成的工作承擔彼此的責任。

站會是為了發(fā)現存在問題，而不是解決它們。將問題記錄起來，然后創(chuàng)建另一次會議，它可以在站會之后立即召開或者選擇某個合適的時間召開，并在會上解決問題。

要鼓勵任何團隊成員主持會議而不是由項目經理或領導主持，以確保它不會變成狀態(tài)報告會議，而是作為團隊進行自我組織和相互承諾的會議。

看板

在敏捷項目管理中，團隊常用的一個工具就是白板加上便簽。我們可以把任務寫在便簽上，把白板做成待辦、處理中、已完成等泳道，然后把這些便簽貼到相應的泳道里面，每天更新各項任務的進度。團隊成員也可以根據看板清楚地了解到每項任務的進度等信息。

展示/評審

當團隊以用戶故事的形式完成特定功能時，團隊會定期展示工作成果?？催^展示后，產品負責人接受或拒絕故事。一般的指導方針是，每兩周至少展示一次團隊的工作產品，這種頻率對于大多數團隊來說是足夠的，這樣，團隊成員就可以得到反饋，防止他們朝著錯誤的方向前進。

展示/評審的作用還體現在，可以保障產品、開發(fā)和測試對需求理解一致。我們在敏捷過程中通過版本計劃評審、需求評審、設計評審、測試用例評審和開發(fā)ShowCase這幾個關鍵活動保障。版本計劃評審和需求評審中，產品經理講解版本范圍、需求及上下文關聯影響，開發(fā)和測試都會參加，如果需求理解不一致的地方就馬上溝通由產品經理把關。到測試用例評審的時候，需求細化成一個個測試用例，這樣讓開發(fā)和測試進一步深化理解需求達成一致。到開發(fā)完成功能，給測試和產品Showcase，測試和產品再一次核對開發(fā)實現功能與需求是否一致，明顯不一致的地方當場指出來，等開發(fā)人員修正后才提交給測試進行測試，這樣就能及早發(fā)現開發(fā)中的一些問題，避免帶到測試環(huán)境，提升測試的有效性。

持續(xù)集成

持續(xù)集成是指每當我們有新的代碼產出時，可以通過一種自動化的方式在服務器上進行構建、打包，進而可以發(fā)布到集成環(huán)境、測試環(huán)境或者生產環(huán)境里面。有了持續(xù)集成作為基礎，我們才能快速對代碼進行重構(所謂重構就是響應變化)、盡快收到反饋、以及頻繁發(fā)布。