中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)，也是如今很流行的軟件開發(fā)方法，但是你真的知道什么是敏捷開發(fā)嗎？本文作者分享了關(guān)于敏捷開發(fā)的流程以及團隊內(nèi)部的敏捷分享，我們一起來看一下。

談互聯(lián)網(wǎng)必談敏捷，可你真的了解敏捷嗎？你們公司用的是什么開發(fā)模式？一個健康的敏捷開發(fā)流程又是什么樣的？設(shè)計師如何介入敏捷？

如果你想到大廠上班，那么你必須要了解這些；如果你想職場晉升，那么利用敏捷幫助團隊提效就是很好的機會；本次我將在團隊內(nèi)部的敏捷分享，進一步深挖，建議大伙小筆記記起來。

一、什么是敏捷開發(fā)

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

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

2. 敏捷的核心思想

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

知識補給：

MVP：最小可行性產(chǎn)品

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

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

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

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

知識補給：

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

4. 敏捷宣言

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

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

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

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

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

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

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

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

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

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

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

20世紀(jì)50年代，計算機剛投入實際使用時，軟件開發(fā)大多是為了特定的應(yīng)用在指定的計算機編制設(shè)計，供小范圍使用，簡單、規(guī)模小且沒有文檔資料，更不用談系統(tǒng)化開發(fā)。

隨著技術(shù)發(fā)展（70年代-90年代），計算機應(yīng)用范圍的擴展，出現(xiàn)了數(shù)據(jù)量大、復(fù)雜程度高、軟件穩(wěn)定可靠的需求，催生了一些系統(tǒng)化的開發(fā)方法，其中以瀑布模型為代表（后面會說）。

系統(tǒng)化解決了過去的部分問題，但面對互聯(lián)網(wǎng)時代（90年代-2007年）更大型、更復(fù)雜、陌生領(lǐ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)致客戶/用戶滿意度低，甚至有可能錯失市場機遇。

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

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

2. 瀑布模型弊端

傳統(tǒng)瀑布模型是一種線性順序生命周期模型，將產(chǎn)品研發(fā)各階段按照固定順序展開工作：需求定義→產(chǎn)品設(shè)計→研發(fā)實現(xiàn)→測試驗證→發(fā)布維護，像瀑布流水般自上而下。

上一階段成功完成后，才會移至下一階段，相鄰的兩個階段互為唯一的輸入/輸出，其他各階段之間缺乏業(yè)務(wù)交流，這有可能導(dǎo)致細(xì)節(jié)疏漏、理解偏差，進而發(fā)展為項目延期或失敗。

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

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

瀑布模型還是一種理想化模型：需求要足夠穩(wěn)定甚至不變、設(shè)計者要有超強的前瞻性、實現(xiàn)者要有極強的業(yè)務(wù)能力及適應(yīng)性。

而這些都存在著大量的不可控風(fēng)險：市場/客戶需求每天都在隨著商業(yè)發(fā)展、技術(shù)發(fā)展在變化，我們無法完全預(yù)料到未來會發(fā)生的所有問題，研發(fā)也無法百分之百精準(zhǔn)還原、完美集成。

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

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

三、Scrum敏捷開發(fā)流程

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

我們這里簡單介紹一下較為流行的Scrum開發(fā)流程：

Scrum原意指的是英式橄欖球運動中，次要犯規(guī)時在犯規(guī)地點對陣爭球，兩隊各以一個整體的方式，隊員間緊密相擁、協(xié)作爭球。

1995年美國計算機協(xié)會的OOPSLA’95會議上，在Jeff Sutherlan和Ken Schwaber聯(lián)合發(fā)表的論文中首次提出Scrum概念：以跨職能團隊的形式，像橄欖球隊般緊密協(xié)作，圍繞隨著統(tǒng)一的目標(biāo)前進，以此提高工作與交付效率。

在介紹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計劃會議、每日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)品，要求滿足驗收標(biāo)準(zhǔn)。

2. 相關(guān)角色

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

②敏捷教練（Scrum Master）：管理和帶領(lǐng)團隊的領(lǐng)導(dǎo)者，他并不管理人（因為團隊是自我組織的）而是管理Scrum，負(fù)責(zé)幫助團隊掃除實施中的障礙，屏蔽外界對團隊的干擾，確保Scrum過程被按照初衷使用；指導(dǎo)團隊快速推進Scrum、促進團隊達成共識。

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

④ 產(chǎn)品負(fù)責(zé)人（PO）：負(fù)責(zé)敏捷團隊和利益相關(guān)者的連接，梳理、拆解、估算需求，確保產(chǎn)品列表對所有人可見、透明、清晰，幫助團隊成員清晰理解需求和目標(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、敏捷團隊、敏捷教練：利益相關(guān)者總是希望我們在產(chǎn)品研發(fā)上，能做到又快又好又對（理想主義），而忽略復(fù)雜且混沌的現(xiàn)實情況；不論結(jié)果如何，整個過程都是會較高地消耗團隊信心、熱情、信任與創(chuàng)造力的。

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

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

3. Scrum流程

① 需求規(guī)劃

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

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

② Sprint計劃會議（Sprint Planning Meeting）

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

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

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

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

③ 每日站會（Daily Scrum Meeting）

項目進入開發(fā)階段，設(shè)計、開發(fā)、測試按照計劃展開工作。

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

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

④ 需求變更

需求變更是在所難免的，我們要“響應(yīng)變化高于遵循計劃”；若發(fā)生緊急變更，我們從開發(fā)成本進行考量，是在本次完成還是將部分任務(wù)延后到下一次迭代，以確保本次迭代能如期交付；若發(fā)生重大變更，我們需要進行團隊會議討論解決方案。

隨著時間變化，問題發(fā)現(xiàn)、需求新解、任務(wù)完成，我們會對Sprint Backlog進行不斷地調(diào)整修改。

⑤ 測試驗收

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

⑥ Sprint評審會議（Sprint Review Meeting）

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

⑦ Sprint回顧會議（Sprint Retrospective Meeting）

每次迭代結(jié)束后需要進行一次回顧會議，復(fù)盤所遇問題、成本偏差、協(xié)作過程，提煉做得好的和需要改進的地方，并制定改進計劃；這個時候PO還會根據(jù)收集到的用戶反饋、上線數(shù)據(jù)，大家一起探討優(yōu)化方案，大致規(guī)劃下一個Sprint，以便成員們提前準(zhǔn)備。

我們個人需要做的是將本次迭代經(jīng)驗總結(jié)，積極地向成員們分享你所學(xué)到的知識及方法技巧，沉淀為團隊知識庫、方法論，復(fù)用到日后的迭代中去。

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

4. Scrum流程小結(jié)

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

四、瀑布模型與敏捷適用范圍

1. 瀑布與scrum

當(dāng)我們以一個產(chǎn)品生命視角來看，瀑布模型呈線性沿著初始方向推進，Scrum呈螺旋狀在一次次迭代中矯正方向前行。

假設(shè)我們用瀑布模型開發(fā)微信，要想在2011就開始著手打造一款涵蓋社交、娛樂、支付、出行、理財?shù)韧暾鷳B(tài)圈的產(chǎn)品；可能要花2-3年的時間進行需求定義、原型設(shè)計，然后花5-6年進行研發(fā)，再花2年多測試驗證，最后花1年發(fā)布推廣。

這聽起來是不是很不切實際？且不說2011年的微信團隊是否有如此超前的思想，有哪家企業(yè)可以在長達9年沒有營收的研發(fā)中存活下來？又有哪款產(chǎn)品能一投入市場就擁有十幾億的用戶量？

如果我們用Scrum來開發(fā)微信呢？

先從熟人通訊工具入手，用戶可以添加通訊錄/QQ好友，并免費發(fā)信息；接著新增“查看附近的人”功能，開啟陌生交友；然后更新“朋友圈”功能，升級為社交平臺；再接著通過“微信支付、公眾號”轉(zhuǎn)型為互聯(lián)網(wǎng)樞紐；最后通過“小程序”打造移動商業(yè)圈。

在產(chǎn)品的不斷迭代中，方向隨著市場需求變化、用戶量積累、企業(yè)持續(xù)盈利，這是不是就比瀑布模式合理順暢得多？

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

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

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ù)測、實現(xiàn)周期短，則適合使用瀑布法，若規(guī)模較大、難預(yù)測、實現(xiàn)周期長，則適合使用敏捷法。

五、敏捷須知

1. 發(fā)車模式

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

每個公司都會有自己的黑話，有的叫“火車模式”，有的叫“班車模式”，有的叫“高鐵模式”等等，為方便大家理解咱們就統(tǒng)稱發(fā)車模式。

跟企業(yè)的具體情況以及團隊能力，發(fā)布周期會有所不同，不必糾結(jié)于2周這個頻率；總之就像發(fā)車一樣，每間隔一段時就發(fā)布一次新版本，有計劃、有規(guī)律。

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

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

2. 用戶故事

用戶故事是從用戶角度描述用戶希望得到的功能，基于who、what、why，用簡單易懂的話幫助所有人理解具體的需求內(nèi)容，在項目啟動階段就達成共識，避免理解偏差出現(xiàn)“這不是我想要的”反復(fù)改稿情況。

用戶故事的經(jīng)典書寫形式為“As a …I want to…，so that …”，即“作為一個（用戶角色），我想要（什么功能），以便于（達到什么目的）”。

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

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

3. 燃盡圖

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

燃盡圖容易被誤認(rèn)為KPI指標(biāo)，這里有必要說明一下：燃盡圖不是KPI指標(biāo)，而是對工作情況進行監(jiān)控調(diào)節(jié)的參考指標(biāo)之一，它與團隊效能、估算管理有關(guān)。

燃盡圖是一種剩余工作量的可視圖，Y軸為剩余的工作量，X軸為Sprint工作日，以一條斜線代表預(yù)估的工作情況（工作量平均分配到整個項目期間），另一條曲線/折線代表真實的工作情況。

當(dāng)曲線高于斜線，那么代表進度落后，需要及時調(diào)整；若曲線低于斜線，那么代表進度快于預(yù)測；若曲線呈上升趨勢，則代表新增的任務(wù)工作量大于完成的工作量。

影響實際曲線的因素很復(fù)雜，有可能是沒有正確估算任務(wù)量與團隊能力，有可能是需求變動，也有可能是團隊沒有及時跟新等等。

六、敏捷工具

敏捷開發(fā)注重溝通協(xié)作，那么除了通過跨職能團隊緊密協(xié)作，還有什么方法能幫助我們進一步提升協(xié)作效率嗎？

在敏捷宣言第2條“工作的軟件高于詳盡的文檔”可以找到指示，我們可以使用項目管理工具實現(xiàn)項目計劃可視化，將項目狀態(tài)透明公開；大多有效的項目管理工具都是基于兩種方法：看板和甘特圖。

1. 看板

看板是起源于豐田的一種生產(chǎn)流程管理工具，以卡片的形式傳遞任務(wù)指令。

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

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

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

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

2. 甘特圖

甘特圖是一種隨時間變化的進程管理表，常用于項目管理、生產(chǎn)管理、資源管理。

在敏捷項目管理中，甘特圖水平顯示時間軸，垂直顯示任務(wù)，相同的顏色顯示同類型的任務(wù)，灰色代表還未開始的任務(wù)；所有人可以通過該圖一目了然地查看成員職責(zé)、任務(wù)耗時、時間期限、項目進度。

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

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

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

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

七、設(shè)計師如何介入敏捷

1. 介入方式

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

無論是團隊中任一個角色，對業(yè)務(wù)不了解就無法做出正確的決策。設(shè)計師常常被誤認(rèn)為是負(fù)責(zé)錦上添花的，在公司沒有什么話語權(quán)，不像產(chǎn)品、運營有明顯的開源價值，也不像開發(fā)、運維有明顯的節(jié)流價值。

我們需要主動深入了解業(yè)務(wù)，洞察潛在機會點有哪些、影響項目的商業(yè)因素有哪些、市場上有哪些解決方案、背后的原因利弊是什么等等。

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

② 并肩而行

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

并肩而行，才能真正地做到高效協(xié)同。

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

③ 進度優(yōu)先

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

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

2. 敏捷設(shè)計

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

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

參與Design Sprint的正是我們的scrum團隊，包含設(shè)計師、產(chǎn)品經(jīng)理、開發(fā)、用戶研究員，如果有可能還可以加入利益相關(guān)者，以及負(fù)責(zé)項目推進的其他人員（運營推廣營銷等）。

Design Sprint分為6個階段：理解、定義、草圖、決定、原型、驗證，是不是和雙鉆模型有些像？它們都是發(fā)散→聚焦→再發(fā)散→再聚焦的過程。

① 理解

第一個階段“理解”，我們需要理解這次sprint要解決什么問題？背后的用戶需求是什么、業(yè)務(wù)訴求是什么、技術(shù)資源限制又是什么？

這個階段我們只討論問題，不談解決方案，就好比答題第一步是先審清楚題目；這時候我們可以借助用戶訪談、問卷調(diào)研、競品分析、焦點小組、實地研究、數(shù)據(jù)摸底等方法對問題進行深度剖析。

② 定義

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

③ 發(fā)散

該階段也是方案構(gòu)思階段，每個人可以大膽腦暴并分享自己的想法（草圖）。

這個時候有一個核心原則“yes,and…”，即不要批判別人的想法，如果你是在忍不住，那么你要提出相應(yīng)的替代方案，而不是一味否決。

開會時，大家應(yīng)該都很討厭那種只會否定但沒有任何建設(shè)性意見的人吧；我們此時需要盡可能多的方案，不需要著急否定。該階段可以使用類比法、競品分析、故事版等方法，幫助我們發(fā)散創(chuàng)意。

④ 決定

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

⑤ 原型

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

⑥ 驗證

到了第六階段，我們先內(nèi)部技術(shù)確認(rèn)、決策者審查，再進行外部用戶測試，主要是收集反饋建議，做進一步的優(yōu)化。

在正式發(fā)布前我們可以進行分段測試，先對一小部分用戶自由開放新版，舊版依舊可用；再選擇一部分關(guān)閉舊版，只允許使用新版；最后全量上線；其中每一分段都收集用戶反饋，進行維護糾錯；該階段使用的方法有A/B測試、眼動追蹤、問卷調(diào)研、可用性走查等等。

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

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

八、如何推動敏捷

說實話，敏捷的推動應(yīng)該是由管理層來推進的，也許是研發(fā)leader、PMO leader、設(shè)計leader等等，他們相對于其他成員更有話語權(quán)；而且每家公司有自己的固有流程規(guī)矩，不是那么容易改變的。

如果你在初創(chuàng)企業(yè)或公司體系不那么完善，那么是可以嘗試推動敏捷的，通過推動敏捷提高團隊效率而走上管理崗的例子也是真實存在的，我們這里簡單說一下推動思路。

1. 獲取管理層支持

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

2. 獲得團隊成員支持

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

與此同時，你還需要幫助團隊成員們了解敏捷。

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

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

4. 在小型項目試點

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

5. 持續(xù)提升

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

6. 擴展推廣

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

參考資料：

https://bk.tw.lvfukeji.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

https://www.jianshu.com/p/a24c6eb51e86

http://www.aharts.cn/pd/157297.html

https://designsprintkit.withgoogle.com/methodology/overview

作者：梁17，微信公眾號：梁17

本文@梁17 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。