敏捷開發都聽過吧？敏捷宣言呢？那可能就不一定了。其實做敏捷也沒必要去理會什么敏捷宣言，不過呢，如果你不知道敏捷宣言就不太好意思說你接觸過敏捷了，所以呢，還是了解一下吧，而且如果你真的靜下心來去了解，你也許會得到更深層的理解，這對你實施敏捷來說是必須的。

敏捷宣言

• 個體與交互 ? ? ? ? ? 勝過 ? ? 過程與工具
• 可以工作的軟件?? 勝過 ? ? 面面俱到的文檔
• 客戶協作?????? ? ? ?? 勝過???? 合同談判
• 響應變化???? ? ?????? 勝過???? 遵循計劃

在談敏捷方法之前就必須先對敏捷宣言有所理解，在2001年由17位世界輕量級方法學家提出了一份敏捷聯盟宣言，這個宣言只是上圖上面部分的簡單四句話，但可不要小看了，這可是敏捷方法的精髓。一般有思想的人都喜歡弄一些簡練的話，提綱挈領，也易于擴展和變化，正如敏捷個人的快樂、高效、平衡，到現在的愛學習、有目標和懂生活：）

在和一些人員交流中，我發現大家都知道敏捷，但是能說出這個簡單的敏捷宣言的并不多，即使現在知道，過不了多久也就忘記了。因為這個又不需要考試，誰吃的沒事去死記硬背這些話呢，公司也不會因為我們知道這個而漲工資。而我們又知道，這其實是敏捷開發的精髓，最好需要通過自己的思考形成自己的理解來記住這四句話。

下面我將對這四句話進行解釋，希望大家跟 隨我的講解也能對這個宣言有所認識。

合同談判　

項目開發一般都是跟隨著合同開始的，由客戶經理同客戶交談，在合同中確定一些法律條文以及交付產品包含的功能，然后客戶經理拿著合同回到公司由開發團隊完成開發后再交付給客戶使用。在開發期間，如果需要變更合同，則需要經過一系列變更流程，遇到一些客戶過程不參與，或只是簡單的詢問一下進度，有的甚至是到最后交付日了直接來問你要東西，這時產品不是他們想要的時候就麻煩大了，這可能就需要進行談判商討解決了。

僅僅通過合同談判來開發產品，客戶在開發過程中就不會進行實質性的反饋，導致最終的產品不滿意也就很正常了。也許你說你們做的產品，暫時沒有客戶使用，其實也不是這樣的，產品開發在早期市場不成熟的時候一般為公司領導（產品經理、LPDT）驅動，后期轉變為用戶驅動、銷售驅動、服務驅動，在矩陣式管理模式下，產品事業部和開發管理部作為兩個部門時，在做產品開發的時候就會類似在進行合同談判，從一開始就會在兩個部門之間產生爭執而不是合作，這勢必會影響產品的開發。

遵循計劃

當項目或產品開始之后，這時候就會組建一個開發團隊了。負責人制定出明確的計劃，詳細列出需求、設計、開發、測試、部署的各項任務，并將看似完整齊全的計劃提交給公司，公司以此不變的計劃作為對客戶的承諾。

然而軟件實在是一個太復雜的東西，業務、技術和人員是影響復雜的主要三個要素：X軸表示技術（成熟度），Y軸表示業務（一致度）：

從圖中可以看到，業務和技術是正交的，各自對復雜度都有影響，我們在開發過程中需要做的通過各種辦法盡量確保從Anarchy－Complex－Complicated－Simple進行轉移。技術和業務最終都需要人來執行，而每個人擁有不同的技能、經驗和觀點，當這些人在一起合作時又會使得開發過程變得復雜。

這些復雜性將導致開發過程中存在很多不確定性，所以項目初期制定的計劃其實基本上不能真正的堅持下來。而當項目開發遇到困難時，項目組可能會為了表明自己做計劃的能力，或者不想經歷復雜的變更過程，而繼續努力的堅持這個已經錯誤的計劃。范圍、時間和成本，這 個金三角幾乎沒有領導不知道，而項目組為了保證”遵循計劃“，對外宣稱項目組運行狀況良好，保證當前人員在預計時間肯定能保質保量的完成開發。而代碼質量 只有開發人員知道，領導們容易忽略和難以控制這個環節，所以最后一味的遵循計劃就勢必導致提供給客戶的是一個不滿意的產品。

過程與工具

計劃制定后，項目組需要在類似ISO9000、CMMI、IPD等一些常用的項目管理方法下進行開發管理，而且還需要找到很多工具來支持開發，需求階段有原型工具、需求管理跟蹤工具，設計階段有Rose、PD，開發階段有各種IDE和輔助插件等。

合適的工具能很好的幫助開發，但當在開發人員面前出現大量龐大笨重甚至不好用的工具和開發環境時，就會開始像拉著重重的行李走在沙漠一樣，效率開始降低，甚至死在路上。在開發過程中，可能會出現夸大了工具的作用，當反應說開發工具對開發起起決定性的影響時，?這很有可能是在計劃階段就開始錯了，就像衣服扣錯的時候，一般都是扣第一個扣子的時候，而不是你發現扣錯的那個扣子。

面面俱到的文檔

瀑布式開發下，文檔承載著各階段之間的信息傳遞。需求文檔中定義詳細用例，每個細節，原型中定義界面表現，甚至每個控件的具體位置，設計中的UML圖，數據庫設計圖，測試用例文檔等等，如果沒有文檔，開發將不能在過程中順利依次展開。

編寫和維護一份詳盡的需求文檔總是一個好主意，然而就像前面所說業務復雜性帶來的不確定性，除非給我們充足的時間，否則我們不可能一開始就想清楚所有細節。另一方面，編寫文檔需要花費大量的時間，如果考慮和代碼的同步時，工作量更是急速上升，如果不考慮同步時，過多的文檔反而比過少的文檔還糟。當我們花大部分時間浪費的文檔，仍舊只能以降低質量來遵循計劃的執行。

更重要的一點是，變化是永恒的真理，文檔并不能運行，寫太多了也不能用來交付。當然，大家不要看到這又走極端了，認為敏捷是不要文檔、不要規格說明書的，這個需要具體情況具體分析，切勿太偏執了

瀑布和敏捷

在我的一個敏捷開發培訓課程中，我有一張瀑布和敏捷對比的PPT可以簡要說明瀑布和敏捷的區別：

瀑布式開發是計劃驅動的，合同談判后項目組制定計劃并且遵循計劃，在過程與工具支持下通過面面俱到的文檔來定義不變的需求和其他文檔，在時間不夠時可以通過增加人員來緩解壓力。而敏捷開發是價值驅動，通過自組織團隊在短期迭代過程中不斷的交付對用后有用的功能來進行產品開發。

從上圖的正反三角形圖形可以看出兩者的驅動是不同的，雖然宣言中右項（過程與工具、面面俱到的文檔、合同談判、遵循計劃）也很有價值，但是我們認為左項（個體與交互、可以工作的軟件、客戶協作、響應變化）更有價值，同時為了防止有些人學了敏捷之后而認為右邊的沒有價值了，我會在每條說明后重申一下右邊的仍舊需要。以下我將繼續對敏捷宣言中的左項內容進行解釋。

客戶協作? 勝過?? 合同談判

尋求客戶合作的價值重于對合同的談判。軟件開發的最終目標是提供給客戶滿意的軟件，而只有客戶才更清楚怎么樣才能滿意，敏捷開發提倡客戶和開發團隊密切的在一起工作，并盡量經常行得提供反饋。各種不同的敏捷方法都會利用短期迭代，通過盡早提供軟件來達到與客戶頻繁溝通和反饋的，這也可以把問題及早暴露出來，以免隱藏的問題在后期造成更大的影響。

雖然我們致力于客戶協作，但為了雙方利益和需要仍舊需要進行合同談判。

響應變化? 勝過??? 遵循計劃

計劃趕不上變化，敏捷項目承認開發過程中的不確定性，所以不會在開發中制定長時間的復雜計劃，它們的成功都是建立在現實反饋的基礎上的。Scrum依照一組簡單實踐及規則，實施經驗性過程控制方法的檢查、適應和保證可視性等步驟，處理軟件開發項目中的復雜問題。通過迭代開發，每次迭代都是基于上一迭代的完善基礎之上進行的，通過不斷的響應變化來消除開發中的不確定性。

作出的計劃常常會出錯，面對這樣的問題，開發小組往往會走上兩個極端：要么根本不做任何規劃，要么在計劃中投入大量的精力直到自己確信計劃是正確的。不做規劃的小組對一些最基本的問題，例如“你們什么時候能完成？”以及“我們可以在6月份安排產品發布嗎？”都無法回答。而做了大量計劃的小組會自欺欺人地認為某個計劃是“正確的”。他們的計劃也許更全面，但這并不一定意味著它更準確或更有用。這兩種極端都是敏捷需要避免的，最開始漫畫所說的“我們實施敏捷，不再需要計劃和文檔了”的論調是及其錯誤的。

敏捷不是不需要計劃，相反它需要更多的規劃。不確定性是影響計劃正確的主要因素，對大部分不確定而言，在獲取知識、減少不確定性的唯一辦法是通過執行－作一些事情、構建一些東西或模擬一些東西－然后獲得反饋。許多項目管理方法是“規劃、規劃。規劃－執行”，而敏捷開發方法是“規劃－執行－調整”、“規劃－執行－調整”。一個項目的不確定性越高，敏捷開發方法對取得成功就越是至關重要，不斷學習和調整是敏捷開發的核心。

雖然我們致力于響應變化，但并不是不需要計劃了，只是變得更多規劃了。

個體與交互?? 勝過 ?? 過程與工具

方法和工具是死的，人是活的，如何沒有優秀個人和團隊協作，再強大的方法和工具都是擺設。一個使用普通工具的優秀人員會比使用優秀工具的普通人員做得更好，一個具有合作精神、自組織的團隊比通過過程規范的團隊工作得更好。敏捷項目首先擁有一個小規模但擁有各種不同職能的成員，每個成員都需要定時和團隊的其他成員一起查看團隊的整體進度，計劃下一步工作，并一起探討所遭遇問題的解決方案。自組織團隊通過個人能力和協作能力，可以自發的通過各種途徑解決開發過程中遇到的問題。

雖然我們致力于個體和交互，但并不是不需要過程與工具了。Scrum、XP等方法本身也有一些方法和過程，每日構造等敏捷實踐也需要工具的支持，需要哪些過程和工具由自組織團隊制定，而不是由領導制定。

可以工作的軟件?? 勝過 ? ? 面面俱到的文檔

在合同中有時會看到分別在需求、設計、開發、測試階段提供什么文檔，支付多少金額等內容，而這些文檔對用戶來說是不是真的有價值呢？面面俱到的文檔對客戶來說確并不重要，用戶需要的是一個能夠運行起來，能夠實質解決工作中問題的可以工作的軟件。面面俱到的文檔對開發團隊也不重要，上百頁的報告沒有人愿意寫，更沒有人愿意去讀，對開發團隊來說最好的兩份文檔就是代碼和團隊。通過頻繁的提供可以工作的軟件，我們也可以更為頻繁的搜集對產品和開發過程的反饋，保證開發小組始終是在處理最具有價值的功能，而且這些功能可以滿足用戶的需要。

雖然我們致力于提供可供做的軟件，但并不是不要文檔。我們在開發過程中仍然需要進行內部交流，?也需要和客戶交流，我們仍舊可能需要制作原型，書寫一些主要需求和算法，只要自組織團隊認為足夠就行了。

這四句價值觀用語句表達就是：

• 自組織團隊與客戶緊密協作，通過高度迭代式、增量式的軟件開發過程響應變化，并在每次迭代結束時交付經過編碼與測試的有價值的軟件

勝過

• 與客戶確定合同后在初期制定并遵循基于活動的完整計劃，在重型過程和工具指導下，通過完成大量文檔進行知識傳遞，最后交付需求

相關文章:

1. 敏捷開發培訓部分講義內容?敏捷已經不是陌生的詞了，但是對這”熟悉”的詞的理解卻有很 … 繼續閱讀 →...
2. 敏捷開發之 12條敏捷原則?前面講了敏捷開發之 4句敏捷宣言，基于此引出了12條原則，它們是敏捷實踐區別于重 … 繼續閱讀 →...
3. 不能失落的戴明?豐田公司東京總部的大廳里，有3張大照片。一張是豐田的創始人，另一張是豐田目前的總 … 繼續閱讀 →...
4. 產品管理：早期產品階段如何與客戶打交道？?做人們想要的產品必不可少的是要與客戶交談，隨之而來最大的問題就是”我 … 繼續閱讀 →...
5. 敏捷游戲：從硬幣游戲學習Scrum敏捷方法?在Scrum硬幣游戲和the-scrum-penny-game-a-modifi … 繼續閱讀 →...
6. 你的管理思維是怎樣的？?作為一名管理者，不是你的工作年限有多長，經驗足；也不是你特別的能干，沖在第一線， … 繼續閱讀 →...
7. 敏捷看板（4）- 第二塊看板?這是材價的第一塊看板，簡單但是完整 不過我想變換一下，變換的原因有以下幾個： 任 … 繼續閱讀 →...
8. 敏捷看板（7）- 如何進行故事編寫和任務拆分？?3月份我們啟動SPU搜索改版，這次改版其實相當于重做一個新的搜索，從數據庫到建索 … 繼續閱讀 →...

總結

以上是生活随笔為你收集整理的敏捷开发之 4句敏捷宣言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。