二十一天說敏捷-【D1】敏捷概述

從本質上講，敏捷（Agile）並不是一種開發方法，而是一種理念。對於專案管理而言，敏捷是一個全新的術語，敏捷強調在軟體研發過程中持續性的根據使用者反饋和需求優先順序來發布新版本，不斷進行迭代，讓產品逐漸完善。

在數十年前，瀑布式專案管理是軟體研發的主流方法，在研發過程中，團隊成員將會花大把的時間和精力在專案前期去收集資源和資訊，然後基於這些去做產品設想和研發規劃。到了70年代，有先覺的研發人員發現瀑布式研發不僅在執行中各處受限，研發速度還很慢，顯然Out了。尤其到了90年代末期，開始出現駭客來搗亂，這就意味著前功盡棄、全部推倒重來，這簡直是研發的噩夢。

相比瀑布基於線性、可預測性地去開發產品，研發人員更想要能夠靈活管理使用者反饋、Bug和需求的方法。這也就是敏捷方法出來以後受歡迎的原因。

2001年2月11日至13日，在美國猶他州瓦薩奇山雪鳥滑雪勝地，17個人聚到一起交談、滑雪、休閒，當然還有聚餐。參會者們包括來自於極限程式設計、Scrum、DSDM、自適應軟體開發、水晶系列、特徵驅動開發、實效程式設計的代表們，還包括了希望找到文件驅動、重型軟體開發過程的替代品的一些推動者。他們試圖找到共識，最終的成果就是《敏捷軟體開發宣言》（Manifesto for Agile Software Development）

可以總結為：

以人為本：重視個體間的合作互動

目標導向：我們最終交付的是“可使用的軟體”，而不是一堆繁重的文件

客戶為先：理解客戶需求，與客戶合作

擁抱改變：客戶會在不斷變化需求的過程中明晰真正需要的，因此敏捷需要擁抱變化。

儘管如此，這四項價值觀並不意味著我們就該放棄工具、文件和計劃。因為它們對研發結果依然有非常重要的價值，只是相比之下，我們應該關注更核心的事物：人、產品模型、協作和迭代。

為了讓這四項原則變得簡單易懂好執行，他們又寫了敏捷開發12項原則作為指導：

1、我們最優先要做的是透過儘早的、持續的交付有價值的軟體來使客戶滿意。

規劃迭代故事時必須按照優先順序安排，為客戶先提供最有價值的功能。透過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷小組關注完成和交付具有使用者價值的功能，而不是孤立的任務。以前我們都用需求規格說明書或者用例來編寫詳細的需求，敏捷使用使用者故事來羅列需求。使用者故事是一種表示需求的輕量級技術，它沒有固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：“作為【使用者的型別】，我希望可以【能力】以便【業務價值】“。使用基於使用者故事的需求分析方法時，仍可能需要原型和編寫文件，只是工作重點更多的轉移到了口頭交流。

2、即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味著我們更瞭解市場需求。

3、經常性的交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。

迭代是受實踐框架限制的，意味著即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟體可以很好的工作，那麼交付時間越短，我們和客戶協作就越緊密，對產品質量就更有益。雖然我們多次迭代，但並不是每次迭代的結果都需要交付給使用者，敏捷開發的目標是讓他們可以交付。這意味著開發小組在每次迭代中都會增加一些功能，增加的每個功能都是經過編碼、測試，達到了可釋出的質量標準的。

另外敏捷開發專案中對開發階段沒有什麼重要的分割，沒有先期的需求階段，然後是分析階段，架構設計階段，編碼測試階段等，在專案真正開始後，每次迭代中都會同時進行所有的上述階段工作。

4、在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。

軟體專案不會依照之前設定的計劃原路執行，中間對業務的理解、軟體的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義的、頻繁 的互動，這樣就可以在早期及時的發現並解決問題。

5、圍繞被激勵起來的個人來構建專案。給他們提供所需要的環境和支援，並且信任他們能夠完成工作。

業務和技術是引起不確定的二個主要方面，人是第三個方面。而業務和技術又必須由人來執行，所以能夠激勵人來解決這些問題是解決不確定性的關鍵。只要個人的目標和團隊的目標一致，我們就需要鼓舞起每個人的積極性，以個人為中心構建專案，提供所需的環境、支援與信任。

6、在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。

在十幾或者二十幾個人組成的大團隊中，文件是一種比較合適的傳遞知識和交流的途徑。而敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），所以大量的文件交流其實並不是很經濟的做法。此時面對面的交談反而更快速有效。

7、工作的軟體是首要進度度量標準。

一般的工作都比較容易衡量任務進展，比如讓你去搬運1噸的石頭，我只要去稱一下你已經搬運的石頭重量就知道你完成多少了。而對於軟體來說，在軟體沒有編碼、測試完成之前，我們都不能因為程式碼編寫了多少行，測試用例跑了多少個就去度量這個功能是否完成了。衡量這個功能是否完成的首要標準就是這個功能可以工作了，對使用者來說已經可以應用了。

8、敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。

很多人都認為軟體開發中加班是很正常的，不加班反而不正常，我對此有點不理解，這個可能是國情所致吧。敏捷過程希望能夠可持續的進行開發，開發速度不會隨著迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態度，開發工作不應該是突擊行為。我們不能指望說突擊這個專案後就可以輕鬆了，因為完成一個專案後會接踵而來下一個專案，而只要還是拼拼的態度，下一個專案依舊會讓你的組員再次突擊。這時不知道有人會不會說，那我們就一直加班，也是“持續的開發速度”啊，這時可要注意了，持續加班只會導致人疲勞、厭倦，保持長期恆定的速度也只是一種理想而已。

9、不斷地關注優秀的技能和好的設計會增強敏捷能力。

敏捷過程有很多好的技術實踐可以加強產品敏捷能力，很多原則、模式和實踐也可以增強敏捷開發能力。

10、簡潔為本----極力減少不必要工作量的藝術。

我們不可能預期後面需求會如何變化，所以不可能一開始就構建一個完美的架構來適應以後的所有變化。敏捷團隊不會去構建明天的軟體，而把注意力放在如何透過最簡單的方法完成現在需要解決的問題。這時有人會說，我已經預計到了肯定存在哪些需求擴充套件點，我們在一開始是否需要考慮呢？這時團隊需要根據自己的理解去決定是否考慮，如果深信在明天發生了這個問題也可以輕易處理的話，那麼就最好先不考慮。

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

敏捷中有很多種實踐，大家都知道，迭代式開發是主要的實踐方法，而自組織團隊也是主要的實踐之一。在自組織團隊中，管理者不再發號施令，而是讓團隊自身尋找最佳的工作方式來完成工作。要形成一個自組織團隊其實比較難。自組織團隊的第一個要素就是必須有一個團隊，而不僅僅是一群人。一群人是一幫在一起工作的人，他們彼此之間並沒有太多的溝通，他們也並不視彼此為一體。專案一開始，我們就會組建“團隊”，但很多時候由構架師、需求人員、開發人員和測試人員組成的是一群人而已。他還認為，團隊的形成必須經歷幾個時期。在經歷了初期的磨合後，成員才會開始對團隊共同的工作理念與文化形成一個基本的認識和理解。團隊內會逐漸形成規矩，而且這些規矩是不言而喻的。比如，每個人都知道上午九點來上班，都會主動詢問別人是否需要幫助，也都會去主動和別人探討問題。如果團隊成員之間能夠達成這樣的默契，那麼這個團隊將成為一個真正高效的工作團隊。在這樣的團隊中，成員之間相互理解，工作效率非常高。在自組織團隊中，團隊成員不需要遵從別人的詳細指令。他們需要更高層次的指導，這種指導更像是一個目標，一個致力於開發出更好的軟體的目標。總之，自組織團隊是一個自動自發、有著共同目標和工作文化的團隊，這樣的團隊總是在向它的組織做出承諾。但是，實現這些承諾對於自組織團隊來說非常重要。否則，一旦出現問題，團隊成員之間就會出現信任危機。

雖然敏捷開發小組是以小組為整體來工作的，但是還是有必要指明一些承擔一定任務的角色。第一個角色是產品負責人。產品負責人的主要職責包括：確認小組所有成員都在追求一個共同的專案前景，確定功能的優先順序以便總是在處理最具有價值的功能，以及作出決定使得對專案的投入可以產生良好的回報。可以對應為以前開發中的“產品經理”。另一角色是跨職能團隊成員，這裡包括了架構師、設計師、程式設計師、需求人員、測試人員、文件編寫者等。還有一個重要角色就是團隊促進者，也被稱為專案經理、SCRUM主管、專案團隊領導或者團隊教練。敏捷開發的團隊促進者會更多的關注僕人式領導而不是管理。

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

由於很多不確定性因素會導致計劃失效，比如專案成員增減、技術應用效果、使用者需求的改變、競爭者對我們的影響等都會讓我們作出不同的反應。敏捷不是基於預定義的工作方式，而是基於經驗性的方式，對以上這些變化，小組透過不斷的反省調整來保持團隊的敏捷性。

如果我們把這些原則和遇到的問題對號入座，很快我們就會發現，這12項原則正是對應了客戶期望。比如，客戶不會關心開發文件寫的怎麼樣，他們更感興趣交付的成品能幹什麼；他們不在意你的開發計劃，他們希望你能立馬交付；昨天他們想要修個BUG，而不是等到下次版本更新。

我們總會遇到需求多樣化的客戶，而這時，敏捷能夠確保你在研發過程中始終將使用者需求作為核心。

綜上，那麼敏捷到底如何定義呢？

PMI於2018年首次出版《敏捷實踐指南》，本書是美國專案管理協會新發布的敏捷實踐標準，當中對敏捷的描述是：

敏捷是一種思維模式，由《敏捷宣言》的4條價值觀所界定，以《敏捷宣言》12原則指導，並透過各種實踐實現，敏捷實踐者根據自身需求選擇不同的實踐。

常用的敏捷實踐有：

Scrum、XP極限程式設計、水晶、DSDM動態系統開發、FDD功能驅動開發、AUP敏捷統一過程、精益、看板、OpenUP，後面的文章再做詳細介紹。