進(jìn)階必看！大廠設(shè)計(jì)超愛用的敏捷開發(fā)指南

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

什么是敏捷開發(fā)

1. 敏捷開發(fā)的定義

敏捷開發(fā)就是將項(xiàng)目拆分為多個子項(xiàng)目，獨(dú)立開發(fā)、分別實(shí)現(xiàn)，盡快的產(chǎn)出交付給用戶，收集用戶反饋后立即調(diào)整優(yōu)化，一直迭代到用戶滿意，最后集成為一個完整的極具用戶價值的產(chǎn)品，且在此過程中產(chǎn)品一直處于可用狀態(tài)。

2. 敏捷的核心思想

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

附知識補(bǔ)給：MVP為最小可行性產(chǎn)品

3. 敏捷開發(fā)的由來

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

傳統(tǒng)的開發(fā)模式，像瀑布模型、噴泉模型、螺旋模型等等，雖然有不斷的進(jìn)化與創(chuàng)新，但始終沒有一款能快速、靈活地適應(yīng)市場變化。進(jìn)而發(fā)展了很多輕量化的軟件開發(fā)方法，比如 Scrum、水晶清透法、極限編程法等等，它們都起源于敏捷開發(fā)宣言之前，但都統(tǒng)稱為敏捷軟件開發(fā)法，因?yàn)樗麄兌际堑驮隽渴降拈_發(fā)。

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

知識補(bǔ)給

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

4. 敏捷宣言

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

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

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

當(dāng)業(yè)務(wù)線眾多、項(xiàng)目復(fù)雜、周期跨度較大，這一點(diǎn)尤為重要。為了幫助成員更快速直觀地掌握全局，一些企業(yè)甚至?xí)谵k公區(qū)安置一塊顯示屏，上面投放項(xiàng)目進(jìn)度、代辦清單、參與成員及情況、里程碑任務(wù)、燃盡圖等等，將項(xiàng)目信息可視化，助力成員們的決策分析與執(zhí)行控制。

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

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

相比起軟件，文檔流傳性、追溯性更強(qiáng)，規(guī)范的文檔能幫助我們低成本的跨部門溝通；面對團(tuán)隊(duì)成員的更新?lián)Q代，文檔也能更好的幫助新人清晰地了解產(chǎn)品歷程及全貌。

客戶合作高于合同談判：

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

響應(yīng)變化高于遵循計(jì)劃：

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

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

為什么要用敏捷開發(fā)

1. 傳統(tǒng)模式危機(jī)

對外：跟不上業(yè)務(wù)發(fā)展，錯失市場機(jī)遇

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

系統(tǒng)化解決了過去的部分問題，但面對互聯(lián)網(wǎng)時代（90 年代-2007 年）更大型、更復(fù)雜、陌生領(lǐng)域的項(xiàng)目，會產(chǎn)生更大且難以預(yù)測的問題。隨著移動互聯(lián)網(wǎng)時代興起（2007 年-現(xiàn)在），這些問題愈發(fā)凸顯，面對日益激烈的市場競爭，企業(yè)的反應(yīng)能力成為關(guān)鍵商業(yè)因素。

顯然，傳統(tǒng)模式適合中小規(guī)模、簡單的產(chǎn)品，無法高度兼容需求升級；面對不斷變化的市場需求，開發(fā)周期長，研發(fā)時常跟不上業(yè)務(wù)發(fā)展節(jié)奏，導(dǎo)致客戶/用戶滿意度低，甚至有可能錯失市場機(jī)遇。

對內(nèi)：團(tuán)隊(duì)耗能高、成本大、緊密度低

傳統(tǒng)模式往往是線性流程，強(qiáng)調(diào)結(jié)構(gòu)化、標(biāo)準(zhǔn)化，若有發(fā)生需求變更或問題出現(xiàn)，則涉及多個模塊的調(diào)整，需要投入大量的時間、精力與金錢；團(tuán)隊(duì)成員只和上下游互動，缺乏信息共享意識，容易導(dǎo)致不透明、不信任，最直觀的表現(xiàn)就是明明有溝通協(xié)配，但也很難形成團(tuán)隊(duì)共識；在規(guī)模較大的企業(yè)，人員眾多、部門復(fù)雜、分工細(xì)化，跨部門協(xié)作經(jīng)常出現(xiàn)信息不一致、溝通成本高、反饋不及時、緊密程度低等問題。

2. 瀑布模型弊端

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

瀑布模型的優(yōu)勢在于在前期的需求分析和產(chǎn)品設(shè)計(jì)階段，投入了大量的時間精力，較為全面深入地洞察問題，越早地發(fā)現(xiàn)問題，一定程度上降低了后期維護(hù)成本。但它成也結(jié)構(gòu)化，敗也結(jié)構(gòu)化，很多時候甚至可以稱之為僵化。

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

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

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

介于瀑布模型及其他傳統(tǒng)模式研發(fā)周期長、反應(yīng)較慢、容易錯失機(jī)會、團(tuán)隊(duì)耗能高、成本大等問題，我們需要敏捷這樣靈活、輕小、低耗能、反應(yīng)迅速的新型開發(fā)模式。

Scrum 敏捷開發(fā)流程

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

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

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

1. 相關(guān)基礎(chǔ)概念

沖刺（Sprint）：

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

產(chǎn)品列表（Product Backlog）：

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

沖刺列表（Sprint Backlog）：

即本次Sprint迭代包含的任務(wù)列表，顆粒度較細(xì)。

產(chǎn)品增量（Product Increment）：

本次Sprint+過去Sprint所產(chǎn)生的價值總和，說人話就是新版產(chǎn)品，要求滿足驗(yàn)收標(biāo)準(zhǔn)。

2. 相關(guān)角色

敏捷團(tuán)隊(duì)：

即負(fù)責(zé)軟件開發(fā)的跨職能團(tuán)隊(duì)，包含了產(chǎn)品經(jīng)理、設(shè)計(jì)師、程序員、架構(gòu)師、運(yùn)維等角色，一個產(chǎn)品可以由多個敏捷團(tuán)隊(duì)分模塊共同創(chuàng)建。為保證溝通質(zhì)量，一個敏捷團(tuán)隊(duì)一般會控制在4-9人，人數(shù)太少則生產(chǎn)力受限，人數(shù)太多則容易增加溝通成本。

敏捷教練（Scrum Master）：

管理和帶領(lǐng)團(tuán)隊(duì)的領(lǐng)導(dǎo)者，他并不管理人（因?yàn)閳F(tuán)隊(duì)是自我組織的）而是管理Scrum，負(fù)責(zé)幫助團(tuán)隊(duì)掃除實(shí)施中的障礙，屏蔽外界對團(tuán)隊(duì)的干擾，確保Scrum過程被按照初衷使用；指導(dǎo)團(tuán)隊(duì)快速推進(jìn)Scrum、促進(jìn)團(tuán)隊(duì)達(dá)成共識。

利益相關(guān)者：

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

產(chǎn)品負(fù)責(zé)人（PO）：

負(fù)責(zé)敏捷團(tuán)隊(duì)和利益相關(guān)者的連接，梳理、拆解、估算需求，確保產(chǎn)品列表對所有人可見、透明、清晰，幫助團(tuán)隊(duì)成員清晰理解需求和目標(biāo)。中小型企業(yè)多以產(chǎn)品經(jīng)理（PM）負(fù)責(zé)，一些大型To B企業(yè)則是由業(yè)務(wù)分析師（BA）負(fù)責(zé)，具體情況視產(chǎn)品屬性及體量規(guī)模而定（在本文統(tǒng)一使用“PO”這一稱謂）。

細(xì)談PO、敏捷團(tuán)隊(duì)、敏捷教練：

利益相關(guān)者總是希望我們在產(chǎn)品研發(fā)上，能做到又快又好又對（理想主義），而忽略復(fù)雜且混沌的現(xiàn)實(shí)情況，不論結(jié)果如何，整個過程都是會較高地消耗團(tuán)隊(duì)信心、熱情、信任與創(chuàng)造力的。

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

所以我們需要通過 PO、敏捷團(tuán)隊(duì)、敏捷教練三者相互協(xié)作，PO 關(guān)注于構(gòu)建哪些正確的事，敏捷團(tuán)隊(duì)關(guān)注于如何正確構(gòu)建，敏捷教練關(guān)注于如何推動 Scrum 快速進(jìn)行，在一次次迭代循環(huán)中收集反饋、加速學(xué)習(xí)，在實(shí)踐中逐步找到三者平衡。

3. Scrum 流程

需求規(guī)劃

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

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

?Sprint計(jì)劃會議（Sprint Planning Meeting）

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

這里值得一提的是需求規(guī)劃和需求評審的區(qū)別，前者由 PO 主導(dǎo)，涉及商業(yè)、市場、運(yùn)營，更像是范圍層“我們做什么，不做什么”；后者由 PM 主導(dǎo)，涉及業(yè)務(wù)邏輯、產(chǎn)品架構(gòu)、產(chǎn)品設(shè)計(jì)、功能實(shí)現(xiàn)、用戶體驗(yàn)設(shè)計(jì)，更像是結(jié)構(gòu)層“如何構(gòu)建，如何連接”。

比如 PO 提出一個用戶故事，孩子的多個家長都可以實(shí)時收到孩子的學(xué)習(xí)情況，需求規(guī)劃會對該需求價值、規(guī)模進(jìn)行評判：其投資回報率及產(chǎn)品當(dāng)前階段，我們現(xiàn)在是否要實(shí)現(xiàn)這個需求。

PM 根據(jù)這個需求細(xì)化，是通過 Push 通知、短信通知、彈窗通知還是信息提示？包含學(xué)習(xí)時長、測試成績、能力分析模型、老師評價等哪些功能?需求評審會對這些實(shí)現(xiàn)需求基于用戶體驗(yàn)、技術(shù)層面進(jìn)行評判：其實(shí)現(xiàn)方式、可行性、疑難點(diǎn)、潛在風(fēng)險，我們?nèi)绾稳ヂ涞貙?shí)現(xiàn)這些需求或者部分需求。

每日站會（Daily Scrum Meeting）

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

每日 Scrum 站會增進(jìn)團(tuán)隊(duì)間的交流溝通、發(fā)現(xiàn)開發(fā)過程中需要移除的障礙、促進(jìn)快速決策、提高團(tuán)隊(duì)的認(rèn)知程度，這是一個進(jìn)行檢視與適應(yīng)的關(guān)鍵會議。

需求變更

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

測試驗(yàn)收

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

Sprint評審會議（Sprint Review Meeting）

在迭代快結(jié)束時舉行 Sprint 評審會議 ，敏捷團(tuán)隊(duì)演示這次迭代完成的工作（Demo 演示），討論當(dāng)前 Sprint Backlog 情況、做的好的地方、遇到什么問題及如何解決的，并解答相關(guān)問題。然后 PO、利益相關(guān)者、敏捷團(tuán)隊(duì)一起探討接下來可能要做的事情，評審市場變化或競品新動向?qū)ξ覀冊斐墒裁从绊憽＿@并不是一個單純進(jìn)度匯報會議，目的是為了獲取反饋并促進(jìn)及時調(diào)整。

Sprint回顧會議（Sprint Retrospective Meeting）

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

注：Sprint 評審會議是對項(xiàng)目本身進(jìn)行檢視和調(diào)整，而 Sprint 回顧會議則是對團(tuán)隊(duì)的工作方式進(jìn)行調(diào)整和優(yōu)化。

4. Scrum 流程小結(jié)

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

瀑布模型與敏捷適用范圍

1. 瀑布與 scrum

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

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

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

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

2. B 端產(chǎn)品是否適合使用敏捷開發(fā)

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

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

敏捷須知

1. 發(fā)車模式

在產(chǎn)品的發(fā)布模式上，很多新型企業(yè)、成熟企業(yè)會采用一種發(fā)車模式：即限定時間和質(zhì)量，通常 2 周發(fā)布一個新版本，用以規(guī)范發(fā)布、提升發(fā)布速率、規(guī)范系統(tǒng)之間的集成。

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

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

設(shè)計(jì)師是通過設(shè)計(jì)手段解決業(yè)務(wù)需求，更多情況下都是跟車角色，很少主動發(fā)車。所以當(dāng)我作為面試官，會查看求職者設(shè)計(jì)項(xiàng)目的出發(fā)點(diǎn)是否基于業(yè)務(wù)需求，作為項(xiàng)目真實(shí)性的評判標(biāo)準(zhǔn)。

2. 用戶故事

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

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

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

3. 燃盡圖

在敏捷宣言第一條解釋里我有提到，一些企業(yè)會在辦公區(qū)安置一塊顯示屏，上面投放項(xiàng)目進(jìn)度、里程碑任務(wù)、燃盡圖等等，將項(xiàng)目可視化，信息透明是高效協(xié)作的基礎(chǔ)。

燃盡圖容易被誤認(rèn)為 KPI 指標(biāo)，這里有必要說明一下：燃盡圖不是 KPI 指標(biāo)，而是對工作情況進(jìn)行監(jiān)控調(diào)節(jié)的參考指標(biāo)之一，它與團(tuán)隊(duì)效能、估算管理有關(guān)。燃盡圖是一種剩余工作量的可視圖，Y 軸為剩余的工作量，X 軸為 Sprint 工作日，以一條斜線代表預(yù)估的工作情況（工作量平均分配到整個項(xiàng)目期間），另一條曲線/折線代表真實(shí)的工作情況。

當(dāng)曲線高于斜線，那么代表進(jìn)度落后，需要及時調(diào)整；若曲線低于斜線，那么代表進(jìn)度快于預(yù)測；若曲線呈上升趨勢，則代表新增的任務(wù)工作量大于完成的工作量。影響實(shí)際曲線的因素很復(fù)雜，有可能是沒有正確估算任務(wù)量與團(tuán)隊(duì)能力，有可能是需求變動，也有可能是團(tuán)隊(duì)沒有及時更新等等。

敏捷工具

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

1. 看板

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

我們可以將 doing 根據(jù)團(tuán)隊(duì)角色進(jìn)一步細(xì)分，比如待辦、設(shè)計(jì)、開發(fā)、測試、已完成；還可以根據(jù)研發(fā)階段進(jìn)細(xì)分，比如 Sprint 0（迭代版本）、To Do（待辦）、WIP（在制品）、Review（評審）、Done（已完成）

甚至可以定制設(shè)計(jì)團(tuán)隊(duì)的任務(wù)看板，比如待辦、設(shè)計(jì)中、待過稿、設(shè)計(jì)評審、開發(fā)驗(yàn)收、上線跟蹤、已完成

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

2. 甘特圖

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

前面說的發(fā)車模式可以讓大家了解每次迭代發(fā)布的時間節(jié)點(diǎn)，而甘特圖更為細(xì)化，讓所有人了解單個迭代里各任務(wù)的時間節(jié)點(diǎn)，幫助大家及時調(diào)節(jié)分配、控制成本。

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

所以看板適合任務(wù)狀態(tài)展示，甘特圖適合周期較短的小型項(xiàng)目查看時間任務(wù)關(guān)系。大家可以根據(jù)實(shí)際情況，將二者結(jié)合使用。釘釘任務(wù)管家就同時支持甘特圖和看板，不過需要付費(fèi)，不太適合白嫖黨。

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

設(shè)計(jì)師如何介入敏捷

1. 介入方式

深入理解業(yè)務(wù)

無論是團(tuán)隊(duì)中任一個角色，對業(yè)務(wù)不了解就無法做出正確的決策。設(shè)計(jì)師常常被誤認(rèn)為是負(fù)責(zé)錦上添花的，在公司沒有什么話語權(quán)，不像產(chǎn)品、運(yùn)營有明顯的開源價值，也不像開發(fā)、運(yùn)維有明顯的節(jié)流價值。我們需要主動深入了解業(yè)務(wù)，洞察潛在機(jī)會點(diǎn)有哪些、影響項(xiàng)目的商業(yè)因素有哪些、市場上有哪些解決方案、背后的原因利弊是什么等等。

只有我們從業(yè)務(wù)出發(fā)，提出切實(shí)有效的解決方案，才能讓大家了解到設(shè)計(jì)師是解決業(yè)務(wù)訴求、為商業(yè)賦能的價值存在。

并肩而行

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

同時我們還需要注意和團(tuán)隊(duì)及時更新設(shè)計(jì)文檔，建議學(xué)習(xí)使用組件庫、藍(lán)湖、zeplin 或者 figma 來降低溝通成本、提高協(xié)作效率。

進(jìn)度優(yōu)先

互聯(lián)網(wǎng)變化日新月異，商業(yè)機(jī)遇轉(zhuǎn)瞬即逝，為了趕在時間節(jié)點(diǎn)發(fā)布，我們有可能要放寬一些限制，不要在無傷大雅的細(xì)節(jié)上嚴(yán)苛要求。比如標(biāo)簽樣式、緩動曲線、行高段間距等等，不必強(qiáng)行要求 100%還原度，可以在灰度測試時要求 60%的還原度，在發(fā)布前要求 80%的還原度，上線后 1-2 次迭代要求 95%的還原度。

要優(yōu)先考慮項(xiàng)目進(jìn)度，保證商業(yè)速度的同時，兼顧開發(fā)的承受能力。敏捷的核心思想本來就是不追求一開始盡善盡美，小步快跑，在一次次快速迭代中達(dá)到更好。

2. 敏捷設(shè)計(jì)

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

Google Design Sprint（設(shè)計(jì)沖刺）是由谷歌風(fēng)投團(tuán)隊(duì)提出的一套產(chǎn)品設(shè)計(jì)方法，幫助初創(chuàng)團(tuán)隊(duì)在 1-5 天快速研究、決策、設(shè)計(jì)、驗(yàn)證方案。以其高協(xié)作、低風(fēng)險的特點(diǎn)，風(fēng)靡各大互聯(lián)網(wǎng)企業(yè)，并在 Slack、Uber、H&M、Nest 等知名項(xiàng)目得到了成功驗(yàn)證。

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

理解

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

定義

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

發(fā)散

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

決定

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

原型

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

驗(yàn)證

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

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

Design Sprint 要求項(xiàng)目所有角色都參與進(jìn)來，匯集各個環(huán)節(jié)的信息細(xì)節(jié)，集思廣益、尋求共識，最終方案不僅團(tuán)隊(duì)統(tǒng)一認(rèn)可，還通過用戶真實(shí)的反饋進(jìn)行驗(yàn)證與修正，盡最大的努力降低風(fēng)險、控制成本。

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

如何推動敏捷

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

1. 獲取管理層支持

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

2. 獲得團(tuán)隊(duì)成員支持

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

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

我們需要一位經(jīng)驗(yàn)豐富的敏捷教練來指導(dǎo)培訓(xùn)，從管理層到開發(fā)團(tuán)隊(duì)都需要進(jìn)行培訓(xùn)，以確保上下游都有一致的開發(fā)理念與基礎(chǔ)認(rèn)知。接著在敏捷教練指導(dǎo)下，將敏捷代入項(xiàng)目中實(shí)踐落地。

4. 在小型項(xiàng)目試點(diǎn)

在成員們經(jīng)驗(yàn)還未成熟的情況下，最好選擇在小型項(xiàng)目中嘗試敏捷開發(fā)的使用，盡可能的降低風(fēng)險。

5. 持續(xù)提升

通常在一到兩個敏捷周期，團(tuán)隊(duì)已經(jīng)適應(yīng)敏捷節(jié)奏，并積攢了一定的經(jīng)驗(yàn)與改進(jìn)方式，可以逐步轉(zhuǎn)入敏捷模式了，并在此過程中不斷提高團(tuán)隊(duì)敏捷能力。

6. 擴(kuò)展推廣

當(dāng)團(tuán)隊(duì)敏捷成熟度不斷提升，可以嘗試擴(kuò)展到不同業(yè)務(wù)線的團(tuán)隊(duì)，逐步實(shí)現(xiàn)以整個產(chǎn)品價值流為中心的大型敏捷部隊(duì)，最后到達(dá)不同業(yè)務(wù)板塊多個產(chǎn)品團(tuán)隊(duì)配合，業(yè)務(wù)驅(qū)動研發(fā)運(yùn)營一體化的終極敏捷。

歡迎關(guān)注作者微信公眾號：「梁17」