談互聯網必談敏捷，可你真的了解敏捷嗎？你們公司用的是什么開發模式？一個健康的敏捷開發流程又是什么樣的？設計師如何介入敏捷？如果你想到大廠上班，那么你必須要了解這些；如果你想職場晉升，那么利用敏捷幫助團隊提效就是很好的機會。本次我將在團隊內部的敏捷分享，進一步深挖，建議大伙小筆記記起來。

什么是敏捷開發

1. 敏捷開發的定義

敏捷開發就是將項目拆分為多個子項目，獨立開發、分別實現，盡快的產出交付給用戶，收集用戶反饋后立即調整優化，一直迭代到用戶滿意，最后集成為一個完整的極具用戶價值的產品，且在此過程中產品一直處于可用狀態。

2. 敏捷的核心思想

小步快跑、快速迭代、擁抱變化：不追求一開始就盡善盡美，而是把最核心的東西先交付 MVP，根據市場反饋來對需求進行驗證和矯正，以靈活敏捷的改變調整去適應變化，在一次次持續迭代中達到最終目標。

附知識補給：MVP為最小可行性產品

3. 敏捷開發的由來

“敏捷”一詞來源于 2001 年年初美國猶他州雪鳥滑雪圣地的一次的聚會，由 17 名軟件開發人員一同發布的“敏捷軟件開發宣言”。它原是一種價值觀，用于指導我們高效地完成產品開發，隨著它改變了整個行業模式，大家便用它來統一命名其指導下的新型開發模式。

傳統的開發模式，像瀑布模型、噴泉模型、螺旋模型等等，雖然有不斷的進化與創新，但始終沒有一款能快速、靈活地適應市場變化。進而發展了很多輕量化的軟件開發方法，比如 Scrum、水晶清透法、極限編程法等等，它們都起源于敏捷開發宣言之前，但都統稱為敏捷軟件開發法，因為他們都是迭代和增量式的開發。

各種敏捷開發方法的差異在于理念、過程、術語不同，但相較于“非敏捷”，它們都更強調團隊間的緊密協作、面對面的溝通、頻繁的交付新版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用。

知識補給

• 迭代：不斷用變量的舊值遞推新值，說人話就是改進優化。比如微信一開始只能純粹的編輯消息，甚至無法復制粘貼，在后來的迭代中陸續支持復制粘貼、轉發、撤回等功能。
• 增量式開發：多個子項目逐步增加、集成，也就是豐富維度。比如微信一開始的通信方式只有發送文字、圖片，在后面的迭代中新增了語音消息、語音通話、視頻通話、語音輸入等多種形式。

4. 敏捷宣言

需要注意的是敏捷 4 大價值觀中，我們更重視左側的價值，這并不代表可以忽略右側的價值。

個體和互動高于流程和工作：

要想為產品持續做出正確的決策是很困難的，我們需要跨部門面對面的溝通交流，獲取更多的有價值信息。同時，要讓團隊所有成員熟悉掌握項目本身、進展情況，幫助成員清晰了解全局，而不是一層一層地隔斷信息卻要求成員們具有全局觀，良好透明的溝通才能保證項目的高效運轉。

當業務線眾多、項目復雜、周期跨度較大，這一點尤為重要。為了幫助成員更快速直觀地掌握全局，一些企業甚至會在辦公區安置一塊顯示屏，上面投放項目進度、代辦清單、參與成員及情況、里程碑任務、燃盡圖等等，將項目信息可視化，助力成員們的決策分析與執行控制。

工作的軟件高于詳盡的文檔：

軟件相對于文檔更靈活輕量，畢竟文檔無論是撰寫還是維護，都需要花費大量的時間精力，于是各種高效有序的項目管理工具在協作中更受歡迎。但軟件高于文檔并不代表著要拋棄文檔或草草記錄，而是在快速迭代的周期里以軟件協作為主，文檔盡可能的精簡，可以在復盤回顧時進行維護修補。

相比起軟件，文檔流傳性、追溯性更強，規范的文檔能幫助我們低成本的跨部門溝通；面對團隊成員的更新換代，文檔也能更好的幫助新人清晰地了解產品歷程及全貌。

客戶合作高于合同談判：

軟件開發初期，需求無法完全收集（我不知道想什么樣的，你先做幾版看看），且客戶需求一直在發生變化，所以要和客戶保持緊密頻繁的溝通，如果條件允許最好與客戶面對面溝通，甚至是在客戶現場辦公。這樣可以第一時間獲取反饋和詳盡的信息細節，以減少理解偏差和決策誤判，保證開發效率和質量。

響應變化高于遵循計劃：

敏捷開發本身就是為了快速地響應市場變化，隨時關注變化，以實際交付質量、真實的反饋去做衡量、決策，而不是遵循計劃。我們需要做的就是調研要有足夠的深度，方案要考慮后期的拓展性，盡量避免變化成為瓶頸甚至危機。如果你想晉升，更要關注學習整個過程中領導如何協調資源、解決困難、指導部署。

除了 4 大價值觀，敏捷開發還有 12 條原則，感興趣的朋友可以進一步了解。

為什么要用敏捷開發

1. 傳統模式危機

對外：跟不上業務發展，錯失市場機遇

20 世紀 50 年代，計算機剛投入實際使用時，軟件開發大多是為了特定的應用在指定的計算機編制設計，供小范圍使用，簡單、規模小且沒有文檔資料，更不用談系統化開發。隨著技術發展（70 年代-90 年代），計算機應用范圍的擴展，出現了數據量大、復雜程度高、軟件穩定可靠的需求，催生了一些系統化的開發方法，其中以瀑布模型為代表（后面會說）。

系統化解決了過去的部分問題，但面對互聯網時代（90 年代-2007 年）更大型、更復雜、陌生領域的項目，會產生更大且難以預測的問題。隨著移動互聯網時代興起（2007 年-現在），這些問題愈發凸顯，面對日益激烈的市場競爭，企業的反應能力成為關鍵商業因素。

顯然，傳統模式適合中小規模、簡單的產品，無法高度兼容需求升級；面對不斷變化的市場需求，開發周期長，研發時常跟不上業務發展節奏，導致客戶/用戶滿意度低，甚至有可能錯失市場機遇。

對內：團隊耗能高、成本大、緊密度低

傳統模式往往是線性流程，強調結構化、標準化，若有發生需求變更或問題出現，則涉及多個模塊的調整，需要投入大量的時間、精力與金錢；團隊成員只和上下游互動，缺乏信息共享意識，容易導致不透明、不信任，最直觀的表現就是明明有溝通協配，但也很難形成團隊共識；在規模較大的企業，人員眾多、部門復雜、分工細化，跨部門協作經常出現信息不一致、溝通成本高、反饋不及時、緊密程度低等問題。

2. 瀑布模型弊端

傳統瀑布模型是一種線性順序生命周期模型，將產品研發各階段按照固定順序展開工作：需求定義→產品設計→研發實現→測試驗證→發布維護，像瀑布流水般自上而下。上一階段成功完成后，才會移至下一階段，相鄰的兩個階段互為唯一的輸入/輸出，其他各階段之間缺乏業務交流，這有可能導致細節疏漏、理解偏差，進而發展為項目延期或失敗。

瀑布模型的優勢在于在前期的需求分析和產品設計階段，投入了大量的時間精力，較為全面深入地洞察問題，越早地發現問題，一定程度上降低了后期維護成本。但它成也結構化，敗也結構化，很多時候甚至可以稱之為僵化。

每一階段都依賴于上一階段的正確、完整，一旦某個階段出現問題，需要回到上一階段推到重來，如果是需求變動或者需求誤判，那么所有已完成的工作都要付諸東流，越到后期風險成本越大。各階段的信息斷層，又會使得隊員們在“可能是……”的反復改改改中喪失信心與創造力。

瀑布模型還是一種理想化模型：需求要足夠穩定甚至不變、設計者要有超強的前瞻性、實現者要有極強的業務能力及適應性。而這些都存在著大量的不可控風險：市場/客戶需求每天都在隨著商業發展、技術發展在變化，我們無法完全預料到未來會發生的所有問題，研發也無法百分之百精準還原、完美集成。

（我沒有在針對開發小哥們，我沒有！我不是！）。

介于瀑布模型及其他傳統模式研發周期長、反應較慢、容易錯失機會、團隊耗能高、成本大等問題，我們需要敏捷這樣靈活、輕小、低耗能、反應迅速的新型開發模式。

Scrum 敏捷開發流程

眾多敏捷開發方法中，有的專注于實踐，如極限編程、敏捷建模；有的專注于管理工作流程，如 Scrum；有的支持需求規范和開發（如 FDD）的活動；而另一些則試圖涵蓋整個開發生命周期，如動態系統開發。我們這里簡單介紹一下較為流行的 Scrum 開發流程。

Scrum 原意指的是英式橄欖球運動中，次要犯規時在犯規地點對陣爭球，兩隊各以一個整體的方式，隊員間緊密相擁、協作爭球。1995 年美國計算機協會的 OOPSLA’95 會議上，在 Jeff Sutherlan 和 Ken Schwaber 聯合發表的論文中首次提出 Scrum 概念：以跨職能團隊的形式，像橄欖球隊般緊密協作，圍繞隨著統一的目標前進，以此提高工作與交付效率。

在介紹 Scrum 流程前，咱們先來看看相關概念與相關角色。

1. 相關基礎概念

沖刺（Sprint）：

在Scrum框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，官方建議每個Sprint的長度是2到4周（互聯網產品研發可以使用1周的Sprint），前一個 Sprint 結束后，新的下一個 Sprint 緊接著立即開始。Sprint由 Sprint計劃會議、每日Scrum站會、開發工作、 Sprint評審會議和 Sprint回顧會議構成。

產品列表（Product Backlog）：

即產品需求列表，我更喜歡稱之為需求池。其表現形式通常為用戶故事（仙女指路本文5.2），顆粒度較粗。

沖刺列表（Sprint Backlog）：

即本次Sprint迭代包含的任務列表，顆粒度較細。

產品增量（Product Increment）：

本次Sprint+過去Sprint所產生的價值總和，說人話就是新版產品，要求滿足驗收標準。

2. 相關角色

敏捷團隊：

即負責軟件開發的跨職能團隊，包含了產品經理、設計師、程序員、架構師、運維等角色，一個產品可以由多個敏捷團隊分模塊共同創建。為保證溝通質量，一個敏捷團隊一般會控制在4-9人，人數太少則生產力受限，人數太多則容易增加溝通成本。

敏捷教練（Scrum Master）：

管理和帶領團隊的領導者，他并不管理人（因為團隊是自我組織的）而是管理Scrum，負責幫助團隊掃除實施中的障礙，屏蔽外界對團隊的干擾，確保Scrum過程被按照初衷使用；指導團隊快速推進Scrum、促進團隊達成共識。

利益相關者：

用戶、客戶、股東及管理層等等，他們會受到產品交付成果的影響，同時他們也能影響著產品決策。

產品負責人（PO）：

負責敏捷團隊和利益相關者的連接，梳理、拆解、估算需求，確保產品列表對所有人可見、透明、清晰，幫助團隊成員清晰理解需求和目標。中小型企業多以產品經理（PM）負責，一些大型To B企業則是由業務分析師（BA）負責，具體情況視產品屬性及體量規模而定（在本文統一使用“PO”這一稱謂）。

細談PO、敏捷團隊、敏捷教練：

利益相關者總是希望我們在產品研發上，能做到又快又好又對（理想主義），而忽略復雜且混沌的現實情況，不論結果如何，整個過程都是會較高地消耗團隊信心、熱情、信任與創造力的。

如果我們耗費大量的時間精力在以正確的方式做正確的事（完美主義），那么很有可能錯過市場機遇；如果我們沉浸在快速搭建漂亮的架構模式（形式主義），那么很大幾率是在自嗨，浪費時間在用戶根本不需要的功能上；如果我們致力于快速產出有用的產品（快餐主義），沒有深入研究正確的投入方式，那么會在未來付出巨大的修復成本。

所以我們需要通過 PO、敏捷團隊、敏捷教練三者相互協作，PO 關注于構建哪些正確的事，敏捷團隊關注于如何正確構建，敏捷教練關注于如何推動 Scrum 快速進行，在一次次迭代循環中收集反饋、加速學習，在實踐中逐步找到三者平衡。

3. Scrum 流程

需求規劃

PO 會將利益相關者們的需求以及自身想法轉化為具體的用戶故事，接著進行需求規劃：與利益相關者了解需求價值，放棄偽需求和無價值需求，將價值需求放入 Product Backlog（需求池）；和敏捷團隊溝通需求規模（實現難度與時長），以需求的價值和規模作為判斷依據，對需求池內容進行優先級排序；必要時，還會將需求拆解為多個子需求，單個子需求具備能在一次 sprint 迭代中實現的可能性。

通常項目早期，或者并非卓越超群的團隊，對于需求的判斷多是不準確的，更多的是在需求池內相對的比較選擇，快速產出投入市場，在反饋中得到驗證與矯正，并在此過程中提升團隊能力，這也正是敏捷的價值所在。

?Sprint計劃會議（Sprint Planning Meeting）

每次迭代一般都是從計劃會議開始，為確保開發質量與效率，我們通常會根據團隊的開發速度，將需求池內容制定到迭代計劃中，一次迭代大概解決 4~6 個需求（視具體情況而定）。計劃會議針對本次迭代范圍，進行需求評審，并將一個需求拆解為多個任務，明確每個任務的目標和驗收標準，以及任務估算排期，產出一份 Sprint Backlog（任務列表）。

這里值得一提的是需求規劃和需求評審的區別，前者由 PO 主導，涉及商業、市場、運營，更像是范圍層“我們做什么，不做什么”；后者由 PM 主導，涉及業務邏輯、產品架構、產品設計、功能實現、用戶體驗設計，更像是結構層“如何構建，如何連接”。

比如 PO 提出一個用戶故事，孩子的多個家長都可以實時收到孩子的學習情況，需求規劃會對該需求價值、規模進行評判：其投資回報率及產品當前階段，我們現在是否要實現這個需求。

PM 根據這個需求細化，是通過 Push 通知、短信通知、彈窗通知還是信息提示？包含學習時長、測試成績、能力分析模型、老師評價等哪些功能?需求評審會對這些實現需求基于用戶體驗、技術層面進行評判：其實現方式、可行性、疑難點、潛在風險，我們如何去落地實現這些需求或者部分需求。

每日站會（Daily Scrum Meeting）

項目進入開發階段，設計、開發、測試按照計劃展開工作。每天早上展開一個 15 分鐘的站會來跟進項目進度，每個人都說說自己昨天的任務及完成度、今天的待辦任務，確保迭代計劃的正常進行；遇到了什么問題及背后原因，是否會影響其他關聯任務或其他成員，以及是否需要幫助，確保及時規避風險。

每日 Scrum 站會增進團隊間的交流溝通、發現開發過程中需要移除的障礙、促進快速決策、提高團隊的認知程度，這是一個進行檢視與適應的關鍵會議。

需求變更

需求變更是在所難免的，我們要“響應變化高于遵循計劃”。若發生緊急變更，我們從開發成本進行考量，是在本次完成還是將部分任務延后到下一次迭代，以確保本次迭代能如期交付；若發生重大變更，我們需要進行團隊會議討論解決方案。隨著時間變化，問題發現、需求新解、任務完成，我們會對 Sprint Backlog 進行不斷地調整修改。

測試驗收

對已完成開發的功能進行可用性、易用性、體驗度、還原度等一系列測試驗收，發布通過測試的部分、修復未通過部分。注意敏捷開發中的測試并非完成本次迭代所有開發任務才測試，而是完成一個測試一個，及時地發現問題解決問題。

Sprint評審會議（Sprint Review Meeting）

在迭代快結束時舉行 Sprint 評審會議 ，敏捷團隊演示這次迭代完成的工作（Demo 演示），討論當前 Sprint Backlog 情況、做的好的地方、遇到什么問題及如何解決的，并解答相關問題。然后 PO、利益相關者、敏捷團隊一起探討接下來可能要做的事情，評審市場變化或競品新動向將會對我們造成什么影響。這并不是一個單純進度匯報會議，目的是為了獲取反饋并促進及時調整。

Sprint回顧會議（Sprint Retrospective Meeting）

每次迭代結束后需要進行一次回顧會議，復盤所遇問題、成本偏差、協作過程，提煉做得好的和需要改進的地方，并制定改進計劃；這個時候 PO 還會根據收集到的用戶反饋、上線數據，大家一起探討優化方案，大致規劃下一個 Sprint，以便成員們提前準備。我們個人需要做的是將本次迭代經驗總結，積極地向成員們分享你所學到的知識及方法技巧，沉淀為團隊知識庫、方法論，復用到日后的迭代中去。

注：Sprint 評審會議是對項目本身進行檢視和調整，而 Sprint 回顧會議則是對團隊的工作方式進行調整和優化。

4. Scrum 流程小結

利益相關者提出需求，由 PO 轉化為具體的用戶故事，需求規劃后，梳理出 Product Backlog（產品列表）；在 Sprint 計劃會議選取并拆解需求、規劃優先級，得到相應的 Sprint Backlog（任務列表）；產品進入開發階段，每日召開 Scrum 站會跟進項目進度、及時發現問題并解決；在迭代快結束時舉行 Sprint 評審會議 ，對項目檢視和調整；迭代結束后進行 Sprint 回顧會議，改進團隊工作方式，此時還會根據產品增量的反饋，大致規劃下一個 Sprint。

瀑布模型與敏捷適用范圍

1. 瀑布與 scrum

當我們以一個產品生命視角來看，瀑布模型呈線性沿著初始方向推進，Scrum 呈螺旋狀在一次次迭代中矯正方向前行。假設我們用瀑布模型開發微信，要想在 2011 就開始著手打造一款涵蓋社交、娛樂、支付、出行、理財等完整生態圈的產品，可能要花 2-3 年的時間進行需求定義、原型設計，然后花 5-6 年進行研發，再花 2 年多測試驗證，最后花 1 年發布推廣。這聽起來是不是很不切實際？且不說 2011 年的微信團隊是否有如此超前的思想，有哪家企業可以在長達 9 年沒有營收的研發中存活下來？又有哪款產品能一投入市場就擁有十幾億的用戶量？

如果我們用 Scrum 來開發微信呢？先從熟人通訊工具入手，用戶可以添加通訊錄/QQ 好友，并免費發信息；接著新增“查看附近的人”功能，開啟陌生交友；然后更新“朋友圈”功能，升級為社交平臺；再接著通過“微信支付、公眾號”轉型為互聯網樞紐；最后通過“小程序”打造移動商業圈。在產品的不斷迭代中，方向隨著市場需求變化、用戶量積累、企業持續盈利，這是不是就比瀑布模式合理順暢得多？

但如果是要做一個單純的通訊工具，按照瀑布模型：定義信息類型、使用場景，再進行原型設計、研發、測試、發布維護，是不是很合乎邏輯？若按照 Scrum 來開發：先做一個可以發信息的產品，接著迭代為可語音通話，再升級為可視頻通話，每次迭代都要召開 Sprint 計劃會議、每日站會、Sprint 評審會議、Sprint 回顧會議，這種并不復雜、當前技術難度不大的產品，用 Scrum 是不是有些浪費資源呢？

可見瀑布模型并非毫無價值，敏捷也并非萬能神方。瀑布模型適合需求明確、穩定、簡單、易于理解的小型產品/項目，敏捷適合需求（一開始）不明確、新型、復雜的大型產品/項目。現在我們更多的是把瀑布揉入到敏捷的單個迭代中，例如需求管理流程用的都是瀑布模式：產品經理→設計→研發→測試→發布→維護。

2. B 端產品是否適合使用敏捷開發

綜上所述，瀑布適合簡單明確的產品，敏捷適合復雜多變的產品，那么復雜而較為穩定的 B 端產品適合使用敏捷嗎？C 端產品用戶面廣、市場多變未知、競爭激烈，需要盡早入局、速戰速決，在一場場戰役中不斷提升產品價值，C 端產品在基因里就和敏捷高度匹配。

而 B 端產品相對來說用戶面較小，若非政策和業務模式變動，通常都較為穩定。B 端一般分為服務于大量客戶的普適性產品和服務于少量客戶的個性化定制產品，對于普適性產品需要伴隨不同行業不同規模的企業成長，情況復雜難以預測，則比較適合使用敏捷開發；對于個性化定制產品需要考慮產品的體量規模，若規模小、易預測、實現周期短，則適合使用瀑布法，若規模較大、難預測、實現周期長，則適合使用敏捷法。

敏捷須知

1. 發車模式

在產品的發布模式上，很多新型企業、成熟企業會采用一種發車模式：即限定時間和質量，通常 2 周發布一個新版本，用以規范發布、提升發布速率、規范系統之間的集成。

每個公司都會有自己的黑話，有的叫“火車模式”，有的叫“班車模式”，有的叫“高鐵模式”等等，為方便大家理解咱們就統稱發車模式。跟企業的具體情況以及團隊能力，發布周期會有所不同，不必糾結于 2 周這個頻率。總之就像發車一樣，每間隔一段時就發布一次新版本，有計劃、有規律。

這樣做的好處在于所有人都清楚各版本發布時間節點、掌握項目進度，較為自由可控地協調工作任務、降低溝通成本；緊湊的發布節奏，無形間形成一種略微緊張的氛圍，良性地促進開發流程敏捷而穩定的發展。

設計師是通過設計手段解決業務需求，更多情況下都是跟車角色，很少主動發車。所以當我作為面試官，會查看求職者設計項目的出發點是否基于業務需求，作為項目真實性的評判標準。

2. 用戶故事

用戶故事是從用戶角度描述用戶希望得到的功能，基于 who、what、why，用簡單易懂的話幫助所有人理解具體的需求內容，在項目啟動階段就達成共識，避免理解偏差出現“這不是我想要的”反復改稿情況。用戶故事的經典書寫形式為“As a …I want to…，so that …”，即“作為一個（用戶角色），我想要（什么功能），以便于（達到什么目的）”。

比如“作為一個家長，我想要獲取孩子的成績單，以便于了解孩子的學習情況”、“作為一個用戶，我想要預約排號，以便于自由掌控排隊時間”

用戶故事具體形式多樣，這里只列舉常見的便簽和電子表格供大家參考。

3. 燃盡圖

在敏捷宣言第一條解釋里我有提到，一些企業會在辦公區安置一塊顯示屏，上面投放項目進度、里程碑任務、燃盡圖等等，將項目可視化，信息透明是高效協作的基礎。

燃盡圖容易被誤認為 KPI 指標，這里有必要說明一下：燃盡圖不是 KPI 指標，而是對工作情況進行監控調節的參考指標之一，它與團隊效能、估算管理有關。燃盡圖是一種剩余工作量的可視圖，Y 軸為剩余的工作量，X 軸為 Sprint 工作日，以一條斜線代表預估的工作情況（工作量平均分配到整個項目期間），另一條曲線/折線代表真實的工作情況。

當曲線高于斜線，那么代表進度落后，需要及時調整；若曲線低于斜線，那么代表進度快于預測；若曲線呈上升趨勢，則代表新增的任務工作量大于完成的工作量。影響實際曲線的因素很復雜，有可能是沒有正確估算任務量與團隊能力，有可能是需求變動，也有可能是團隊沒有及時更新等等。

敏捷工具

敏捷開發注重溝通協作，那么除了通過跨職能團隊緊密協作，還有什么方法能幫助我們進一步提升協作效率嗎？在敏捷宣言第 2 條“工作的軟件高于詳盡的文檔”可以找到指示，我們可以使用項目管理工具實現項目計劃可視化，將項目狀態透明公開。大多有效的項目管理工具都是基于兩種方法：看板和甘特圖。

1. 看板

看板是起源于豐田的一種生產流程管理工具，以卡片的形式傳遞任務指令。現在看板已成為 scrum 極具代表性的工具之一，分為“To Do”、“Doing”、“Done”，寫著任務的卡片在以上 3 個階段間流轉。所有人可以通過看板清晰掌握成員職責、項目狀態、項目進度，更關注于任務本身。當任務發生變化，只需將任務卡片進行移動或修改。且看板極易使用，如果沒有軟件工具（電子看板），僅需便簽紙也可以實現（物理看板）。

我們可以將 doing 根據團隊角色進一步細分，比如待辦、設計、開發、測試、已完成；還可以根據研發階段進細分，比如 Sprint 0（迭代版本）、To Do（待辦）、WIP（在制品）、Review（評審）、Done（已完成）

甚至可以定制設計團隊的任務看板，比如待辦、設計中、待過稿、設計評審、開發驗收、上線跟蹤、已完成

市面上優秀的看板工具紛繁樣多，例如經典的 Trello，全球千萬級用戶使用的項目管理工具，免費、簡單、靈活；功能強大的筆記軟件 notion，不僅靈活美觀，還支持一組數據多維度展現方式；還有國內較知名的 leangoo，基于看板的項目協作工具，還提供實時協作的腦圖功能；阿里的 teambition，簡潔、漂亮，符合設計師審美，另外待辦和網盤功能在測試階段，很是期待。

2. 甘特圖

甘特圖是一種隨時間變化的進程管理表，常用于項目管理、生產管理、資源管理。在敏捷項目管理中，甘特圖水平顯示時間軸，垂直顯示任務，相同的顏色顯示同類型的任務，灰色代表還未開始的任務。所有人可以通過該圖一目了然地查看成員職責、任務耗時、時間期限、項目進度。

前面說的發車模式可以讓大家了解每次迭代發布的時間節點，而甘特圖更為細化，讓所有人了解單個迭代里各任務的時間節點，幫助大家及時調節分配、控制成本。

但如你所見，對于周期較長的項目會占用較大的橫向空間，對于復雜項目（任務量大）會占用較大的豎向空間。雖然有不少軟件會固定表頭和首列，方便用戶在一屏顯示不全的情況閱讀對應信息，但來回滾動、梳理信息，一定程度上還是存在較大的理解成本。

所以看板適合任務狀態展示，甘特圖適合周期較短的小型項目查看時間任務關系。大家可以根據實際情況，將二者結合使用。釘釘任務管家就同時支持甘特圖和看板，不過需要付費，不太適合白嫖黨。

推薦一個輕量的在線甘特圖工具 UP Gantt，支持微信登錄、多人協作，還可以定制雙休和法定節假日，自動計算工作日數、進度百分比等等。

設計師如何介入敏捷

1. 介入方式

深入理解業務

無論是團隊中任一個角色，對業務不了解就無法做出正確的決策。設計師常常被誤認為是負責錦上添花的，在公司沒有什么話語權，不像產品、運營有明顯的開源價值，也不像開發、運維有明顯的節流價值。我們需要主動深入了解業務，洞察潛在機會點有哪些、影響項目的商業因素有哪些、市場上有哪些解決方案、背后的原因利弊是什么等等。

只有我們從業務出發，提出切實有效的解決方案，才能讓大家了解到設計師是解決業務訴求、為商業賦能的價值存在。

并肩而行

在敏捷里，設計師不再是那個空等需求的小美工，而是和開發在需求定義階段就參與進來，從業務、產品、體驗、技術角度一同討論解決方案，成員們可以在初始階段就達成共識，不會出現已完成設計進入開發階段，開發小哥反饋實現問題、業務邏輯問題，打回到產品重新梳理、重新設計；成員們還能提前了解彼此的初步解決方案，以及時反饋矯正，或調整自己的對應方案。并肩而行，才能真正地做到高效協同。

同時我們還需要注意和團隊及時更新設計文檔，建議學習使用組件庫、藍湖、zeplin 或者 figma 來降低溝通成本、提高協作效率。

進度優先

互聯網變化日新月異，商業機遇轉瞬即逝，為了趕在時間節點發布，我們有可能要放寬一些限制，不要在無傷大雅的細節上嚴苛要求。比如標簽樣式、緩動曲線、行高段間距等等，不必強行要求 100%還原度，可以在灰度測試時要求 60%的還原度，在發布前要求 80%的還原度，上線后 1-2 次迭代要求 95%的還原度。

要優先考慮項目進度，保證商業速度的同時，兼顧開發的承受能力。敏捷的核心思想本來就是不追求一開始盡善盡美，小步快跑，在一次次快速迭代中達到更好。

2. 敏捷設計

咱們說了這么久敏捷開發模式、發布模式，但似乎對如何開展設計工作沒有太多關系，設計師好像只需全程參與進來就好了。既然咱們要敏捷，那就來聊一聊敏捷設計模式——Google Design Sprint。

Google Design Sprint（設計沖刺）是由谷歌風投團隊提出的一套產品設計方法，幫助初創團隊在 1-5 天快速研究、決策、設計、驗證方案。以其高協作、低風險的特點，風靡各大互聯網企業，并在 Slack、Uber、H&M、Nest 等知名項目得到了成功驗證。

參與 Design Sprint 的正是我們的 scrum 團隊，包含設計師、產品經理、開發、用戶研究員，如果有可能還可以加入利益相關者，以及負責項目推進的其他人員（運營推廣營銷等）。Design Sprint 分為 6 個階段：理解、定義、草圖、決定、原型、驗證，是不是和雙鉆模型有些像？它們都是發散→聚焦→再發散→再聚焦的過程。

理解

第一個階段“理解”，我們需要理解這次 sprint 要解決什么問題？背后的用戶需求是什么、業務訴求是什么、技術資源限制又是什么？這個階段我們只討論問題，不談解決方案，就好比答題第一步是先審清楚題目。這時候我們可以借助用戶訪談、問卷調研、競品分析、焦點小組、實地研究、數據摸底等方法對問題進行深度剖析。

定義

第二個階段“定義”，對第一階段的問題發散進行聚焦，確定本次的問題重點是什么、設計價值機會點有哪些、設計目標是什么、設計原則是什么？這時候的主要手段有用戶體驗地圖、旅程圖、KANO 模型、OKR 等等。

發散

該階段也是方案構思階段，每個人可以大膽腦暴并分享自己的想法（草圖）。這個時候有一個核心原則“yes,and…”，即不要批判別人的想法，如果你是在忍不住，那么你要提出相應的替代方案，而不是一味否決。開會時，大家應該都很討厭那種只會否定但沒有任何建設性意見的人吧。我們此時需要盡可能多的方案，不需要著急否定。該階段可以使用類比法、競品分析、故事版等方法，幫助我們發散創意。

決定

進入第四階段“決定”，我們根據實現成本、用戶價值進行投票，確定最終的方案方向。該階段我們主要是達成共識，選出最合適的方案快速推進工作，有可能需要放棄一些優秀方案，秉持進度優先的理念，不必過于執著。該階段的主要方法有投票法、卡片分類法、決策矩陣等。

原型

這個時候我們開始進行原型設計，你可以在紙上畫，也可以在 sketch、figma 等專業軟件畫。個人建議直接在會上用紙畫出主要的流程功能，向團隊進行復查驗證，會后再詳細地繪制、測試（也就是把原型、驗證兩個階段，在會議上和迭代發布前做了 2 次）。

驗證

到了第六階段，我們先內部技術確認、決策者審查，再進行外部用戶測試，主要是收集反饋建議，做進一步的優化。在正式發布前我們可以進行分段測試，先對一小部分用戶自由開放新版，舊版依舊可用；再選擇一部分關閉舊版，只允許使用新版；最后全量上線。其中每一分段都收集用戶反饋，進行維護糾錯。該階段使用的方法有 A/B 測試、眼動追蹤、問卷調研、可用性走查等等。

到這里我們的一個 Design Sprint 已經完成了，很多人以為把項目拆分進行小項目迭代就是敏捷，往往忽略了跨職能團隊的緊密協作，只學了個空殼卻依然沒有解決問題。

Design Sprint 要求項目所有角色都參與進來，匯集各個環節的信息細節，集思廣益、尋求共識，最終方案不僅團隊統一認可，還通過用戶真實的反饋進行驗證與修正，盡最大的努力降低風險、控制成本。

如果大家還想看具體的 Design Sprint 如何開展，剛才提到的各種方法工具怎么使用，歡迎點贊評論催更。點贊過百，必有下集（一起來挖坑吖）

如何推動敏捷

說實話，敏捷的推動應該是由管理層來推進的，也許是研發 leader、PMO leader、設計 leader 等等，他們相對于其他成員更有話語權。而且每家公司有自己的固有流程規矩，不是那么容易改變的。如果你在初創企業或公司體系不那么完善，那么是可以嘗試推動敏捷的，通過推動敏捷提高團隊效率而走上管理崗的例子也是真實存在的，我們這里簡單說一下推動思路。

1. 獲取管理層支持

無論你要推動什么事情，管理層的支持是絕對關鍵，你需要從價值、成本角度去推動。比如 CPRIME 的研究表示敏捷效率是瀑布式的 3 倍，用戶滿意度提升 53%，它可以幫助我們減少不確定性、提升的生產速度及質量、節省資源、改善成員自主性。

2. 獲得團隊成員支持

敏捷注重團隊間的溝通協作，成員們也是敏捷的直接使用者，所以你需要從共贏角度去推動。比如它可以幫助我們做正確的事、并正確的做事，提升溝通效率，減少不必要的返工、加班。與此同時，你還需要幫助團隊成員們了解敏捷。

3. 申請敏捷教練（Scurm master）加入

我們需要一位經驗豐富的敏捷教練來指導培訓，從管理層到開發團隊都需要進行培訓，以確保上下游都有一致的開發理念與基礎認知。接著在敏捷教練指導下，將敏捷代入項目中實踐落地。

4. 在小型項目試點

在成員們經驗還未成熟的情況下，最好選擇在小型項目中嘗試敏捷開發的使用，盡可能的降低風險。

5. 持續提升

通常在一到兩個敏捷周期，團隊已經適應敏捷節奏，并積攢了一定的經驗與改進方式，可以逐步轉入敏捷模式了，并在此過程中不斷提高團隊敏捷能力。

6. 擴展推廣

當團隊敏捷成熟度不斷提升，可以嘗試擴展到不同業務線的團隊，逐步實現以整個產品價值流為中心的大型敏捷部隊，最后到達不同業務板塊多個產品團隊配合，業務驅動研發運營一體化的終極敏捷。

歡迎關注作者微信公眾號：「梁17」