敏捷宣言概覽
猶他州（Utah）的雪鳥城（Snowbird）是一個不太可能發生軟件革命的地方，它位於鹽湖城外約25英里的地方，一點都不像硅谷：既不以陽光和溫和的氣候聞名，也不是什麼科技創新中心，更沒有那麼多充滿熱情的企業家。但就在這裏，一個滑雪勝地，一羣具有反叛性的軟件開發人員於2001年2月聚集在一起，經歷了爲期三天的討論，他們制定並簽署了行業歷史上最重要的文件之一：敏捷宣言。
英文版：
We are uncovering better ways of developing software by doing it and help others do it. Through this work we come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documents
Customer collaboration over contract negotiation
Responding to changes over following a plan
That is, there is value in the item on the right, we value the items on the left more.
中文版：
我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此，我們建立了如下價值觀：
個體與交互 優於 流程與工具
可工作的軟件 優於 面面俱到的文檔
客戶協作 優於 合同談判
響應變化 優於 遵循計劃
也就是說，儘管右項有其價值，我們更重視左項的價值
以上內容出自敏捷宣言：http://agilemanifesto.org/
我身邊不少同仁對敏捷宣言中間的四句較爲熟悉，往往最容易忽略了前後兩句，久而久之，使得一些後來者曲瞭解敏捷宣言的精髓。而我恰恰覺得敏捷宣言的首、尾很重要。
第一句告訴我們敏捷方法論並不是憑空而談，它源自於截止目前的實踐積累，但它有可能沒法直接解決你現在所面臨的問題，所以不必將其神話論，盲目跟隨。你要做的是，明晰敏捷的核心，挖掘和定義清楚問題，循序漸進地在組織中引入敏捷，並且在實踐中不斷去探索更好的方法。
也就是說，儘管右項有其價值，我們更重視左項的價值 這一句起到畫龍點睛，敏捷方法論源於實踐，它應迴歸實踐，幫助我們解決實際問題，而不是一個框住我們思維的框架，淪爲思想牢籠。所以在實踐中，我們應該以開放的心態去接受右項的價值，並在探索中借用左項來幫助團隊提升效率。而不是一味着否定一邊而神話另一邊。我們應該時刻警惕這一點。
敏捷宣言解讀
以人爲本
我相信沒有比面對面交流更高效的溝通渠道了
一個人在團中的戰鬥力巔峯狀態一定是在受到足夠的尊重和信任的前提下產生的，尊重和信任激發個人內心的責任感和使命感，激發了個體的潛能。從團隊角度出發，我們應該充分尊重每個人，激發個體的鬥志給與他們所需要的環境和支持，並且相信他們能夠完成任務，在團隊內部建立彼此的信任。從個人角度出發，我們應該具備相當的專業能力，擁有較強的自管理能力，並不斷提升自己，增強挑戰困難和暴露問題的勇氣。
基於互相信任的前提，敏捷提倡自治的全功能團隊。在工作形式上，整個團隊平時坐在一起工作，從物理空間上創造了更加便捷面對面的溝通機會。在團隊職責上，團隊內部具備完成軟件交付的角色（能力），團隊所有人對軟件的質量負責，開發過程由團隊內部把控，業務價值在團隊內部快速流動並得到驗證，在任何環節都能及時獲得反饋。同時，每個角色都更容易從全局視角去思考軟件，避免了傳統部門牆模式下的視角割裂和協作障礙。
有了個體與交互，我們是否可以摒棄一切流程與工具呢？答案當然是不可以！
這裏舉一個我曾經的真實經歷：
- 公司不同的角色分佈在不同的部門。需求部門的分析師在前期會花上一個月甚至更久的時間跟客戶討論需求，編寫詳細的需求分析文檔（開發人員和設計人員不參與）。
- 需求文檔被部門經理審覈通過之後，項目管理系統進行提交。
- 我拿到需求分析文檔進行功能開發，設計部門根據需求文檔設計原型界面。
- 後期的開發過程中，當我需要一個icon的時候，我不得不在系統中提交申請，並由設計部門的項目經理審批後，設計師纔開始設計。
- 功能開發完成後，在預先的發佈時間內，由項目經理授權將軟件提交給測試部門，測試部門開始測試。
- 測試人員在系統中通過Bug跟蹤來反饋測試結果，後期開發人員和測試人員的交互主要發生在Bug跟蹤系統上。這就好比，兩個人在使用郵箱在交流一個緊急的Bug。
- 等待和返工成了後期開發的家常便飯，更低效的是，返工的時候需要反向走流程。另外，整個過程從需求分析到交給測試團隊歷時了大半年之久。
在上述流程中，每個部門各自爲政，好處是每個人在小黑屋裏能專注、"高效"地做出一個用於被審批的中間產物，壞處是缺乏整體視角，很可能是以最高的效率做了一件錯誤的事情（效率低下的終極定義）。層層審批流程在重量級的項目管理和Bug跟蹤工具下似乎運行得很良好，卻扼殺了及時溝通和調整的時機，製造了彼此之間的隔閡、大大增加了成本浪費，於組織、於個人都無益。
所以，我們要摒棄這種重流程和重工具，提倡輕量級流程和輕量級工具，而這些流程和工具又在促進個體交互。比如，我們在日常工作中會使用Trello、Jira、Keynote等工具。
價值導向
可工作的軟件最終交付物，是我們追求的核心價值，以價值爲導向也是我們每個職業人力所能及在做的事情。在交付價值的同時，如何看待過程中的文檔呢？可能就仁者見仁智者見智了。
提到文檔，"敏捷神教徒"會跳出來指責並排斥一切文檔，他們提倡開發人員應基於口頭討論後便開工，以最快的速度將業務功能實現，這是一種極端的思想，曲解了其含義。
爲客戶交付可工作的軟件是我們的核心目標，我們應該儘早交付可進行端到端測試的代碼，該目標決定了我們不應該花過多精力在面面俱到的文檔上，但這不代表我們要抵制任何文檔。實踐證明，輕量級的文檔策略有助於團隊高質量交付可工作的軟件。
在Scrum體系中，產品待辦列表和Sprint待辦列表就屬於輕量級的文檔。前者涵蓋了產品的業務價值，後者包含了指導團隊進行迭代開發的最優先的業務需求，並且在團隊內形成知識共享，促進溝通協作。這類文檔不應當省略。
在開發過程中，交互設計原型也是一種輕量級文檔，交互設計師交付可以儘早地跟團隊和客戶進行確認驗收的核心業務場景的原型，快速收集反饋。而不是一開始就將產品的所有功能界面進行分塊，然後在內容、視覺、交互上設計到非常精美的程度。
以上兩類文檔都能夠爲團隊中的個體交互提供基礎支撐，大大的提高團隊的協作效率。要不然，所有人都基於自己腦海裏的信息去交流，很可能置身戰場（舌戰）的感覺。
除了以上促進價值交付的文檔，還有如下幾類文檔也是有價值，甚至不避免的：
- 作爲交付物的一部分，比如用戶手冊，安裝指南等。
- 軟件發佈受法律監管強制要求的文檔。
- 幫助新成員快速獲取項目上下文的文檔。
- 記錄重要會議和重要決策的文檔，以便回溯。
回到實際項目中，有一類文檔會引起較多爭議，比如：Troubleshoots、開發規範、交接文檔、系統架構圖等，這類文檔更多是從項目管理的角度出發。而維護這些文檔往往會提高管理成本，這是一個博弈的過程。怎麼權衡也是需要根據不同的項目情況來定，我們要警惕的是盲目排斥一切文檔，心中拿捏一杆秤：文檔所創造的價值高於管理它的成本，它就值得去做。
客戶團隊
2015年，我去ThoughtWorks新加坡Office參與一個銀行系統的交付。當時從中國區調遣人員過去支援，一來因爲那邊人員相對較爲緊缺，二來因爲跟客戶關係處理得有些不妥，那邊同事不願意介入。近三個月的時間，軟件成功交付上線了，但從銷售那得知項目款很難要回來，後來我才知道這個項目一開始沒有簽下合同…感慨對優於合同談判踐行得不錯！
當然這是個反例。爲了避免誤解，我們需要從兩個視角去對待合同：商務視角和交付視角。從商務視角，企業與企業合作需要法律的保障，所以正常情況下需要有一份合法的合同作爲保障，這種不常見的問題更多出在管理上（新加坡總經理後被更換了）。
我們更多從交付視角來出發。ThoughtWorks作爲一家專業軟件服務提供商，我們的終極目標是幫助客戶實現他們真正想要的價值。基於業務從來都是捉摸不定的前提，在開發的過程中我們不可能固守一張死合同，遇到需求變更就談判，面紅耳赤最終只能關係破裂，導致雙輸。
我們提倡客戶團隊，客戶也作爲團隊的一分子，跟客戶建立信任的合作關係取代敵對的談判關係。因爲需求的變化往往來自客戶，這背後往往也是因爲不確定的業務模式導致。讓客戶參與進來可以在開發的過程中儘早的發現變化，從而儘早採取解決方案，避免更多的浪費，保證交付朝正確的方向前進。協作的前提是信任，客戶直接參與能夠讓客戶更清楚當前的交付狀況，增強客戶的信心以及對我們的信任，切忌採取合同互懟的下下策。
如果不能讓客戶成爲團隊的一分子，就要儘可能在其他的方面多做工作，比如提高Showcase頻率，提高跟客戶Catchup的頻率，提供一個軟件環境讓客戶始終能夠在用我們交付的系統，等等。
另外，客戶參與可以提升客戶的責任感，從而避免客戶不負責任的需求變動。
擁抱變化
在我看來，這一點道出了敏捷的精髓。我曾經給敏捷下過定義：通過高效的協作，獲取快速的反饋，以便儘早做出調整，從而減少浪費，交付更大的價值。
敏捷初衷並不是讓我們更快速地交付軟件，敏捷一詞很容易讓人們產生望文生義的聯想：敏捷就是迅速，就是快。當我們在看兩個武功相當的高手過招（非太極）的時候，除了眼花繚亂的動作（出手極快，詠春拳唯快不破），更核心的點是他們能夠根據對手的出招來快速採取應對招式。回到敏捷軟件開發，開發速度快慢與否取決於團隊成員的能力以及團隊協作的默契度等因素，所以不一定所有的敏捷團隊開發速度都會很高。而她真正的威力在於，當面臨業務需求變更的時候，敏捷開發方式讓我們能夠更早、更快的做出響應。響應變化的能力纔是她的核心競爭力，而她恰恰巧妙了抓了業務複雜性和不確定性的核心屬性。
敏捷團隊的交付速度有可能在某些特定迭代比瀑布團隊更慢，但需求發生變更時（通常一定會發生），響應變化的敏捷交付團隊很早就做出了調整，而遵循計劃的瀑布團隊極有可能是一條道走到黑，最終交付一個讓客戶想哭又哭不出來的四不像。從最終價值成果來看，敏捷開發實踐顯然更容易幫助我們實現價值最大化。
如果說我們做任何事情的終極目標是實現價值最大化，那麼敏捷的終極目標就是通過提升響應力來最小化浪費，從而最大化價值。敏捷的開發團隊能夠更快速響應業務需求的變化，敏捷的企業組織能夠更快速相應市場的變化。
變化一詞很好的描述了軟件開發的本身屬性，業務需求的不確定性給了敏捷軟件開發方法用武之地。而對於流程非常穩定不變的工作，比如富士康某條成熟的iPhone生產線，遵循計劃恐怕是更佳的選擇。
寫在最後
敏捷雖好，不要盲從，更不要迷信
敏捷開發方法有她的優勢，也有她的門檻。市面上存在不少有形無神的僞敏捷組織。他們天天站會，甚至，他們也模仿Scrum搞了個3355，但他們仍然苦於對變化的龜速響應。
我認爲敏捷更像一種文化價值的認同，相比於形式，更重要的是團隊對敏捷價值觀的理解和認同，以及指導他們做出日常行爲是否體現了尊重、勇氣、開放、承諾、專注、反饋、簡潔這些核心價值觀。在一個敏捷的團隊中，每個成員都應該擁有持續改進的心態，他們會不斷學習理解敏捷宣言的內涵，會不斷提升自己的專業技能，並能夠結合團隊實際情況採取因地制宜的敏捷實踐。
Posted by 袁慎建@ThoughtWorks
版權聲明：自由轉載•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0