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

我們使用 tapd 寫 feature，流轉、跟蹤任務，言必談敏捷，然而我們是否真的走對了敏捷？（注：tapd 是騰訊內部的敏捷專案管理系統） 。

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

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

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

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

5.我這有個幾百億的大專案，怎麼敏？

6.盡信書，不如無書。

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

程式設計師說，要有敏捷

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

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

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

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

另外，長老們還制定了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 前置部分的小紙條

U I設計師參與到 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 的大小。

大專案敏捷之前，先得不敏捷幾步。

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

相關推薦