你大概走了假敏捷：《手繪敏捷寶典》在此，還不來收！

時間 2019-11-22

標籤大概走了敏捷手繪敏捷寶典在此還不简体版

原文原文鏈接

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~程序員

本文由薄玉桴發表於雲+社區專欄app

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

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

1.朋友，你據說過敏捷麼？工具

2.離開敏捷工具，咱們怎麼敏？佈局

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

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

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

6.盡信書，不如無書。ui

1、朋友，你據說過敏捷麼？

程序員說，要有敏捷

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

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

這十七我的如同開宗立派的長老，在會議以後給本身起了個名字「敏捷聯盟」，他們不只賦予了新方法名字，還有宣言，甚至綱領。

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

中文版的「敏捷宣言」。在創建於2002年3月的《Manifesto for Agile Software Development》裏你能夠找到幾十種語言的「敏捷宣言」。

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

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

看起來是個很不錯的方法，文檔不重要了，流程不重要了，你們聚在一塊兒說一說就能夠了不是嗎？太棒了，感受能夠從繁重的文書工做中解脫出來了呢。

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

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

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

初識敏捷，有一些概念須要瞭解，若是你是老司機，跳過這部分，阿敏。

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

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

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

scrum 即爲這樣一種方式，你們蜂擁而上，團隊是球員，球是產品目標，人員環環相扣，圍繞着產品目標進行工做。這裏面多少有點「統籌法」的影子，人員深刻協做以達到最優化效果。

Product Backlog:

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

Backlog 裏面寫什麼：

1.待開發任務。

2.任務優先級。

敏捷須要維護一份詳盡的需求列表。這份列表經常要求 scrum 持有人（通常是產品經理）對全部待開發事項有深刻了解，而且可以把待開發事項分解成更爲細緻的任務（或者跟敏捷教練一塊兒，後面咱們會再次提到敏捷教練）

story board:

不少領域都有故事板的概念，交互領域裏，用故事板表述用戶場景、電影領域裏故事板用來更具體地描述分鏡。在開發領域，故事版是任務流轉的可視化窗口，通常有「待開發」「開發中」「待測試」「返工」「待發布」幾個區塊，全部任務由任務操做者負責流轉至於下一個步驟，這樣任何一我的項目成員都能看到任務的完成狀況。

一個app使用情景故事版

在開發中，故事板展示全部需求的工做流

burn down chart：

燃盡圖

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

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

2、離開敏捷工具，咱們怎麼敏？

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

隨着敏捷在行業內的不斷融入，各類工具產品層出不窮。國外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 原本就是排斥文檔的做業方式，爲一個小輕快的方法制做一套嚴謹龐大的工具，基本也算違背了元老們的初衷了吧，科科。

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

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

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

另外一種思路，是把設計和測試徹底歸入到團隊中來，一塊兒進行 scrum 的合做。

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

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

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

項目持有者將需求分爲「 UI 支持」和「非 UI 支持」兩類。咱們將小紙條擴展一下。

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

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

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

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

4、敏捷不須要文檔嗎？

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

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

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

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

「咱們是敏捷團隊。」

十幾我的八九條槍的階段以後，產品趨於穩定，團隊逐步擴大。不管從內部協調仍是外部溝通上對產品流程的正規化和文檔化要求與日俱增。

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

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

一個以訛傳訛的過程

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

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

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

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

對又是你

產品文檔包括：

1.需求；

2.加入日期；

3.開發版本；

4.呈現和詳細方案

在非敏捷開發流程中，文檔在評審會後完善並更新，造成一個給研發參考的實現目標。在敏捷中，需求自己在 sprint 週期內不斷完善，你能夠在一個 sprint 以後將文檔補全。

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

**接口文檔：**必要且重要。包括接口說明、字段定義、字段類型、值定義、數據上報、錯誤碼等。通常來講約定以後由接口開發者更新文檔，若是大家沒有云端存儲的能力，至少我們人手一份，按期更新。

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

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

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

1.空間上，文檔傳播範圍更廣。規範化和常規化的內容造成文檔能夠大大減小溝通成本。尤爲在多個系統協做的狀況下，跨 scrum 、跨團隊甚至跨部門的溝通時有發生，文檔的重要性和便捷性不言而喻。

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

5、大項目怎麼引入敏捷？

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

還能走敏捷嗎？

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

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

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

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

大項目敏捷中：

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

2.將全部需求分解成任務，開一次全局 scrum 會。預估時間以後，分散任務到各個 sprint 中。在時間較緊的狀況下，sprint 的容量就要相應增長。