本文轉載自微信公眾號「DDD和微服務」，作者 shaogefenhao。轉載本文請聯系DDD和微服務公眾號。
進入具體的管理工作，我們只談真實的敏捷團隊和問題，本文總結了敏捷實踐中最關鍵的一些概念來詮釋敏捷這個詞本身的含義。
敏捷的概念包含價值觀和原則、敏捷軟件開發具體的工作框架、常見敏捷實踐、敏捷迭代會議等內容。
Agile 敏捷
想要弄明白敏捷是什么，首先需要弄明白敏捷這個詞本身，以及容易混淆的其它軟件開發方法的概念。例如：瀑布、RUP、精益、看板等容易被混淆的詞匯，還有被人津津樂道的小瀑布。
瀑布模型（Waterfall model）是人們最早的軟件開發方法，它的本質是模仿制造業、建筑業的管理方式，將軟件開發過程分為若干個階段，每個階段線性、依次進行。
瀑布模型被描述為 5 個經典的步驟：
- 需求定義（Requirements）
- 設計（Design）
- 實現（Implementation）
- 集成與測試（Integration）
- 移交與維護（MAIntenance）
由于固化的工作流模式，對于復雜軟件來說并不好用，在瀑布模型一出現就引來不少批評，甚至包括提出瀑布模型之一的 Royce。于是業界致力于探索增量式開發、迭代式開發，因此出現了一大堆相關方法論：水晶清透法、特性驅動、極限編程、Scrum 等。
敏捷實際上不是某個明確的開發方法，而代表增量、迭代的一類開發方法。 由于其特征明顯區別于瀑布，說敏捷打敗了 RUP 實際上不是非常準確。
在 2001 年，十七名軟件開發人員在猶他州的雪鳥度假村會面，將這些方法論概括起來，并取了一個標志性的名稱——敏捷，同時也發布了著名的敏捷宣言。誰也料不到，當時一個小會議，對軟件開發方法產生了巨大的影響。
這群人還搞了一個聯盟，將敏捷的一些詞匯做了定義，將其標準化，網站為：https://www.agilealliance.org/agile101/agile-glossary/
這個網站是目前能找到對敏捷相關詞匯最權威的網站。
總結一下，與瀑布瀑布代表的是嚴格遵守過程的開發風格相對，敏捷代表增量、迭代的一類開發風格。
在概念上，符合此類特征的軟件開發方法都可以被稱為敏捷，例如：
- Scrum
- 極限編程（XP）
- 功能驅動開發（FDD）
- 看板
- 精益軟件開發
- RUP
但是，由于敏捷不是一個明確的開發框架，所以就經常被當做一個任人打扮的小姑娘。
“沒有文檔，我們這是敏捷”
“需求調整，明天上線，我們這是敏捷”
“不做規劃，做一點改一點，我們這是敏捷”
“項目沒有做好，不夠敏捷”
所以敏捷是一個非常寬泛的概念，很多工作框架都指敏捷（我現在也不知道 Thoughtworks 敏捷是指的哪一種敏捷）。在維基百科中，敏捷軟件開發被定義為：
是一種應對快速變化需求的一種軟件開發模式，描述了一套軟件開發的價值和原則。
敏捷宣言和價值觀
在提到敏捷時，必不可少的就是敏捷宣言。敏捷宣言是雪鳥會議最具代表性的產出物，更像是口號性質的內容。
敏捷宣言：
個體和互動：高于流程和工具。工作的軟件：高于詳盡的文檔。客戶合作：高于合同談判。響應變化：高于遵循計劃。
參考資料：https://agilemanifesto.org/iso/zhchs/manifesto.html
敏捷宣言中有很重要一句補充，當往往被人選擇性忽視：“雖然他們也很重視右邊的內容，但是更重視左邊的內容”。
也就是說為了實現左邊的目標，我們更應該做好右邊的內容。所以我們應該警惕：
敏捷不是三邊項目，不是邊設計、變開發、邊驗收。
敏捷不是隨便響應變化，沒有“紀律”和不能保持克制的團隊無法運行敏捷。
敏捷不是拋棄文檔、流程，而是避免形式化的文檔、流程。
敏捷不是萬能的軟件工程方法，有些流量需求更適合看板方法，甚至有些公司采用多模的方式運行。
敏捷實踐
除此之外，一些工作實踐也往往被敏捷文化吸收了，例如結對編程、TDD 等，不過這些實踐也不一定是敏捷的專利。
敏捷中很多實踐更多的被當做工具庫，按需實踐，很多實踐甚至需要付出巨大成本，因此在我們實際工作中都需要被裁剪。
實話說，有些被納入敏捷中的實踐在工作中并不好用，更像是皇帝的新裝。
迭代和增量式開發（IID）
迭代是敏捷開發最顯著的特征。我個人的理解為人們無法做到像瀑布模型描述的那樣準確完成所有的設計，并精確實施。
迭代的用途有下面一些：
- 響應在開發階段接收到的最新需求和變化。
- 我們無法精確完成所有的前期設計。
- 不能接受在最后一刻才進行集成。
- 。。。
在現實中，迭代是一種克制和權衡。敏捷擁抱變化，但是盡量在迭代中別變化，否則固定的迭代就沒有了意義。
迭代這個話題的另外包括迭代周期是否固定、周期多長的問題。
在實踐中，迭代周期不固定非常難操作，團隊的整體習慣難以培養，有點類似倒時差的感覺。
常見的迭代周期有一周、兩周、四周等，迭代周期越長越像瀑布，迭代周期越短越像精益，而迭代周期適中就很像 Scrum。
Scrum 一般以兩周、四周作為迭代周期，適合大部分項目。
其實，由于每個迭代都要重復很多活動，迭代會增加成本。迭代在敏捷中的作用是：犧牲局部效率，減少分工，提高整體效率。
跨職能團隊
敏捷的另外一個顯著特點是跨職能團隊。跨職能團隊的意思是，不會將團隊按照專業崗位劃分，而是將不同的角色混編到一個團隊。
在跨職能團隊的每個人集成起來，讓敏捷團隊看起來像一個增強的開發者，團隊和團隊之間是原子化和去中心化的。
我對跨職能團隊的理解是，軟件開發無法做到像生產型企業一樣有序傳遞信息，知識型團隊和生產型團隊有本質差異。
舉個例子，生產型團隊的加工過程都是被優化過的固定模式，所以他們更強調流程、秩序，產品從設計部門、組裝部門、測試部門都有明確的標準、考核方式。
但是，軟件工程不是這樣的。軟件工程長期以來被比喻為建筑業、制造業，其實更像是出版業。我們無法像工廠一樣工作，幾十上百人合作編寫一部百萬字的巨著。
知識性團隊的信息傳遞變得更加不可靠、不確定且多變，跨職能團隊才能合作更加緊密。
看板和消息輻射器
使用看板并不是敏捷最初的特點，甚至不是必選項，看板在敏捷中作為“消息輻射器”存在。
看板是“消息輻射器”最主要的形式。“消息輻射器”是指在團隊日常工作中，需要一個信息發布的公告板，這樣所有人都能及時同步獲取所有的信息。
一般來說常見的消息輻射器有：
- 任務看板：用來同步團隊工作狀態和任務清單。
- 燃盡圖：用來顯示團隊的進度狀態，燃盡的意圖是團隊作為一個整體，不以某個人作為進度追溯單位，而是整體拉通看項目進展。
- 流水線健康看板：展示持續集成流水線的健康狀態，避免因為構建失敗阻塞其它人的工作。
- 。。。
部署“消息輻射器”的意圖有：
- 團隊保持透明，不需要對來訪者（客戶和干系人）隱藏信息。
- 團隊內部共享信息，不需要隱藏問題、知識和困難。
持續集成和發布
即使在迭代中，也需要避免返工和增量式構建，因此敏捷提倡持續集成和發布。
讓軟件隨時處于集成狀態和可發布狀態。傳統意義上，集成需要花費程序員一些工作和時間，但是結合持續集成工具的使用，持續集成環境被設置好后，現在幾乎沒有成本。
持續集成是現代軟件工程顯著的特點，讓上規模的軟件能可靠交付的保障之一，也讓團隊有序擴展變得可能。
用戶故事和待辦事項
為了做到上述實踐和期望，在敏捷中需要將任務拆分到足夠小，但是又能單獨被驗收、測試和集成。
所以使用了用戶故事（User Story）這個概念。一個好的用戶故事需要滿足 INVEST 原則，這個原則對于其它形式的任務拆分也適用。
INVEST 分別代表以下原則：獨立性（Independent）、可協商性（Negotiable）、有價值（Valuable）、可以估算性（Estimable）、短小（Small）、可測試性（Testable）。
這幾項原則的出發點是為了讓任務像水流一樣可以流動，不至于阻塞團隊。我們不必同時滿足這幾項原則，因為這幾項原則可能在某些條件下矛盾，而是根據情況盡可能做到這些原則。
其中，獨立和可被測試讓任務可以一定程度上“單件流”，這樣測試人員可以提前進行測試；可以估算和短小是為了不阻塞其他人，并能在迭代內部完成集成，滿足迭代周期要求；可協商性、有價值是為了能快速給客戶演示，并獲取反饋。
反之，如果一個迭代必須所有任務合并起來測試，這就像瀑布一樣整體分析、開發、提測，會帶來人員空閑、集成風險增加的問題。
將用戶故事放到團隊的代辦清單中就叫做 Backlog。Backlog 是一種彈性空間，我們需要假定團隊的工作速度往往不是恒定的，如果工作狀態良好就從 Backlog 中獲取任務，如果團隊進展不理想，就先把任務放回 Backlog。
估算和迭代計劃
單純有了用戶故事還不夠。如果我們需要計劃迭代過程，就需要任務。團隊中的任務往往分為四類：
- 用戶故事
- 技術事項
- 日常工作事項
- Bug
團隊 Backlog 主要構成為用戶故事、技術事項，可以把用戶故事進行估算就成了任務。技術事項往往不滿足 INVEST 特點，所以常常不被看做用戶故事，特殊處理不過也需要估算工作量。
在常見的敏捷實踐中，有兩種估算形式。一種是通過人天來進行估算，一種是通過復雜性來估算。
通過人天估算很容易理解，就是團隊的平均水平而言，完成一項任務需要多少天時間。而通過復雜度估算比較復雜，需要找到一項可以參考的任務作為 1 個基本點，其它任務根據這個基本點來進行估算。
在以前的項目中，非常流行使用復雜度估算，并通過斐波那鍥數列進行遞增（這當中的科學道理我并不知道，也可能是一種文化）；現在越來越多的項目回歸人天估算，因為更具有操作性。
通過對任務的估算并結合每個迭代投入的人員數量，可以計算出這個迭代的能完成的任務量，并做合理的規劃。
畢竟制定一個永遠無法完成的計劃和沒有計劃的結果類似。
敏捷會議
當我們談論敏捷時，另外一個方面是敏捷的會議。
敏捷中有很多會議一般以 Scrum 為代表，有很多文章都介紹過這些會議。這篇文章中，我嘗試把這些會議和具體解決的問題映射上。
和敏捷實踐相比，會議更像套路，所以需要根據實際環境裁剪制定，這也是為什么沒有一套標準的工作框架流行開的原因。
站會
站會和大家熟悉的晨會是一樣的，站立會議的目的是為了更加高效，追求盡快結束。
站會的目標是更新每項任務的狀態，同步團隊信息，發現和解決阻塞項。一般有兩種運行模型，一種是基于任務清單更新，也可以基于參會人輪流更新。
站會陳述的模板一般為三段：
- 昨天做了什么？
- 今天做了什么？
- 遇到了什么困難？
工作量評估會議
工作量評估會議和敏捷實踐中的估算對應，是為了更好的進行迭代計劃。
工作量估算會議的另外一個用途是對需求的進一步澄清，在工作量評估會議之前，需要完成技術方案設計，才能有效評估出工作量。
在某些團隊中，工作量評估會議需要全員參與并投票，并陳述差異。不過這種實踐參會成本太高，往往會被簡化為關鍵人員參與即可。
工作量評估會議發生在迭代開始之前。
迭代計劃會議
工作量評估會議完成后，項目經理或者迭代經理需要計劃下一個迭代，包括需求、人員規模、時間等內容。
迭代計劃會議的目的是將迭代計劃和整個團隊同步，有時候也會包含業務需求串講和同步。
迭代計劃會議往往發生在迭代前或者迭代的第一天，迭代計劃會議前需要準備好所有的任務清單。
開卡、結卡
在敏捷會議中，非常具有儀式感的會議就是開卡、結卡（因為很多時候任務被以卡片的形式書寫并放到看板上管理的）。
開卡的意思是開發人員領取任務時候需要找業務人員、測試人員對齊該項任務的內容，所以一般由三方人員參會故被稱為 “Three Amigos”。
結卡同理，當完成任務后，開發人員需要找到業務人員、測試人員進行驗收，然后該任務會流轉到下一環節。
實際上 “Three Amigos” 會占據大量的時間，但是在實踐中卻能起到非常不錯的效果。其原因是，業務人員無法通過需求文檔將任務無歧義的傳遞清楚，認真踐行“Three Amigos”可以澄清需求，甚至需求不清楚的情況下，開發人員可以拒絕領取該任務。
回顧會議
回顧其實就是復盤，回顧會議讓敏捷迭代自洽，讓其工作方式也能更新。
回顧會議往往發生在迭代結束后，通過組織全員的頭腦風暴，主持者營造一個安全的環境下，獲取團隊的反饋，并進行改進。
回顧的方式非常多，有興趣可以參考我之前的文章《用歸零的心態，做好團隊回顧》
在敏捷中回顧會議是周期性，這一點和很多企業內部的復盤會議不太一樣。敏捷中的回顧強調向前看，不能將其變成懲罰性質的批評會，這樣無法起到改進工作流程的目的。
總結
敏捷概念的開放性讓敏捷學習者和實踐者無所適從。其實很多時候，我們在談敏捷時，僅僅在談一種理念，因此這種理念可以被用到除了工作之外的很多地方。
如果要在團隊中實踐敏捷最好選擇一個框架執行，例如 Scrum 就是一個經典的敏捷框架。
關于敏捷和技術管理，不僅要坐而論道，知道原理，還需要下地干活，在實踐中體會。
