深度解讀敏捷宣言
敏捷宣言概覽
英文版：
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.
中文版：
我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。由此，我們建立了如下價值觀： 個體與互動 優於 流程與工具 可工作的軟體 優於 面面俱到的文件 客戶協作 優於 合同談判 響應變化 優於 遵循計劃 也就是說，儘管右項有其價值，我們更重視左項的價值
以上內容出自敏捷宣言：ofollow,noindex" target="_blank">http://agilemanifesto.org/
我身邊不少同仁對敏捷宣言中間的四句較為熟悉，往往最容易忽略了前後兩句，久而久之，使得一些後來者曲瞭解敏捷宣言的精髓。而我恰恰覺得敏捷宣言的首、尾很重要。
第一句告訴我們敏捷方法論並不是憑空而談，它源自於截止目前的實踐積累，而它有可能沒法直接解決你現在所面臨的問題，所以不必將其神話論，盲目跟隨，說不定將來會有更高效地方式，核心是我們應不斷在實踐中去探索。
也就是說，儘管右項有其價值，我們更重視左項的價值
這一句起到畫龍點睛，敏捷方法論源自於實踐，迴歸實踐，它應該能夠幫助我們解決實際問題，而不是一個框住我們思維的框架，淪落為思想牢籠。所以在實踐中，我們應該以開放的心態去接受右項的價值，並在探索中借用左項來幫助團隊提升效率。而不是一味著否定一邊而神話另一邊。我們應該時刻警惕這一點。
敏捷宣言解讀
個體與互動 優於 流程與工具
我相信沒有比面對面交流更高效的溝通渠道了
一個人在團中的戰鬥力巔峰狀態一定是在受到足夠的尊重和信任的前提下產生的，這能夠激發個人內心的責任感和使命感，也就激發了潛能。從團隊角度出發，我們應該充分尊重每個人，激發個體的鬥志給與他們所需要的環境和支援，並且相信他們能夠完成任務 ，在團隊內部建立彼此的信任。從個人角度出發，我們應該具備相當的專業能力，擁有較強的自管理能力，並不斷提升自己，增強挑戰困難和暴露問題的勇氣。
基於互相信任的前提，敏捷提倡自治的全功能團隊。在工作形式上，整個團隊平時坐在一起工作，從物理空間上創造了更加便捷面對面的溝通機會。在團隊職責上，團隊內部具備完成軟體交付的角色（能力），團隊所有人對軟體的質量負責，開發過程由團隊內部把控，業務價值團隊內部快速流動，在任何環節都能及時獲得反饋。同時，每個角色都更容易從全域性視角去思考軟體，避免了傳統部門牆模式下的視角割裂和協作障礙。
有了個體與互動，我們是否可以摒棄一切流程與工具呢？答案當然是不可以！
這裡舉一個我曾經的真實經歷：
- 公司不同的角色分佈在不同的部門。需求部門的分析師在前期會花上一個月甚至更久的時間跟客戶討論需求，編寫詳細的需求分析文件（開發人員和設計人員不參與）。
- 需求文件被部門經理稽核通過之後，專案管理系統進行提交。
- 我拿到需求分析文件進行功能開發，設計部門根據需求文件設計原型介面。
- 後期的開發過程中，當我需要一個icon的時候，我不得不在系統中提交申請，並由設計部門的專案經理審批後，設計師才開始設計。
- 功能開發完成後，在預先的釋出時間內，由專案經理授權將軟體提交給測試部門，測試部門開始測試。
- 測試人員在系統中通過Bug跟蹤來反饋測試結果，後期開發人員和測試人員的互動主要發生在Bug跟蹤系統上。這就好比，兩個人在使用郵箱在交流一個緊急的Bug。
- 等待和返工成了後期開發的家常便飯，更低效的是，返工的時候需要反向走流程。
在上述流程中，每個部門各自為政，好處是每個人在小黑屋裡能專注、”高效”地做出一個用於被審批的中間產物，壞處是缺乏整體視角，很可能是以最高的效率做了一件錯誤的事情（效率低下的終極定義）。層層審批流程在重量級的專案管理和Bug跟蹤工具下似乎執行得很良好，卻扼殺了及時溝通和調整的時機，製造了彼此之間的隔閡、大大增加了成本浪費，於組織、於個人都無益。所以，這些是我們儘量要摒棄的。
所以我們要摒棄的是這種重流程和重工具的做法，提倡輕量級流程和輕量級工具，而這些流程和工具又在促進個體互動。比如，我們在日常工作中會使用Trello、Jira、Keynote等工具。
可工作的軟體 優於 面面俱到的文件
提到文件，”敏捷神教徒”會跳出來指責並排斥一切文件，他們提倡開發人員應基於口頭討論後便開工，以最快的速度將業務功能實現，這是一種極端的思想，曲解了其含義。
為客戶交付可工作的軟體是我們的核心目標，我們應該儘早交付可進行端到端測試的程式碼，該目標決定了我們不應該花過多精力在面面俱到的文件上，但這不代表我們要抵制任何文件。實踐證明，輕量級的文件策略有助於團隊高質量交付可工作的軟體。
在Scrum體系中，產品待辦列表和Sprint待辦列表就屬於輕量級的文件。前者涵蓋了產品的本身業務價值，後者指導團隊進行迭代開發，並且在團隊內形成知識共享，促進溝通協作。這類文件不應當省略。
在開發過程中，互動設計原型也是一種輕量級文件，互動設計師交付可以儘早地跟團隊和客戶進行確認驗收的核心業務場景的原型，快速收集反饋。而不是一開始就將產品的所有功能介面在內容、視覺、互動上分別切割，各個環節獨立設計到非常精美的程度。
以上兩類文件都能夠為團隊中的個體互動提供基礎支撐，極大的提高團隊的協作效率。要不然，所有人都基於自己腦海裡的資訊去交流，很可能置身戰場的感覺。
回到實際專案中，有一類文件會引起較多爭議，比如：問題備忘錄、開發規範、交接文件、安裝指南、系統架構圖等，這類文件更多是從專案管理的角度出發。而維護這些文件往往會提高管理成本，這是一個博弈的過程。所以怎麼權衡也是需要根據不同的專案情況來定，我們要做的是切記排斥一些文件，心中拿捏一杆秤：文件所創造的價值高於管理它的成本，它就值得去做。
客戶協作 優於 合同談判
2015年，我去ThoughtWorks新加坡Office參與一個銀行系統的交付。當時從中國區調遣人員過去支援，一來因為那邊人員相對較為緊缺，二來因為跟客戶關係處理得有些不妥，那邊同事不願意介入。近三個月的時間，軟體成功交付上線了，但從銷售那得知專案款很難要回來，後來我才知道這個專案一開始沒有簽下合同…感慨對優於合同談判踐行得不錯！
當然這是個反例。為了避免誤解，我們需要從兩個視角去對待合同：商務視角和交付視角。從商務視角，企業與企業合作需要法律的保障，所以正常情況下需要有一份合法的合同作為保障，這種不常見的問題更多出在管理上（新加坡總經理後被更換了）。
我們更多從交付視角來出發。ThoughtWorks作為一家專業軟體服務提供商，我們的終極目標是幫助客戶實現他們真正想要的價值。基於業務從來都是捉摸不定的前提，在開發的過程中我們不可能固守一張死合同，遇到需求變更就談判，面紅耳赤最終只能關係破裂，導致雙輸。
我們提倡客戶跟我們在一起。需求的變化往往來自客戶，這背後往往也是因為不確定的業務模式導致。讓客戶參與進來可以在開發的過程中儘早的發現變化，從而儘早採取解決方案，避免更多的浪費，保證交付朝正確的方向前進。協作就需要建立信任，所以有事沒事就拿合同來互懟，肯定是下下策。
如果客戶沒法在一起工作，就要儘可能在其他的方面多做工作，比如提高showcase頻率，提高跟客戶Catchup的頻率，提供一個軟體環境讓客戶始終能夠在用我們交付的系統，等等。
另外，客戶參與可以提升客戶的責任感，從而避免客戶不負責任的需求變動。
響應變化 優於 遵循計劃
在我看來，這一點道出了敏捷的精髓。我曾經這樣定義敏捷：通過高效的協作，獲取快速的反饋，從而儘早做出調整，減少浪費
待續
擴充套件
-
敏捷實踐的TDD出自極限程式設計，它提供了一種強大的思維工具Tasking。而在實踐中，人們在做Tasking時會從功能視角或者業務視角出發。開發人員往往更習慣功能視角。功能視角和業務視角，它倆的區別，猶如傳統的開發流程和敏捷開發流程的區別。前者只有在各個不同功能模組的完成疊加之後去交付業務價值，後者每次都能夠交付一個獨立的業務價值，從而儘早、更快地為客戶交付價值，獲得客戶真實有效的反饋，便於及時作出調整。
-
很多開發者在講到測試的好處的時候都會提到一點 – 測試即文件。這種說法無疑也是在強調可工作的軟體的重要性。測試時可執行的文件，它代表了我們的業務價值
歡迎找我交流，郵箱 |
ThoughtWorks 常年招聘DEV、UX、PM、BA、QA等角色，如果你對ThoughtWorks心動了，快來找我內推吧