作者：薄玉桴，騰訊產品經理，關注項目管理。靈魂畫手。

?

今天你敏捷了沒有？“敏捷”在互聯網和軟件開發領域從涓涓細流逐漸演變為行業潮流，往小了說是改進了開發方法，往大了說是革了瀑布流式的命——把產品開發引向了快速迭代、小步快跑的路線上。

我們使用tapd寫 feature，流轉、跟蹤任務，言必談敏捷，然而我們是否真的走對了敏捷？

編輯注：tapd 是騰訊內部的敏捷項目管理系統。

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

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

3.設計也要介入敏捷流程？

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

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

6.盡信書，不如無書。

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

程序員說，要有敏捷

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

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

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

鹽湖城-snowbird（敏捷聯盟成立地——雪鳥滑雪場）

中文版的“敏捷宣言”。在建立于2002年3月的?http://agilemanifesto.org/?里你可以找到幾十種語言的“敏捷宣言”。

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

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

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

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

去文檔，敏捷管理者需要維護更為精細的需求池；去流程，口頭溝通成為常態，對團隊的耦合度要求更高。

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

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

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

sprint：字面意思是短跑沖刺，一個開發階段被認為是一次沖刺，一個個sprint首位相連，構成一個項目。

Scrum:指的是英式橄欖球中一股腦爭球這一戰術或行為。

scrum 即為這樣一種方式，大家一擁而上，團隊是球員，球是產品目標，人員環環相扣，圍繞著產品目標進行工作。這里面多少有點“統籌法”的影子，人員深入協作以達到最優化效果。

Product Backlog:

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

Backlog里面寫什么：

1.待開發任務。

2.任務優先級。

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

story board:

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

一個app使用情景故事版

在開發中，故事板展現所有需求的工作流

burn down chart：

燃盡圖

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

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

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

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

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

（數據來源：“2016中國開發者白皮書”）

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

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

Jira的名字來自于哥斯拉

假設我們沒有任何項目協同軟件，敏捷怎么實施？

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

敏捷工具消失了

敏捷路徑里必須有一個項目持有者，制定規劃并把握項目走向。這位產品汪我看你骨骼驚奇，你就擔負起這個責任吧。

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

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

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

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

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

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

當然不是讓你倆傻站著，你倆要開會

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

分解完成后，你得到了一個比較詳細的待開發列表。

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

會上討論什么：

1.需求討論或技術討論；

2.成員預估需求所需開發時間；

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

4.交流一下感情。

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

scrum會后你的工作：

1.整理這個sprint內的需求列表；

2.整理每個需求的預期開發時間；

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

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

5.制作一個燃盡圖。

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

故事版布局如下：

一個標準的故事版：最開始所有的小紙條都在“待開發”一欄

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

以為這就完事了？天真。

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

每日站會

站會都有什么人參加：

1.你（項目持有者）

2.SM

3.其他scrum成員

站會干什么：

1.昨天大家分別做了什么事，遇到了什么問題，如何解決或尋求解決方案；

2.昨天任務的完成狀態，剩余多少時間，是否需要進行時間修正（增加時間或減少時間），把已完成的任務流轉到下一環節（把紙條從一個item內撕下，貼到下一個item里去）；

任務進行中，小紙條的示例

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

4.交流一下感情。

站會之后你的工作：

繪制燃盡圖。

一個燃盡圖的示例：正常的sprint的任務時間是隨著sprint的進程逐漸減少的

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

任務未能燃盡；研發返工過多；測試需求淤積.....

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

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

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

三、設計師在敏捷中如何介入？

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

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

另一種思路，是把設計和測試完全納入到團隊中來，一起進行scrum的合作。

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

有請產品經理（項目持有者）出場。

很好，我們有了一個設計師

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

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

UI設計師參與到scrum會中。對于需要UI支持的需求，設計師給出一個UI制作的時間預估。項目持有者將這部分時間加到擴展小紙條上去。在一個sprint中，設計師的工作跟研發的工作分別進行。

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

一個已經完成了UI設計的小紙條示例

四、敏捷不需要文檔嗎？

一切為快服務的敏捷特別適合初創團隊使用。它能把團隊人員緊密結合在一起，高效而有序地輸出產能。而常規高效的版本輸出往往是初創團隊高速發展的第一要務。

敏捷了一段時間之后，產品進入正軌，項目拿到撥款，公司拿到投資，你們要擴大團隊規模，新入職的同事想了解下產品和技術細節，你告訴TA：

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

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

“我們是敏捷團隊。”

十幾個人八九條槍的階段之后，產品趨于穩定，團隊逐步擴大。無論從內部協調還是外部溝通上對產品流程的正規化和文檔化要求與日俱增。

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

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

一個以訛傳訛的過程

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

誰來維護文檔，怎么維護？

我們挑選幾個重要的文檔：產品文檔、概要設計、接口文檔

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

對又是你

產品文檔包括：

1.需求；

2.加入日期；

3.開發版本；

4.呈現和詳細方案

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

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

接口文檔：必要且重要。包括接口說明、字段定義、字段類型、值定義、數據上報、錯誤碼等。一般來說約定之后由接口開發者更新文檔，如果你們沒有云端存儲的能力，至少咱們人手一份，定期更新。

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

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

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

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

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

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

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

還能走敏捷嗎？

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

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

可能會發生一到多次需求討論會。

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

大項目敏捷中：

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

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

一個需要加班的sprint

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

4.別忘了文檔。

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

文末再總結本文重點：

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

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

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

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

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

（文章所有插圖為筆者手繪，版權所有）

?

原文出自騰訊云技術社區
原文鏈接https://www.qcloud.com/community/article/766331

轉載于:https://www.cnblogs.com/hongge66/p/6782897.html

總結

以上是生活随笔為你收集整理的你大概走了假敏捷：认真说说敏捷的实现和问题（手绘版）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。