本文轉(zhuǎn)載自微信公眾號「DDD和微服務(wù)」，作者 shaogefenhao。轉(zhuǎn)載本文請聯(lián)系DDD和微服務(wù)公眾號。

進(jìn)入具體的管理工作，我們只談?wù)鎸?shí)的敏捷團(tuán)隊(duì)和問題，本文總結(jié)了敏捷實(shí)踐中最關(guān)鍵的一些概念來詮釋敏捷這個(gè)詞本身的含義。

敏捷的概念包含價(jià)值觀和原則、敏捷軟件開發(fā)具體的工作框架、常見敏捷實(shí)踐、敏捷迭代會議等內(nèi)容。

Agile 敏捷

想要弄明白敏捷是什么，首先需要弄明白敏捷這個(gè)詞本身，以及容易混淆的其它軟件開發(fā)方法的概念。例如：瀑布、RUP、精益、看板等容易被混淆的詞匯，還有被人津津樂道的小瀑布。

瀑布模型（Waterfall model）是人們最早的軟件開發(fā)方法，它的本質(zhì)是模仿制造業(yè)、建筑業(yè)的管理方式，將軟件開發(fā)過程分為若干個(gè)階段，每個(gè)階段線性、依次進(jìn)行。

瀑布模型被描述為 5 個(gè)經(jīng)典的步驟：

• 需求定義（Requirements）
• 設(shè)計(jì)（Design）
• 實(shí)現(xiàn)（Implementation）
• 集成與測試（Integration）
• 移交與維護(hù)（Maintenance）

由于固化的工作流模式，對于復(fù)雜軟件來說并不好用，在瀑布模型一出現(xiàn)就引來不少批評，甚至包括提出瀑布模型之一的 Royce。于是業(yè)界致力于探索增量式開發(fā)、迭代式開發(fā)，因此出現(xiàn)了一大堆相關(guān)方法論：水晶清透法、特性驅(qū)動(dòng)、極限編程、Scrum 等。

敏捷實(shí)際上不是某個(gè)明確的開發(fā)方法，而代表增量、迭代的一類開發(fā)方法。 由于其特征明顯區(qū)別于瀑布，說敏捷打敗了 RUP 實(shí)際上不是非常準(zhǔn)確。

在 2001 年，十七名軟件開發(fā)人員在猶他州的雪鳥度假村會面，將這些方法論概括起來，并取了一個(gè)標(biāo)志性的名稱——敏捷，同時(shí)也發(fā)布了著名的敏捷宣言。誰也料不到，當(dāng)時(shí)一個(gè)小會議，對軟件開發(fā)方法產(chǎn)生了巨大的影響。

這群人還搞了一個(gè)聯(lián)盟，將敏捷的一些詞匯做了定義，將其標(biāo)準(zhǔn)化，網(wǎng)站為：https://www.agilealliance.org/agile101/agile-glossary/

這個(gè)網(wǎng)站是目前能找到對敏捷相關(guān)詞匯最權(quán)威的網(wǎng)站。

總結(jié)一下，與瀑布瀑布代表的是嚴(yán)格遵守過程的開發(fā)風(fēng)格相對，敏捷代表增量、迭代的一類開發(fā)風(fēng)格。

在概念上，符合此類特征的軟件開發(fā)方法都可以被稱為敏捷，例如：

• Scrum
• 極限編程（XP）
• 功能驅(qū)動(dòng)開發(fā)（FDD）
• 看板
• 精益軟件開發(fā)
• RUP

但是，由于敏捷不是一個(gè)明確的開發(fā)框架，所以就經(jīng)常被當(dāng)做一個(gè)任人打扮的小姑娘。

“沒有文檔，我們這是敏捷”

“需求調(diào)整，明天上線，我們這是敏捷”

“不做規(guī)劃，做一點(diǎn)改一點(diǎn)，我們這是敏捷”

“項(xiàng)目沒有做好，不夠敏捷”

所以敏捷是一個(gè)非常寬泛的概念，很多工作框架都指敏捷（我現(xiàn)在也不知道 Thoughtworks 敏捷是指的哪一種敏捷）。在維基百科中，敏捷軟件開發(fā)被定義為：

是一種應(yīng)對快速變化需求的一種軟件開發(fā)模式，描述了一套軟件開發(fā)的價(jià)值和原則。

敏捷宣言和價(jià)值觀

在提到敏捷時(shí)，必不可少的就是敏捷宣言。敏捷宣言是雪鳥會議最具代表性的產(chǎn)出物，更像是口號性質(zhì)的內(nèi)容。

敏捷宣言：

個(gè)體和互動(dòng)：高于流程和工具。工作的軟件：高于詳盡的文檔?？蛻艉献鳎焊哂诤贤勁小ｍ憫?yīng)變化：高于遵循計(jì)劃。

參考資料：https://agilemanifesto.org/iso/zhchs/manifesto.html

敏捷宣言中有很重要一句補(bǔ)充，當(dāng)往往被人選擇性忽視：“雖然他們也很重視右邊的內(nèi)容，但是更重視左邊的內(nèi)容”。

也就是說為了實(shí)現(xiàn)左邊的目標(biāo)，我們更應(yīng)該做好右邊的內(nèi)容。所以我們應(yīng)該警惕：

敏捷不是三邊項(xiàng)目，不是邊設(shè)計(jì)、變開發(fā)、邊驗(yàn)收。

敏捷不是隨便響應(yīng)變化，沒有“紀(jì)律”和不能保持克制的團(tuán)隊(duì)無法運(yùn)行敏捷。

敏捷不是拋棄文檔、流程，而是避免形式化的文檔、流程。

敏捷不是萬能的軟件工程方法，有些流量需求更適合看板方法，甚至有些公司采用多模的方式運(yùn)行。

敏捷實(shí)踐

除此之外，一些工作實(shí)踐也往往被敏捷文化吸收了，例如結(jié)對編程、TDD 等，不過這些實(shí)踐也不一定是敏捷的專利。

敏捷中很多實(shí)踐更多的被當(dāng)做工具庫，按需實(shí)踐，很多實(shí)踐甚至需要付出巨大成本，因此在我們實(shí)際工作中都需要被裁剪。

實(shí)話說，有些被納入敏捷中的實(shí)踐在工作中并不好用，更像是皇帝的新裝。

迭代和增量式開發(fā)（IID）

迭代是敏捷開發(fā)最顯著的特征。我個(gè)人的理解為人們無法做到像瀑布模型描述的那樣準(zhǔn)確完成所有的設(shè)計(jì)，并精確實(shí)施。

迭代的用途有下面一些：

1. 響應(yīng)在開發(fā)階段接收到的最新需求和變化。
2. 我們無法精確完成所有的前期設(shè)計(jì)。
3. 不能接受在最后一刻才進(jìn)行集成。
4. 。。。

在現(xiàn)實(shí)中，迭代是一種克制和權(quán)衡。敏捷擁抱變化，但是盡量在迭代中別變化，否則固定的迭代就沒有了意義。

迭代這個(gè)話題的另外包括迭代周期是否固定、周期多長的問題。

在實(shí)踐中，迭代周期不固定非常難操作，團(tuán)隊(duì)的整體習(xí)慣難以培養(yǎng)，有點(diǎn)類似倒時(shí)差的感覺。

常見的迭代周期有一周、兩周、四周等，迭代周期越長越像瀑布，迭代周期越短越像精益，而迭代周期適中就很像 Scrum。

Scrum 一般以兩周、四周作為迭代周期，適合大部分項(xiàng)目。

其實(shí)，由于每個(gè)迭代都要重復(fù)很多活動(dòng)，迭代會增加成本。迭代在敏捷中的作用是：犧牲局部效率，減少分工，提高整體效率。

跨職能團(tuán)隊(duì)

敏捷的另外一個(gè)顯著特點(diǎn)是跨職能團(tuán)隊(duì)?？缏毮軋F(tuán)隊(duì)的意思是，不會將團(tuán)隊(duì)按照專業(yè)崗位劃分，而是將不同的角色混編到一個(gè)團(tuán)隊(duì)。

在跨職能團(tuán)隊(duì)的每個(gè)人集成起來，讓敏捷團(tuán)隊(duì)看起來像一個(gè)增強(qiáng)的開發(fā)者，團(tuán)隊(duì)和團(tuán)隊(duì)之間是原子化和去中心化的。

我對跨職能團(tuán)隊(duì)的理解是，軟件開發(fā)無法做到像生產(chǎn)型企業(yè)一樣有序傳遞信息，知識型團(tuán)隊(duì)和生產(chǎn)型團(tuán)隊(duì)有本質(zhì)差異。

舉個(gè)例子，生產(chǎn)型團(tuán)隊(duì)的加工過程都是被優(yōu)化過的固定模式，所以他們更強(qiáng)調(diào)流程、秩序，產(chǎn)品從設(shè)計(jì)部門、組裝部門、測試部門都有明確的標(biāo)準(zhǔn)、考核方式。

但是，軟件工程不是這樣的。軟件工程長期以來被比喻為建筑業(yè)、制造業(yè)，其實(shí)更像是出版業(yè)。我們無法像工廠一樣工作，幾十上百人合作編寫一部百萬字的巨著。

知識性團(tuán)隊(duì)的信息傳遞變得更加不可靠、不確定且多變，跨職能團(tuán)隊(duì)才能合作更加緊密。

看板和消息輻射器

使用看板并不是敏捷最初的特點(diǎn)，甚至不是必選項(xiàng)，看板在敏捷中作為“消息輻射器”存在。

看板是“消息輻射器”最主要的形式。“消息輻射器”是指在團(tuán)隊(duì)日常工作中，需要一個(gè)信息發(fā)布的公告板，這樣所有人都能及時(shí)同步獲取所有的信息。

一般來說常見的消息輻射器有：

• 任務(wù)看板：用來同步團(tuán)隊(duì)工作狀態(tài)和任務(wù)清單。
• 燃盡圖：用來顯示團(tuán)隊(duì)的進(jìn)度狀態(tài)，燃盡的意圖是團(tuán)隊(duì)作為一個(gè)整體，不以某個(gè)人作為進(jìn)度追溯單位，而是整體拉通看項(xiàng)目進(jìn)展。
• 流水線健康看板：展示持續(xù)集成流水線的健康狀態(tài)，避免因?yàn)闃?gòu)建失敗阻塞其它人的工作。
• 。。。

部署“消息輻射器”的意圖有：

• 團(tuán)隊(duì)保持透明，不需要對來訪者（客戶和干系人）隱藏信息。
• 團(tuán)隊(duì)內(nèi)部共享信息，不需要隱藏問題、知識和困難。

持續(xù)集成和發(fā)布

即使在迭代中，也需要避免返工和增量式構(gòu)建，因此敏捷提倡持續(xù)集成和發(fā)布。

讓軟件隨時(shí)處于集成狀態(tài)和可發(fā)布狀態(tài)。傳統(tǒng)意義上，集成需要花費(fèi)程序員一些工作和時(shí)間，但是結(jié)合持續(xù)集成工具的使用，持續(xù)集成環(huán)境被設(shè)置好后，現(xiàn)在幾乎沒有成本。

持續(xù)集成是現(xiàn)代軟件工程顯著的特點(diǎn)，讓上規(guī)模的軟件能可靠交付的保障之一，也讓團(tuán)隊(duì)有序擴(kuò)展變得可能。

用戶故事和待辦事項(xiàng)

為了做到上述實(shí)踐和期望，在敏捷中需要將任務(wù)拆分到足夠小，但是又能單獨(dú)被驗(yàn)收、測試和集成。

所以使用了用戶故事（User Story）這個(gè)概念。一個(gè)好的用戶故事需要滿足 INVEST 原則，這個(gè)原則對于其它形式的任務(wù)拆分也適用。

INVEST 分別代表以下原則：獨(dú)立性（Independent）、可協(xié)商性（Negotiable）、有價(jià)值（Valuable）、可以估算性（Estimable）、短?。⊿mall）、可測試性（Testable）。

這幾項(xiàng)原則的出發(fā)點(diǎn)是為了讓任務(wù)像水流一樣可以流動(dòng)，不至于阻塞團(tuán)隊(duì)。我們不必同時(shí)滿足這幾項(xiàng)原則，因?yàn)檫@幾項(xiàng)原則可能在某些條件下矛盾，而是根據(jù)情況盡可能做到這些原則。

其中，獨(dú)立和可被測試讓任務(wù)可以一定程度上“單件流”，這樣測試人員可以提前進(jìn)行測試；可以估算和短小是為了不阻塞其他人，并能在迭代內(nèi)部完成集成，滿足迭代周期要求；可協(xié)商性、有價(jià)值是為了能快速給客戶演示，并獲取反饋。

反之，如果一個(gè)迭代必須所有任務(wù)合并起來測試，這就像瀑布一樣整體分析、開發(fā)、提測，會帶來人員空閑、集成風(fēng)險(xiǎn)增加的問題。

將用戶故事放到團(tuán)隊(duì)的代辦清單中就叫做 Backlog。Backlog 是一種彈性空間，我們需要假定團(tuán)隊(duì)的工作速度往往不是恒定的，如果工作狀態(tài)良好就從 Backlog 中獲取任務(wù)，如果團(tuán)隊(duì)進(jìn)展不理想，就先把任務(wù)放回 Backlog。

估算和迭代計(jì)劃

單純有了用戶故事還不夠。如果我們需要計(jì)劃迭代過程，就需要任務(wù)。團(tuán)隊(duì)中的任務(wù)往往分為四類：

• 用戶故事
• 技術(shù)事項(xiàng)
• 日常工作事項(xiàng)
• Bug

團(tuán)隊(duì) Backlog 主要構(gòu)成為用戶故事、技術(shù)事項(xiàng)，可以把用戶故事進(jìn)行估算就成了任務(wù)。技術(shù)事項(xiàng)往往不滿足 INVEST 特點(diǎn)，所以常常不被看做用戶故事，特殊處理不過也需要估算工作量。

在常見的敏捷實(shí)踐中，有兩種估算形式。一種是通過人天來進(jìn)行估算，一種是通過復(fù)雜性來估算。

通過人天估算很容易理解，就是團(tuán)隊(duì)的平均水平而言，完成一項(xiàng)任務(wù)需要多少天時(shí)間。而通過復(fù)雜度估算比較復(fù)雜，需要找到一項(xiàng)可以參考的任務(wù)作為 1 個(gè)基本點(diǎn)，其它任務(wù)根據(jù)這個(gè)基本點(diǎn)來進(jìn)行估算。

在以前的項(xiàng)目中，非常流行使用復(fù)雜度估算，并通過斐波那鍥數(shù)列進(jìn)行遞增（這當(dāng)中的科學(xué)道理我并不知道，也可能是一種文化）；現(xiàn)在越來越多的項(xiàng)目回歸人天估算，因?yàn)楦哂胁僮餍浴?/p>

通過對任務(wù)的估算并結(jié)合每個(gè)迭代投入的人員數(shù)量，可以計(jì)算出這個(gè)迭代的能完成的任務(wù)量，并做合理的規(guī)劃。

畢竟制定一個(gè)永遠(yuǎn)無法完成的計(jì)劃和沒有計(jì)劃的結(jié)果類似。

敏捷會議

當(dāng)我們談?wù)撁艚輹r(shí)，另外一個(gè)方面是敏捷的會議。

敏捷中有很多會議一般以 Scrum 為代表，有很多文章都介紹過這些會議。這篇文章中，我嘗試把這些會議和具體解決的問題映射上。

和敏捷實(shí)踐相比，會議更像套路，所以需要根據(jù)實(shí)際環(huán)境裁剪制定，這也是為什么沒有一套標(biāo)準(zhǔn)的工作框架流行開的原因。

站會

站會和大家熟悉的晨會是一樣的，站立會議的目的是為了更加高效，追求盡快結(jié)束。

站會的目標(biāo)是更新每項(xiàng)任務(wù)的狀態(tài)，同步團(tuán)隊(duì)信息，發(fā)現(xiàn)和解決阻塞項(xiàng)。一般有兩種運(yùn)行模型，一種是基于任務(wù)清單更新，也可以基于參會人輪流更新。

站會陳述的模板一般為三段：

1. 昨天做了什么？
2. 今天做了什么？
3. 遇到了什么困難？

工作量評估會議

工作量評估會議和敏捷實(shí)踐中的估算對應(yīng)，是為了更好的進(jìn)行迭代計(jì)劃。

工作量估算會議的另外一個(gè)用途是對需求的進(jìn)一步澄清，在工作量評估會議之前，需要完成技術(shù)方案設(shè)計(jì)，才能有效評估出工作量。

在某些團(tuán)隊(duì)中，工作量評估會議需要全員參與并投票，并陳述差異。不過這種實(shí)踐參會成本太高，往往會被簡化為關(guān)鍵人員參與即可。

工作量評估會議發(fā)生在迭代開始之前。

迭代計(jì)劃會議

工作量評估會議完成后，項(xiàng)目經(jīng)理或者迭代經(jīng)理需要計(jì)劃下一個(gè)迭代，包括需求、人員規(guī)模、時(shí)間等內(nèi)容。

迭代計(jì)劃會議的目的是將迭代計(jì)劃和整個(gè)團(tuán)隊(duì)同步，有時(shí)候也會包含業(yè)務(wù)需求串講和同步。

迭代計(jì)劃會議往往發(fā)生在迭代前或者迭代的第一天，迭代計(jì)劃會議前需要準(zhǔn)備好所有的任務(wù)清單。

開卡、結(jié)卡

在敏捷會議中，非常具有儀式感的會議就是開卡、結(jié)卡（因?yàn)楹芏鄷r(shí)候任務(wù)被以卡片的形式書寫并放到看板上管理的）。

開卡的意思是開發(fā)人員領(lǐng)取任務(wù)時(shí)候需要找業(yè)務(wù)人員、測試人員對齊該項(xiàng)任務(wù)的內(nèi)容，所以一般由三方人員參會故被稱為 “Three Amigos”。

結(jié)卡同理，當(dāng)完成任務(wù)后，開發(fā)人員需要找到業(yè)務(wù)人員、測試人員進(jìn)行驗(yàn)收，然后該任務(wù)會流轉(zhuǎn)到下一環(huán)節(jié)。

實(shí)際上 “Three Amigos” 會占據(jù)大量的時(shí)間，但是在實(shí)踐中卻能起到非常不錯(cuò)的效果。其原因是，業(yè)務(wù)人員無法通過需求文檔將任務(wù)無歧義的傳遞清楚，認(rèn)真踐行“Three Amigos”可以澄清需求，甚至需求不清楚的情況下，開發(fā)人員可以拒絕領(lǐng)取該任務(wù)。

回顧會議

回顧其實(shí)就是復(fù)盤，回顧會議讓敏捷迭代自洽，讓其工作方式也能更新。

回顧會議往往發(fā)生在迭代結(jié)束后，通過組織全員的頭腦風(fēng)暴，主持者營造一個(gè)安全的環(huán)境下，獲取團(tuán)隊(duì)的反饋，并進(jìn)行改進(jìn)。

回顧的方式非常多，有興趣可以參考我之前的文章《用歸零的心態(tài)，做好團(tuán)隊(duì)回顧》

在敏捷中回顧會議是周期性，這一點(diǎn)和很多企業(yè)內(nèi)部的復(fù)盤會議不太一樣。敏捷中的回顧強(qiáng)調(diào)向前看，不能將其變成懲罰性質(zhì)的批評會，這樣無法起到改進(jìn)工作流程的目的。

總結(jié)

敏捷概念的開放性讓敏捷學(xué)習(xí)者和實(shí)踐者無所適從。其實(shí)很多時(shí)候，我們在談敏捷時(shí)，僅僅在談一種理念，因此這種理念可以被用到除了工作之外的很多地方。

如果要在團(tuán)隊(duì)中實(shí)踐敏捷最好選擇一個(gè)框架執(zhí)行，例如 Scrum 就是一個(gè)經(jīng)典的敏捷框架。

關(guān)于敏捷和技術(shù)管理，不僅要坐而論道，知道原理，還需要下地干活，在實(shí)踐中體會。