筆者根據(jù)自己對敏捷開發(fā)Scrum的理解，總結(jié)了敏捷開發(fā)從開始到結(jié)束的流程以及其適用的場景。
一、敏捷開發(fā)到底是什么
很難用一兩句話說清楚敏捷到底是什么，也許因為它只是一套松散的框架，有原則卻無具體方法，1000個項目可能有1000種敏捷的工作方式。敏捷只有在實踐中才有意義，一旦脫離實際去學(xué)習(xí)就變得近乎玄幻。
最常被討論的敏捷框架有3套：Scrum、Agile、看板。涉及到軟件開發(fā)，尤其是面向C端Scrum和Agile更常見，看板方法擅長把繁雜瑣碎的工作一目了然，例如客戶支持這類事務(wù)性工作。
談?wù)揝crum不得不提到PDCA循環(huán)（如下圖），這是一種擅長探索和創(chuàng)造的工作 方式，我認為Scrum正是圍繞PDCA循環(huán)方式衍生出來的的一系列理念、原則和實踐（如backlog、sprint、user story）。它不是方法論，更不是公式，也有一些方法體系，但可供參考卻不該照搬，不同的項目可能需要非常不同但都可稱為Scrum的工作流程。
（PDCA循環(huán)）
如果只用一句話描述Scrum，我認為是：充分接納前景的不確定性，采取探索式前進，以為客戶實現(xiàn)價值為最終目的的開發(fā)方法。重探索輕預(yù)測，這是和線性開發(fā)方式的本質(zhì)區(qū)別。
Scrum步驟由一個接一個Sprin(迭代)組成，因此新手想要快速上手Scrum的話，也許最該學(xué)習(xí)的是一個Sprint(迭代)從哪里開始和結(jié)束，如下：
1. 擬定和評估待辦事項清單
待辦事項即backlog，我的團隊叫需求列表/需求池，指可能要開發(fā)的功能列表。待辦事項有時來自需求方，但更應(yīng)該來自產(chǎn)品經(jīng)理的遠見和洞察。所有被提出的事項（無論是否看起來有價值）都不妨先放入清單，再進行維護。維護包括：
①評估需求價值、工期和緊急程度，去偽存真
②值得做的真需求排定優(yōu)先級
③追蹤處理進度。
如何維護一個健康的backlog涉及細節(jié)很多，不妨參閱我的另一篇文章《如何維護健康的需求池》
雖然我的團隊習(xí)慣把待辦事項稱為“需求”，但我自己更喜歡《Scrum精髓》中的叫法——”價值“或者“特性”?！毙枨蟆痹趫F隊溝通中多指運營方而非用戶的需求，暗示產(chǎn)品對運營負責(zé)，而且暗示了團隊能預(yù)測產(chǎn)品的成功，這更符合瀑布式而非敏捷式方法；“價值”的叫法突出了敏捷的價值導(dǎo)向，為實現(xiàn)用戶價值每個角色都負有不可推卸的的責(zé)任?！疤匦浴钡慕蟹▌t突出了敏捷的探索精神，承認當前在做的未必是用戶真正需要的，只有檢測后才有定論。“價值”和“特性”都更能體現(xiàn)敏捷原則。
2. 沖刺啟動會
在上一步厘清需求優(yōu)先級后，團隊所有人（至少所有角色）坐下來規(guī)劃下個迭代要做的需求，也就是消化需求表里優(yōu)先級最高的需求。實際工作中，一些優(yōu)先級不太高但是簡單易做的需求也會見縫插針安排到下個迭代中，以求達到最大工作量。
經(jīng)過充分溝通后，對于下個沖刺應(yīng)該完成哪些內(nèi)容大家都應(yīng)該達成共識。啟動會標志著沖刺的開始，一旦啟動任何人都不應(yīng)該改動沖刺內(nèi)容。也就是需求一旦進入需開發(fā)階段任何人不能進行改動。
為什么共識是進行敏捷的前提？
如果沒有共識，重視溝通，多方參與——容易扯皮，允許在“沖刺”前修改方案——容易推卸責(zé)任或拖延工期，每個沖刺交付最小可行化產(chǎn)品——基于各自利益對最小可行化無法定義，測試和迭代時也難對成果和方向達成一致。
舉例說明，如果某公司的開發(fā)團隊承接來自ABC三個不同產(chǎn)品線的需求，ABC對用戶價值的理解不同（都想讓自己的產(chǎn)品線占用盡可能多資源），在整個公司層面實現(xiàn)敏捷是很困難的。但是可以通過融合方式——關(guān)鍵點評審 盡可能晚確定最終方案，來結(jié)合兩種開發(fā)的優(yōu)點
3. 每日立會
每天固定時間召集所有角色開一個簡短會議，盡量不超過15分鐘，目的是公告工作進展。
4. 成果展示和評估
開發(fā)完成并測試后，再次召集所有角色，展示成果，之后投入使用。
5. 沖刺回顧和新沖刺規(guī)劃
已完成的事項，大家坐下來回顧看看哪些比較順利，哪些可以做的更好。
回顧完成后立即開始下一個沖刺的規(guī)劃。
二、敏捷和線性的本質(zhì)區(qū)別
如上文所說，個人認為沖探索輕預(yù)測是敏捷和線性開發(fā)方式的本質(zhì)區(qū)別。如下所示：
- 敏捷開發(fā)：關(guān)照不確定性→探索式，注重應(yīng)變→價值中心
- 線性開發(fā)：關(guān)照確定性→遵守規(guī)程，注重良好設(shè)計→過程中心
敏捷開發(fā)承認環(huán)境、團隊、用戶和自身的不確定性，認為市場需求難以預(yù)測，因此包容試錯、探索前進，在小步快跑中實時校對方向。校對的參照點是用戶價值，是否能為用戶創(chuàng)造價值作為評價工作的關(guān)鍵指標。
相對而言，線性開發(fā)關(guān)注確定性的內(nèi)容，強調(diào)準確預(yù)測市場，根據(jù)預(yù)測進行盡可能完美的設(shè)計，設(shè)計出來的藍圖必須嚴格呈現(xiàn)，因此評價工作的標準也是藍圖實現(xiàn)程度，即使市場反饋可能并不盡如人意。
三、敏捷的適用場景
線性開發(fā)因為重預(yù)測，便于流程控制，但難點在于必須一開始就確定正確的設(shè)計范圍；敏捷開發(fā)因為是探索導(dǎo)向的流程，可以不斷深挖問題本質(zhì)，提煉真正問題，但缺點是大項目跨部門時時間成本高。
由于敏捷方法以用戶價值為目標，瀑布方法以完美呈現(xiàn)藍圖為目標，項目制團隊中容易就價值達成一致，但是跨團隊跨部門甚至跨公司的項目中，各方理解的價值未必一致。如果能就用戶價值（也就是要交付的產(chǎn)品）達成共識，才能應(yīng)用敏捷開發(fā)。如果無法達成共識，只能通過過程的控制減少溝通和時間成本，宜采用瀑布式開發(fā)。
根據(jù)優(yōu)劣勢，不管是敏捷還是線性開發(fā)都有其適用場景——常用于戰(zhàn)略決策的Cynefin框架非常適合解釋敏捷開發(fā)適用的場景，如下圖：
1. 簡單域（simple）-已知的已知
當因果關(guān)系顯然而見時。處理手法為”感受－歸類－反應(yīng)” （Sense-Categorise-Respond），如導(dǎo)出銷售額數(shù)據(jù)/制作巧克力蛋糕。Scrum不是好的選擇，更應(yīng)該選擇已被證明正確的方法。
2. 繁雜域（complicated）-已知的未知
需要專家診斷后找出正確答案。處理手法為”感受－分析－反應(yīng)” （Sense-Analyze-Respond），如搭建底層數(shù)據(jù)庫/建造太空飛船。Scrum不是最佳方案，應(yīng)該由專家處理。
3. 復(fù)雜域（complex）-未知的未知
因果關(guān)系只能從檢討中反映出來，難以預(yù)測，只能事后知道。處理手法是”試探－感受－反應(yīng)” （Probe-Sense-Respond），如推出新產(chǎn)品/養(yǎng)育青少年。Scrum最擅長的領(lǐng)域。
4. 混亂域（chaotic）-不可知的未知
完全沒有任何因果關(guān)系的混亂情況，需要快速做出反應(yīng)，沒有時間思考。需要的是”行動－感受－反應(yīng)” （Act-Sense-Respond），如911事件/系統(tǒng)宕機。Scrum不是最佳方案，需要的是立即行動。
5. 如果連屬于以上哪個情況都不清楚的，是一個無序的狀態(tài)（disorder），等待參與者把情況安穩(wěn)至上面四個其中之一的情況。
軟件開發(fā)過程中可能涉及以上各個領(lǐng)域，但電商產(chǎn)品（尤其C端）大部分工作落在復(fù)雜域。需要實際工作中靈活適用。
本文由 @羊小雙雙 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于CC0協(xié)議。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
