今天你敏捷了沒有？“敏捷”在互聯(lián)網(wǎng)和軟件開發(fā)領(lǐng)域從涓涓細(xì)流逐漸演變?yōu)樾袠I(yè)潮流，往小了說是改進(jìn)了開發(fā)方法，往大了說是革了瀑布流式的命——把產(chǎn)品開發(fā)引向了快速迭代、小步快跑的路線上。

我們使用 tapd 寫 feature，流轉(zhuǎn)、跟蹤任務(wù)，言必談敏捷，然而我們是否真的走對了敏捷？（注：tapd 是騰訊內(nèi)部的敏捷項目管理系統(tǒng)） 。

1.朋友，你聽說過敏捷么？

2.離開敏捷工具，我們怎么敏？

3.設(shè)計也要介入敏捷流程？

4.敏捷跟文檔是對立的？

5.我這有個幾百億的大項目，怎么敏？

6.盡信書，不如無書。

一、朋友，你聽說過敏捷么？

程序員說，要有敏捷

從敏捷的濫觴看去，比起方法，這玩意貌似更像一個宗教（笑）。

千禧之初，美國在計算機(jī)行業(yè)已經(jīng)走了幾十年，瀑布流、螺旋模型、快速迭代...各種各樣的軟件開發(fā)流程雨后春筍各領(lǐng)風(fēng)騷一段時間。雖然不斷變化和完善，但互聯(lián)網(wǎng)的加速發(fā)展讓傳統(tǒng)方法顯得笨重，難以快速適應(yīng)變化。有十七個程序員（程序員改變世界）在美國猶他州的一個風(fēng)景區(qū)開了個碰頭會，找到了一個團(tuán)隊耦合度高，流程極其靈活的方法，他們把它稱為agile program development。

這十七個人如同開宗立派的長老，在會議之后給自己起了個名字“敏捷聯(lián)盟”，他們不僅賦予了新方法名字，還有宣言，甚至綱領(lǐng)。

鹽湖城- snowbird（敏捷聯(lián)盟成立地——雪鳥滑雪場）

中文版的“敏捷宣言”。在建立于2002年3月的《Manifesto for Agile Software Development》里你可以找到幾十種語言的“敏捷宣言”。

另外，長老們還制定了12原則，作為福音傳播。

顯而易見，敏捷是絕對的結(jié)果導(dǎo)向，去文檔化，去流程化，高效溝通和合作是究極奧義。

看起來是個很不錯的方法，文檔不重要了，流程不重要了，大家聚在一起說一說就可以了不是嗎？太棒了，感覺可以從繁重的文書工作中解脫出來了呢。

失之東隅收之桑榆。一處的方便一定意味著另外什么地方以其他方式運行著簡化掉的部分。

去文檔，敏捷管理者需要維護(hù)更為精細(xì)的需求池；去流程，口頭溝通成為常態(tài)，對團(tuán)隊的耦合度要求更高。

胖友，這里有一份教義，你要不要聽一下。

初識敏捷，有一些概念需要了解，如果你是老司機(jī)，跳過這部分，阿敏。

agile：迅速，敏捷。這是敏捷的理念也是精髓：迅速響應(yīng)需求，快速反饋結(jié)果。agile 的引入像一股活水沖擊著老氣橫秋的瀑布流模型，速度上跑贏幾條街。

sprint：字面意思是短跑沖刺，一個開發(fā)階段被認(rèn)為是一次沖刺，一個個 sprint 首位相連，構(gòu)成一個項目。

Scrum:指的是英式橄欖球中一股腦爭球這一戰(zhàn)術(shù)或行為。

scrum 即為這樣一種方式，大家一擁而上，團(tuán)隊是球員，球是產(chǎn)品目標(biāo)，人員環(huán)環(huán)相扣，圍繞著產(chǎn)品目標(biāo)進(jìn)行工作。這里面多少有點“統(tǒng)籌法”的影子，人員深入?yún)f(xié)作以達(dá)到最優(yōu)化效果。

Product Backlog:

backlog 即需求池。待辦事項列表。

Backlog 里面寫什么：

1.待開發(fā)任務(wù)。

2.任務(wù)優(yōu)先級。

敏捷需要維護(hù)一份詳盡的需求列表。這份列表常常要求 scrum 持有人（一般是產(chǎn)品經(jīng)理）對所有待開發(fā)事項有深入了解，并且能夠把待開發(fā)事項分解成更為細(xì)致的任務(wù)（或者跟敏捷教練一起，后面我們會再次提到敏捷教練）

story board:

很多領(lǐng)域都有故事板的概念，交互領(lǐng)域里，用故事板表述用戶場景、電影領(lǐng)域里故事板用來更具體地描述分鏡。在開發(fā)領(lǐng)域，故事版是任務(wù)流轉(zhuǎn)的可視化窗口，一般有“待開發(fā)”“開發(fā)中”“待測試”“返工”“待發(fā)布”幾個區(qū)塊，所有任務(wù)由任務(wù)操作者負(fù)責(zé)流轉(zhuǎn)至于下一個步驟，這樣任何一個人項目成員都能看到任務(wù)的完成情況。

一個app使用情景故事版

在開發(fā)中，故事板展現(xiàn)所有需求的工作流

burn down chart：

燃盡圖

一個 sprint 內(nèi)，人/時是一個比較固定的值。在這個時間框架充分安排開發(fā)任務(wù)，每天進(jìn)行時間結(jié)算，繪制時間燃盡圖。項目成員通過燃盡圖獲知時間進(jìn)展，若項目燃盡所用時間與預(yù)期時間契合，則需求時間預(yù)估和安排合理，若不契合則需要在下一個 sprint 進(jìn)行調(diào)整。

名詞聽起來都玄乎乎的，很符合開宗立派的氣質(zhì)。這些概念定義了敏捷各個環(huán)節(jié)的工作，這些流程和節(jié)點是敏捷開展的基礎(chǔ)和保障。

二、離開敏捷工具，我們怎么敏？

一個誤區(qū)：我們用了敏捷管理工具，就敏捷了

隨著敏捷在行業(yè)內(nèi)的不斷融入，各種工具產(chǎn)品層出不窮。國外jira、redmine，Axosoft ，國內(nèi)的leangoo 、禪道，三大家則都有自研的工具，百度的icafe，阿里的aone，我鵝自研tapd。

（數(shù)據(jù)來源：“2016中國開發(fā)者白皮書”）

我們在 tapd 上建迭代，建需求，研發(fā)、測試等著收到需求流轉(zhuǎn)的郵件之后開始干活...任務(wù)在測試和研發(fā)之間流轉(zhuǎn)，bug 提給研發(fā)，研發(fā)解決 bug .....我們宣稱：我們敏捷化了！

我們習(xí)慣于敏捷軟件的便利，拉群解決一切，然而卻喪失了敏捷的初衷，scrum 的本意。

Jira的名字來自于哥斯拉

假設(shè)我們沒有任何項目協(xié)同軟件，敏捷怎么實施？

設(shè)定一個環(huán)境，現(xiàn)在沒有任何協(xié)同工具可用，但是所有人都坐在一起。有人站起來說，既然這樣，我們不如敏捷吧！

敏捷工具消失了

敏捷路徑里必須有一個項目持有者，制定規(guī)劃并把握項目走向。這位產(chǎn)品汪我看你骨骼驚奇，你就擔(dān)負(fù)起這個責(zé)任吧。

另外還有一個關(guān)鍵人物 SM（別想歪）。SM 全稱 scrum master，中文稱敏捷教練。一般說來，SM 需要由對技術(shù)開發(fā)以及當(dāng)前項目明晰的技術(shù)經(jīng)理擔(dān)任。

雖然缺少線上工具，但至少要準(zhǔn)備一些簡單材料：一卷雙面膠+白紙或一沓便利貼；筆，一面平坦的墻或一塊黑板。

如果還有電腦可用，excel 或者 word，甚至寫字板都可以，沒有電腦那就白紙好了，總之你得找個地方寫下你的需求池（backlog）

需求池示例(任務(wù)名稱、平臺、詳細(xì)描述、優(yōu)先級按照P0-PX逐漸遞減)

確定一個 sprint 周期的自然天。可以用月/旬/周等時間概念作為周期，我們選擇一周（五個工作日）作為一個 sprint 周期。

按照優(yōu)先級，從需求池中拉出你認(rèn)為應(yīng)該加入你們一窮二白的第一個 sprint 里面去的需求，別太貪心，大概覺得差不多一周左右的開發(fā)量就夠了。拉上SM桑單獨開一次小會。

當(dāng)然不是讓你倆傻站著，你倆要開會

你們一起通覽需求，SM 桑根據(jù)經(jīng)驗對需求先行分解一遍，比如某需求在開發(fā)層面需要分解為 ABC 三部分，這三部分就形成三個開發(fā)任務(wù)。

分解完成后，你得到了一個比較詳細(xì)的待開發(fā)列表。

正式開始一個 sprint 開始之前，產(chǎn)品、研發(fā)、測試需要一同開一次 scrum 會議，共同討論本次 sprint 的功能點。

會上討論什么：

1.需求討論或技術(shù)討論；

2.成員預(yù)估需求所需開發(fā)時間；

3.需求是否match人力時間，需求排入sprint；

4.交流一下感情。

每個任務(wù)的預(yù)估時間在最后由敏捷教練綜合判定

scrum 會后你的工作：

1.整理這個 sprint 內(nèi)的需求列表；

2.整理每個需求的預(yù)期開發(fā)時間；

3.撰寫故事版上的小紙條；

4.把小紙條貼到故事版上；

5.制作一個燃盡圖。

一個改良版的小紙條，寫明開發(fā)者、任務(wù)描述、預(yù)估時間和每日燃盡時間

故事版布局如下：

一個標(biāo)準(zhǔn)的故事版：最開始所有的小紙條都在“待開發(fā)”一欄

到此為止，你可以開始 run 起一個 sprint 。

以為這就完事了？天真。

接下來你必須來參加每日舉行的項目短會。這個環(huán)節(jié)在 agile 中非常關(guān)鍵，是 agile 的日常修煉。為了縮減會議時間，我們一般站著開——所以也叫“站會”，早上上班后或晚上下班前，抽出十到十五分鐘時間，完成它。

每日站會

站會都有什么人參加：

1.你（項目持有者）

2.SM

3.其他 scrum 成員

站會干什么：

1.昨天大家分別做了什么事，遇到了什么問題，如何解決或?qū)で蠼鉀Q方案；

2.昨天任務(wù)的完成狀態(tài)，剩余多少時間，是否需要進(jìn)行時間修正（增加時間或減少時間），把已完成的任務(wù)流轉(zhuǎn)到下一環(huán)節(jié)（把紙條從一個item內(nèi)撕下，貼到下一個item里去）；

任務(wù)進(jìn)行中，小紙條的示例

3.功能測試后是否有返工；

4.交流一下感情。

站會之后你的工作：

繪制燃盡圖。

一個燃盡圖的示例：正常的 sprint 的任務(wù)時間是隨著 sprint 的進(jìn)程逐漸減少的

周而復(fù)始，完成了一個 sprint 后，你們開了第二次 scrum 會。這時議題多了一項:復(fù)盤上一個 sprint。

任務(wù)未能燃盡；研發(fā)返工過多；測試需求淤積.....

針對問題討論解決方案，根據(jù)實際情況進(jìn)行下一個 sprint 的任務(wù)安排。

自此，我們在沒有任何敏捷工具的幫助下，開始了敏捷的旅程。

說起來agile developing 本來就是排斥文檔的作業(yè)方式，為一個小輕快的方法制作一套嚴(yán)謹(jǐn)龐大的工具，基本也算違背了元老們的初衷了吧，科科。

三、設(shè)計師在敏捷中如何介入？

我們正在使用或者聽過的一些流程方法——不單敏捷，瀑布流，迭代式，結(jié)對開發(fā)，精益開發(fā)....似乎都不關(guān)設(shè)計師什么事。既然開發(fā)團(tuán)隊抱團(tuán)敏捷了，設(shè)計，這個在產(chǎn)品流程中必不可少而工作內(nèi)容相對獨立的角色，要怎么介入敏捷呢？

一種思路是，設(shè)計擁有自己的敏捷流程。設(shè)計師作為一個 scrum 存在，以從上游獲取的需求進(jìn)行 sprint 。

另一種思路，是把設(shè)計和測試完全納入到團(tuán)隊中來，一起進(jìn)行 scrum 的合作。

這樣的話，UI工作至少要比開發(fā)工作前移至少半個 sprint 。

有請產(chǎn)品經(jīng)理（項目持有者）出場。

很好，我們有了一個設(shè)計師

項目持有者將需求分為“ UI 支持”和“非 UI 支持”兩類。我們將小紙條擴(kuò)展一下。

多出來 UI 前置部分的小紙條

U I設(shè)計師參與到 scrum 會中。對于需要 UI 支持的需求，設(shè)計師給出一個 UI 制作的時間預(yù)估。項目持有者將這部分時間加到擴(kuò)展小紙條上去。在一個 sprint 中，設(shè)計師的工作跟研發(fā)的工作分別進(jìn)行。

當(dāng)設(shè)計師將某一需求完成時，將小紙條的 UI 部分撕下，匯入到“”待開發(fā)”中去。

一個已經(jīng)完成了 UI 設(shè)計的小紙條示例

四、敏捷不需要文檔嗎？

一切為快服務(wù)的敏捷特別適合初創(chuàng)團(tuán)隊使用。它能把團(tuán)隊人員緊密結(jié)合在一起，高效而有序地輸出產(chǎn)能。而常規(guī)高效的版本輸出往往是初創(chuàng)團(tuán)隊高速發(fā)展的第一要務(wù)。

敏捷了一段時間之后，產(chǎn)品進(jìn)入正軌，項目拿到撥款，公司拿到投資，你們要擴(kuò)大團(tuán)隊規(guī)模，新入職的同事想了解下產(chǎn)品和技術(shù)細(xì)節(jié)，你告訴TA：

你要不翻下 backlog 看看？這個實現(xiàn)你要不看一下代碼？這個字段我也不記得有沒有了....你抓包看下？

新同事一臉懵逼，難道咱們沒有文檔嗎？你自豪地指出：

“我們是敏捷團(tuán)隊。”

十幾個人八九條槍的階段之后，產(chǎn)品趨于穩(wěn)定，團(tuán)隊逐步擴(kuò)大。無論從內(nèi)部協(xié)調(diào)還是外部溝通上對產(chǎn)品流程的正規(guī)化和文檔化要求與日俱增。

從短期收益上看，文檔對于敏捷開發(fā)是非必須品，并且很有可能會拖慢進(jìn)度。在一個 sprint 中，口頭溝通顯然效率更高，每個人都有精確到工時的任務(wù)，沒人有等待文檔更新的時間。強(qiáng)調(diào)文檔就等于放棄靈活性。

從長期和宏觀上看，文檔對于敏捷團(tuán)隊和敏捷的實施利大于弊——節(jié)省在一些常規(guī)問題上的溝通成本，同時降低錯誤的發(fā)生概率。對于一個將要長期實施敏捷的 團(tuán)隊來講，文檔讓后續(xù)的工作效率更高。

一個以訛傳訛的過程

這樣一個功在當(dāng)代利在千秋的好事，當(dāng)然要做。那么——

誰來維護(hù)文檔，怎么維護(hù)？

我們挑選幾個重要的文檔：產(chǎn)品文檔、概要設(shè)計、接口文檔

產(chǎn)品文檔：不好意思內(nèi)個產(chǎn)品經(jīng)理你過來下。雖然你要維護(hù) backlog 、跟 SM 分解需求、開 scrum 會、寫小紙條、開站會、畫燃盡圖、還有什么外部溝通啊，寫 PPT 啊，絞盡腦汁想規(guī)劃啊......你還得認(rèn)真把這個文檔維護(hù)好。

對又是你

產(chǎn)品文檔包括：

1.需求；

2.加入日期；

3.開發(fā)版本；

4.呈現(xiàn)和詳細(xì)方案

在非敏捷開發(fā)流程中，文檔在評審會后完善并更新，形成一個給研發(fā)參考的實現(xiàn)目標(biāo)。在敏捷中，需求本身在 sprint 周期內(nèi)不斷完善，你可以在一個 sprint 之后將文檔補(bǔ)全。

概要設(shè)計：敏捷的常規(guī)迭代中，概要設(shè)計不是一個必須的文檔。但全新項目、重構(gòu)以及重大新功能則必須輸出概要設(shè)計文檔。研發(fā) leader 責(zé)無旁貸，這個落你身上了。

接口文檔：必要且重要。包括接口說明、字段定義、字段類型、值定義、數(shù)據(jù)上報、錯誤碼等。一般來說約定之后由接口開發(fā)者更新文檔，如果你們沒有云端存儲的能力，至少咱們?nèi)耸忠环?，定期更新?/p>

長久來看，文檔是提高效率的一大利器

雖然《宣言》中明確地放低了文檔的地位（“工作的軟件大于詳盡的文檔”），敏捷強(qiáng)調(diào)互動和變化，以及對變化的及時響應(yīng)。誠然文檔恰恰做不到如此靈活。但敏捷真的完全排斥文檔嗎？

文檔的時效性和靈活性遠(yuǎn)低于口頭溝通，但卻有它實在的好處。

1.空間上，文檔傳播范圍更廣。規(guī)范化和常規(guī)化的內(nèi)容形成文檔可以大大減少溝通成本。尤其在多個系統(tǒng)協(xié)作的情況下，跨 scrum 、跨團(tuán)隊甚至跨部門的溝通時有發(fā)生，文檔的重要性和便捷性不言而喻。

2.時間上，文檔流傳性更好。團(tuán)隊不是一成不變的，有人離開有人加入。更新?lián)Q代中，新人快速了解系統(tǒng)，老兵傳承研發(fā)理念；在更大的時間跨度上，團(tuán)隊可能成為忒修斯之船，文檔的存在就是對產(chǎn)品歷程的完整追溯，你將不用他人幫助就可以了解到產(chǎn)品的大部分面貌甚至全貌。

五、大項目怎么引入敏捷？

看起來敏捷方法特別適合產(chǎn)品常規(guī)迭代。有一種可能性是，你的產(chǎn)品需要插入一個巨無霸模塊，與其說是模塊倒不如說它幾乎可以成為一個產(chǎn)品了。你想了想，這么大個項目怎么說產(chǎn)品、設(shè)計、研發(fā)、測試全情投入也得個一兩個月。

還能走敏捷嗎？

注意你的項目時間。有 deadline 的 scrum 是帶著鐐銬跳迪斯科，時間節(jié)點關(guān)乎 sprint 的大小。

大項目敏捷之前，先得不敏捷幾步。

可能會發(fā)生一到多次需求討論會。

團(tuán)隊必須不厭其煩地理解需求或修正產(chǎn)品經(jīng)理“天真的幻想”，產(chǎn)品經(jīng)理使用不斷完善的原型同團(tuán)隊進(jìn)（tao）行( jia )溝( huan )通( jia )。在最后的產(chǎn)品評審之前，至少敲定產(chǎn)品框架和大部分細(xì)節(jié)。這次評審邀請項目成員和所有協(xié)同團(tuán)隊，除了敲定的產(chǎn)品功能，技術(shù)上需要得到一些初步結(jié)論（比如“能不能做”。事實上，產(chǎn)品經(jīng)理應(yīng)該在產(chǎn)品規(guī)劃階段就知會協(xié)同團(tuán)隊將要做什么）。接下來進(jìn)行概要設(shè)計（新產(chǎn)品、重構(gòu)、重大新功能必須進(jìn)行概要設(shè)計）。技術(shù)評審邀請除設(shè)計以外的項目成員和協(xié)同團(tuán)隊參會。

大項目敏捷中：

1.將 deadline 之前的時間分解為多個 sprint 。（deadline 之前必須留出一定“出血時間”用以解決時間預(yù)估不足的任務(wù)、返工任務(wù)以及 bug )

2.將所有需求分解成任務(wù)，開一次全局 scrum 會。預(yù)估時間之后，分散任務(wù)到各個 sprint 中。在時間較緊的情況下，sprint 的容量就要相應(yīng)增加。

一個需要加班的 sprint

3.進(jìn)入敏捷流程，常規(guī) scrum 會、站會，燃盡圖，故事版。未完成任務(wù)在 scrum 會上重新預(yù)估時間，滾入新 sprint 內(nèi)，以此類推（按時完成 sprint 內(nèi)的任務(wù)是目標(biāo)。實在不行我們還有“出血時間”呢）

4.別忘了文檔。

雖然被推崇備至，但敏捷并不是完美的開發(fā)方法。敏捷的最大的優(yōu)勢是靈活，而造成敏捷問題的根源也正是靈活。

文末再總結(jié)本文重點：

1.敏捷是一種流程、方法、理念，甚至信仰。

2 用了敏捷管理軟件不一定就是敏捷。敏捷的初衷是團(tuán)隊成員能夠更加緊密地配合完成工作，線上的的流轉(zhuǎn)如果削弱了這種配合性，反倒背離了敏捷的本意。實際上只要有白板紙張和筆，你的團(tuán)隊就能開始敏捷。

4.我們敏捷了，不是不要文檔了。在外部交流多、世代跨度長的情況下，文檔的必要性顯而易見。長期的面對面溝通最終會導(dǎo)致低效，這也是敏捷缺陷的根源。

5.設(shè)計師可以完全介入到敏捷流程中，只需要做一些細(xì)心的安排。

6.大項目開發(fā)中可以走敏捷，具體問題具體分析，需要根據(jù)項目特點制定敏捷計劃。

（文章所有插圖為筆者手繪，版權(quán)所有）

原文地址：https://cloud.tencent.com/developer/article/1004881