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

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

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

(資料圖片)

Agile 敏捷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“項目沒有做好，不夠敏捷”

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

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

敏捷宣言和價值觀

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

敏捷宣言：

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

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

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

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

敏捷不是三邊項目，不是邊設(shè)計、變開發(fā)、邊驗收。

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

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

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

敏捷實踐

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

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

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

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

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

迭代的用途有下面一些：

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

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

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

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

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

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

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

跨職能團隊

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

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

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

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

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

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

看板和消息輻射器

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

看板是“消息輻射器”最主要的形式?！跋⑤椛淦鳌笔侵冈趫F隊日常工作中，需要一個信息發(fā)布的公告板，這樣所有人都能及時同步獲取所有的信息。

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

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

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

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

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

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

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

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

用戶故事和待辦事項

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

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

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

這幾項原則的出發(fā)點是為了讓任務(wù)像水流一樣可以流動，不至于阻塞團隊。我們不必同時滿足這幾項原則，因為這幾項原則可能在某些條件下矛盾，而是根據(jù)情況盡可能做到這些原則。

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

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

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

估算和迭代計劃

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

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

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

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

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

在以前的項目中，非常流行使用復(fù)雜度估算，并通過斐波那鍥數(shù)列進(jìn)行遞增（這當(dāng)中的科學(xué)道理我并不知道，也可能是一種文化）；現(xiàn)在越來越多的項目回歸人天估算，因為更具有操作性。

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

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

敏捷會議

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

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

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

站會

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

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

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

昨天做了什么？今天做了什么？遇到了什么困難？工作量評估會議

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

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

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

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

迭代計劃會議

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

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

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

開卡、結(jié)卡

在敏捷會議中，非常具有儀式感的會議就是開卡、結(jié)卡（因為很多時候任務(wù)被以卡片的形式書寫并放到看板上管理的）。

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

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

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

回顧會議

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

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

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

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

總結(jié)

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

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

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

關(guān)鍵詞：