IT工程師數位筆記本

前言

本篇文章將對敏捷軟件開發的方法論及其應用做基本介紹，將描述團隊是如何通過協作來完成共同目標的。本篇文章不僅僅適合軟件開發人員閱讀，同時也適合于團隊負責人、項目經理、產品經理、開發經理、測試人員、QA經理、QA工程師、技術文檔專員、用戶體驗設計師等任何涉及軟件交付的人員。文章重點介紹技術團隊是如何通力協作來計劃、構建和交付軟件的。但文中沒有具體代碼的編寫，也沒有對特定技術的介紹，并且也不會介紹任何微軟技術。希望這篇文章可以幫助你改善專業性和團隊的效率。

背景

Winston Royce 瀑布模型

引自 1970 年的 IEEE 論文 "Managing the Development of Large Software Systems"

該論文中闡述了，在計算機程序設計開發過程中，無論軟件的規模和復雜度如何，都會經過兩個必不可少的階段：軟件分析和編碼。而許多其他額外的開發步驟，雖然也是需要的，但卻都沒有像軟件分析與編碼一樣對最終產品作出最直接的貢獻，反而增加的開發過程的支出。

然后，Royce 介紹了需要額外的將 5 個重要的步驟添加到整個開發流程中，用于最大化地消除軟件開發中的風險：

步驟1：程序設計優先

一個軟件程序的初步設計階段，將被插入到軟件需求和軟件分析階段之間。程序設計人員將在此階段開始進行軟件整體的初步設計，包括設計、定義和指定數據處理模型，定義系統間的接口，描述輸入輸出過程，定義初步的操作步驟等。同時，開始起草易于理解和信息豐富的概述文檔，并在后續的過程中始終保持更新。

步驟2：設計文檔化

軟件開發過程管理的第一個準則就是強制對軟件開發過程進行文檔化，每一個開發階段都需要形成必要的文檔。

步驟3：過程執行兩次

保證軟件成功的第二個最重的準則是所開發的軟件產品是否是完全的從零開始。通常第一次開發的計算機程序會存在問題，而最終交付至客戶進行部署的版本，實際上已經是軟件的第二個版本。

步驟4：計劃、控制和監控軟件測試

在這個階段中，成本與進度的控制風險最高。因為軟件測試過程發生在整個項目進度的后期時刻，如果發生問題的話，備份的方案在此時的可用性最差。

步驟5：讓客戶參與

采用正式的方式讓客戶參與到項目中，是軟件過程中非常重要的一點，這樣就可以在最終交付時間點前進行承諾。

在仔細的閱讀 Royce 的論文之后發現：

• 每個階段被迭代地傳遞至下一階段
• 在軟件發布之前，整個過程需要被執行兩次
• Royce 明確的認為，如果這個過程僅執行一次，項目將會失敗

并且不幸的是，從對軟件過程結果的描述中可以看出，程序設計這個階段并沒有被限制在順序的迭代步驟中。

這些都是什么東西？

答案是：

敏捷開發本身并不是一個獨立的方法論，其涵蓋并描述了多個敏捷方法論。在 2001 年簽署的敏捷宣言中，所包含的方法論包括：Scrum、XP、Crystal、FDD 和 DSDM。其后，軟件精益實踐也呈現出了非常大的價值，并被包含在敏捷開發的方法論中。

進一步閱讀 “Agile Principles and Values, by Jeff Sutherland”

敏捷宣言的簽署者

敏捷軟件開發宣言

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

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

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

敏捷宣言遵循的 12 條原則

1. 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
2. 欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
3. 經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。
4. 業務人員和開發人員必須相互合作，項目中的每一天都不例外。
5. 激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
6. 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
7. 可工作的軟件是進度的首要度量標準。
8. 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
9. 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
10. 以簡潔為本，它是極力減少不必要工作量的藝術。
11. 最好的架構、需求和設計出自自組織團隊。
12. 團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

由于缺乏實踐指導，許多開發人員都經歷過噩夢一樣的項目。而缺乏有效的指導，會導致項目的不可預測性、錯誤的重復和工作量的浪費。客戶會因為進度的失控、預算的增長和低劣的質量而感到失望。而開發人員會因為在經歷長時間的努力后仍然產出了低質量的軟件而沮喪。

DSDM

DSDM（Dynamic Software Development Method）通過提供一個框架，考慮在整個軟件開發周期內填補一些快速應用開發（RAD：Rapid Application Development）方法的空白。DSDM 方法的主要功能有：

1. 用戶必須持續參與
2. 迭代式和增量式開發
3. 提高產品交付頻率
4. 在每個階段均進行集成測試
5. 滿足業務需求是接受產品交付的主要依據

FDD

FDD（Feature Driven Development）是一種方法論的包裝。它允許你在較高的層次應用一種方法來管理項目，并同時允許應用其他方法在較低的層次進行管理。FDD 主要關注要能夠估計工作量和進度，項目可以作為一個整體級別上匯報狀態，也可在非常細粒度的級別進行匯報。但其不會指明應用某個特定的方法來創建進度，而使其能由實施者來決定。這個概念就在于實施者需要觀察項目的狀態，確認項目的狀態如何，是否在進度范圍內，是否有偏差等。

Lean

精益思想提供了一種系統級的最優化方法，主要關注于減少浪費和改善系統整體流程的價值。精益在制造業有著豐富的歷史，并在近些年流行于軟件開發圈子中。

精益源自精益制造理論，其為實現質量、提升速度、客戶滿足等提供了一整套原則。在精益軟件開發中有 7 個原則：

1. 消除浪費
2. 內建質量于流程
3. 增強學習
4. 延遲承諾
5. 快速交付
6. 尊重和權力下放
7. 整體優化

將這些原則應用于軟件產品交付并不是最終目標。不是說“我們要精益”，而是通過使用精益原則來指導決策的制定和通過選擇技術來改進系統的整體。例如，通過 TDD（Test-Driven Development）的實踐，在軟件的構建初期即檢測其完整性，從而支持了在構建的過程中保證完整性的精益原則。

Plan

在計劃驅動的開發過程中，如果項目按照計劃來進行，則說明項目是順利的。所以在軟件開發中，其依賴于需求的穩定性，也就是明確的和確定的需求。你可能會說，需求能穩定簡直太奢侈了，基本上絕大多數的軟件項目都做不到。

在計劃驅動的方法中，如果在設計階段更改需求，則成本較低。而如果在整個構建過程啟動后再來適應需求的變更，代價將非常昂貴。所以，大部分的精力都投入在了計劃階段。而軟件開發確實與此不同，因為無法保證一定能有一個好的設計來使構建的過程可預測。

"Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard

敏捷方法正是在嘗試打破對需求穩定性的依賴，給出一個過程來適應變化。其通過適應性的計劃和演進性的設計來達成。

適應性的計劃，意味著變更貫穿整個項目周期，重新計劃和重新適應的過程非常頻繁。

演進性的設計，可以通過實施自測試代碼、持續集成、重構和簡化設計等方式來達成。

所以，一種是價值驅動的（敏捷驅動開發），而另一種是計劃驅動的（計劃驅動開發）。這不是說計劃驅動的方法沒有任何價值，而是說在敏捷驅動開發中，我們使價值更顯示地體現，并經常進行討論。

敏捷驅動和計劃驅動兩種方法均依賴于環境狀況，這也是它們的短處。而如果環境狀況問題沒有被跟蹤，有可能導致項目失敗。這其中的挑戰就是如何平衡兩種方法，進而取長補短。

Plan 與 Agile

計劃驅動開發與敏捷驅動開發之間最根本的差異有兩點。第一點是，在計劃驅動的模型中，在項目的晚期交付軟件產品的一個增量。但是在敏捷驅動模型中，每次僅交付一個較小的增量，而交付的頻率非常高。第二個區別是，順序性與并行性。在計劃驅動開發中，在一個過程成功地結束后，下一個過程才能開始。而在敏捷驅動開發中，由于計劃的過程一直在進行，所以活動是并行的。

“Plan your work, then work your Plan” by Martin Fowler and Neal Ford

• 兩種方法均提供過程、工具和技術
• 兩種方法均是嚴謹的軟件開發方法
• 每一種方法都有優勢和劣勢
• 敏捷方法可以適應多種環境狀況，而計劃驅動的方法并不擅長
• 敏捷方法仍然是一種嚴謹的軟件開發方法，但是其著重強調了過程中的不同方面
• 計劃驅動的方法更強調正式的溝通和控制
• 敏捷方法強調持續的溝通，并有能力適應變化和不確定性
• 通過高度的迭代來達成質量需求要優于通過多種質量控制門限
• 檢測工作是否正在被完成要優于當產品完成時檢測
• 從滿足客戶需要的一個目標開始要優于從預測將要交付什么產品開始

能在計劃驅動的方法中工作的很好的管理團隊，將同樣能勝任敏捷驅動的方法。
而如果管理團隊在計劃驅動的方法中就缺乏能力，在敏捷方法中也一樣。

Agile

敏捷軟件開發的原則和價值觀是，形成一種方法來幫助團隊打破傳統過程周期的膨脹，而更多的關注如何通過簡單的技術達成目標。
那么，目標到底是什么呢？

好，每個軟件開發人員和開發團隊最主要的目標就是，為雇主和客戶交付盡可能高的價值。項目的失敗就是未能交付價值。

敏捷開發的關鍵技術點在于，其將傳統瀑布模型中的 5 個步驟壓縮進了一個一周的循環周期中。其通過在迭代的周期中，不斷的交付較小的軟件增量來開發軟件系統。并且其允許開發人員在開發過程中進行軟件測試和軟件評審。快速、低成本和靈活性，就是敏捷的精髓。

"Adoption rates among IT departments are accelerating," says Phil Murphy, vice president and research director at Forrester in a 2011 report.

有很多種敏捷過程：Scrum、Crystal、BDD（Behavior-Driven Development）, TDD（Test-Driven Development）, FDD（Feature-Driven Development）, ADP（Adaptive Software Development）, XP（Extreme Programming）等等。盡管如此，眾多成功的敏捷團隊通過在這些過程中不斷的調整，已經演進出其特有的敏捷性方式。而這些改變中最常見的就是將 Scrum 和 XP 結合到一起，使用 Scrum 來管理多個團隊，每個團隊分別進行 XP 實踐。

極限編程（XP）

As developers we need to remember that XP is not the only game in town.- Pete McBreen

極限編程著重強調團隊合作，包括管理人員、客戶和開發人員。它通過 5 中基本途徑來改進軟件項目：溝通、簡單、反饋、勇氣、尊重。

根據維基百科上的定義： “Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.”

極限編程將一套簡單具體的實踐融合進敏捷開發過程中。極限編程也是一種開發軟件的常用方法。非常多的項目團隊已采納這種方式。并且其中的許多團隊已通過添加和修改過程實踐來適應過程。

• 極限編程是絕大多數敏捷方法論的祖先。
• 20世紀初期，Kent Beck 創造了極限編程理論。
• 融合過程與實踐。

Kent Beck 的基本思想是：

• 觀察高效團隊的實踐
• 推動團隊將能力發揮至極致

那么，到底 “推動團隊將能力發揮至極致” 是什么意思？是下面這張圖中描述的意思嗎？

或者

都不是，這些描述的都不是極限編程。讓我們來看看極限編程意味著什么。

極限編程包含了一組符合敏捷價值觀和原則的實踐。極限編程是一種獨立的方法，而敏捷代表一類方法。所以有很多種敏捷方法，而極限編程只是其中一個。

雖然是這樣說，但沒有任何其他一種方法能像極限編程一樣有良好的定義和作用范圍。例如，Scrum 方法大致相當于極限編程中計劃游戲實踐的部分，只是引入了整體團隊的概念。雖然細節上有所不同，但公平的說，Scrum 是極限編程的一個子集。實際上，很多 Scrum 團隊通過在過程中增加一些極限編程的實踐來擴種整體過程，例如驗收測試、結對編程、持續集成，尤其是測試驅動開發。

在所有敏捷方法中，極限編程是唯一一個方法為開發人員的日常工作提供了深入而嚴謹的規范。在這些規范中，測試驅動開發是最具革命性的。下面圖中是一些較好的極限編程實踐。

Scrum

Scrum 是一種迭代式和增量式的敏捷軟件開發框架，用于管理軟件項目、產品或應用的開發。其重點在于“它是一種靈活的、整體的產品開發策略，開發團隊作為一個工作單元整體來達成共同的目標”，這與傳統的“順序性的開發方法”是截然不同的。

• 在 1986 年，Hirotaka Takeuchi 和 Ikujiro Nonaka 首次定義 Scrum 為 “一種靈活的、整體的產品開發策略”
• 在 1995 年，Jeff Sutherland 和 Ken Schwaber 聯合發表了描述 Scrum 方法論的論文。Scrum 概念首次公布于世。

Scrum 中的角色

在一個產品的形成過程中，有三種核心的角色：

• 產品負責人（Product Owner）
• 開發團隊（Development Team）
• Scrum 教練（Scrum Master）

產品負責人

• 產品負責人代表著產品干系人，代表著客戶的聲音。
• 負責確保產品價值符合業務需求。
• 負責編寫以客戶為中心的用戶故事，并設定優先級，并添加到產品訂單（Product Backlog）中。
• Scrum 團隊必須擁有一個產品負責人，產品負責人也可以是開發團隊中的一員。
• 產品負責人與敏捷教練最好不是同一個人。

開發團隊

• 負責在每個沖刺（Sprint）結束時提供潛在的可交付的產品增量。
• 一個跨職能的小團隊，人數 3-9 人，進行具體工作（包括分析、設計、開發、測試、技術溝通、文檔等）。
• 自組織模式，盡管團隊有可能與項目管理部門直接接觸。

Scrum 教練

• 負責幫助團隊移除障礙，確保團隊能夠實現沖刺目標。
• 并非團隊領導者，但是一個負責屏蔽外界對團隊的干擾的角色。
• 確保 Scrum 過程按照其初衷使用。
• 規則的實施者，團隊的保護者，使團隊始終聚焦在具體任務上。
• 從多個視角上定義，還常被定義為仆人領袖。
• 與項目經理的區別在于，項目經理可能需要進行人員管理。
• 除此之外，不包含任何額外的職責。

Backlog

產品訂單（Product Backlog）是為一個產品維護的需求排序列表。它由產品特性、產品缺陷、非功能性需求等等構成。同時包括為成功交付可工作的軟件所需要做的任何事情。在 Scrum 中，并不需要在項目初期為所有需求制定冗長的文檔。產品訂單對于 Sprint 幾乎總是足夠的。并且，隨著產品的不斷增長和與客戶不斷的溝通，產品訂單總是在變化。

沖刺訂單（Sprint Backlog）是包含了開發團隊在下一個沖刺中所有工作的列表。團隊需要從產品訂單中的故事或特性選擇出來沖刺訂單，知道團隊感覺訂單中的工作在這個沖刺中已經足夠了。開發團隊通過提問“我們能完成這個嗎？”的方式將故事或特性添加至沖刺訂單中。

概念上講，團隊需要從最高優先級的產品訂單開始工作，然后選擇關聯的低優先級或高優先級的項。但在具體實踐中，很難看到團隊會去逐項選擇，例如，最高優先級的5項，與較低優先級的2項直接關聯。

敏捷軟件開發調查

這項調查是在2012年8月9日至11月1日之間進行的，由 VersionOne 公司贊助。通過多種多樣的軟件開發社區渠道，有 4,048 名人員參與了投票。數據由 Analysis.Net Research 公司進行分析并將其編寫成一份報告。

誰了解敏捷？

敏捷失敗的原因

采用敏捷的壁壘

采用敏捷最常見的困擾

結論

一個優秀的敏捷團隊會挑選適合他們的管理和技術實踐。在嘗試敏捷實踐時，常常有眾多敏捷無法工作的借口。那些真正懂得敏捷方法優勢的人可能已經取得了成功。而那些一直在尋找失敗原因的人，或者真的找到了癥結，要么完全放棄了努力，要么直接停止了實踐。Elisabeth Hendrickson 稱這種敏捷為“假敏捷”。

為了支持這個結論，我找到了一句名言：

"In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower

當然，最好不要總沉迷于任何給定的方法，因為公司和項目的需求和條件都在定期的發生變更，所以想要項目獲得成功，我們需要靈活地選擇項目管理的方法。沒有某種特定的方法永遠都是良方，所以這其中的技巧就是要確定哪些方法能滿足我們的工作，并不斷的加以調整以滿足個性化的需求。這才是"敏捷"的根本。

參考資料

• Manifesto for Agile Software Development
• Agile Principles, Patterns, and Practices in C# Robert C. Martin, Micah Martin
• Agile Alliance
• msdn.microsoft.com
• Martin Fowler
• pluralsight

本文翻譯自 CodeProject 網站 Monjurul Habib 的文章 "Agile software development methodologies and how to apply them."