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

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

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

(資料圖片)

Agile 敏捷

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

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

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

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

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

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

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

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

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

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

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

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

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

“沒(méi)有文檔，我們這是敏捷”

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

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

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

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

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

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

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

敏捷宣言：

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

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

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

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

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

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

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

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

敏捷實(shí)踐

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

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

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

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

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

迭代的用途有下面一些：

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

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

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

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

常見(jiàn)的迭代周期有一周、兩周、四周等，迭代周期越長(zhǎng)越像瀑布，迭代周期越短越像精益，而迭代周期適中就很像 Scrum。

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

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

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

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

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

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

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

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

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

看板和消息輻射器

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

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

一般來(lái)說(shuō)常見(jiàn)的消息輻射器有：

任務(wù)看板：用來(lái)同步團(tuán)隊(duì)工作狀態(tài)和任務(wù)清單。燃盡圖：用來(lái)顯示團(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ì)保持透明，不需要對(duì)來(lái)訪者（客戶和干系人）隱藏信息。團(tuán)隊(duì)內(nèi)部共享信息，不需要隱藏問(wèn)題、知識(shí)和困難。

持續(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)在幾乎沒(méi)有成本。

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

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

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

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

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

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

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

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

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

估算和迭代計(jì)劃

單純有了用戶故事還不夠。如果我們需要計(jì)劃迭代過(guò)程，就需要任務(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)，所以常常不被看做用戶故事，特殊處理不過(guò)也需要估算工作量。

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

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

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

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

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

敏捷會(huì)議

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

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

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

站會(huì)

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

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

站會(huì)陳述的模板一般為三段：

昨天做了什么？今天做了什么？遇到了什么困難？工作量評(píng)估會(huì)議

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

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

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

工作量評(píng)估會(huì)議發(fā)生在迭代開(kāi)始之前。

迭代計(jì)劃會(huì)議

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

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

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

開(kāi)卡、結(jié)卡

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

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

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

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

回顧會(huì)議

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

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

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

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

總結(jié)

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

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

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

關(guān)鍵詞：