筆者根據自己對敏捷開發Scrum的理解，總結了敏捷開發從開始到結束的流程以及其適用的場景。

一、敏捷開發到底是什么

很難用一兩句話說清楚敏捷到底是什么，也許因為它只是一套松散的框架，有原則卻無具體方法，1000個項目可能有1000種敏捷的工作方式。敏捷只有在實踐中才有意義，一旦脫離實際去學習就變得近乎玄幻。

最常被討論的敏捷框架有3套：Scrum、Agile、看板。涉及到軟件開發，尤其是面向C端Scrum和Agile更常見，看板方法擅長把繁雜瑣碎的工作一目了然，例如客戶支持這類事務性工作。

談論Scrum不得不提到PDCA循環（如下圖），這是一種擅長探索和創造的工作 方式，我認為Scrum正是圍繞PDCA循環方式衍生出來的的一系列理念、原則和實踐（如backlog、sprint、user story）。它不是方法論，更不是公式，也有一些方法體系，但可供參考卻不該照搬，不同的項目可能需要非常不同但都可稱為Scrum的工作流程。

（PDCA循環）

如果只用一句話描述Scrum，我認為是：充分接納前景的不確定性，采取探索式前進，以為客戶實現價值為最終目的的開發方法。重探索輕預測，這是和線性開發方式的本質區別。

Scrum步驟由一個接一個Sprin(迭代)組成，因此新手想要快速上手Scrum的話，也許最該學習的是一個Sprint(迭代)從哪里開始和結束，如下：

1. 擬定和評估待辦事項清單

待辦事項即backlog，我的團隊叫需求列表/需求池，指可能要開發的功能列表。待辦事項有時來自需求方，但更應該來自產品經理的遠見和洞察。所有被提出的事項（無論是否看起來有價值）都不妨先放入清單，再進行維護。維護包括：

①評估需求價值、工期和緊急程度，去偽存真

②值得做的真需求排定優先級

③追蹤處理進度。

如何維護一個健康的backlog涉及細節很多，不妨參閱我的另一篇文章《如何維護健康的需求池》

雖然我的團隊習慣把待辦事項稱為“需求”，但我自己更喜歡《Scrum精髓》中的叫法——”價值“或者“特性”?！毙枨蟆痹趫F隊溝通中多指運營方而非用戶的需求，暗示產品對運營負責，而且暗示了團隊能預測產品的成功，這更符合瀑布式而非敏捷式方法；“價值”的叫法突出了敏捷的價值導向，為實現用戶價值每個角色都負有不可推卸的的責任?！疤匦浴钡慕蟹▌t突出了敏捷的探索精神，承認當前在做的未必是用戶真正需要的，只有檢測后才有定論?！皟r值”和“特性”都更能體現敏捷原則。

2. 沖刺啟動會

在上一步厘清需求優先級后，團隊所有人（至少所有角色）坐下來規劃下個迭代要做的需求，也就是消化需求表里優先級最高的需求。實際工作中，一些優先級不太高但是簡單易做的需求也會見縫插針安排到下個迭代中，以求達到最大工作量。

經過充分溝通后，對于下個沖刺應該完成哪些內容大家都應該達成共識。啟動會標志著沖刺的開始，一旦啟動任何人都不應該改動沖刺內容。也就是需求一旦進入需開發階段任何人不能進行改動。

為什么共識是進行敏捷的前提？

如果沒有共識，重視溝通，多方參與——容易扯皮，允許在“沖刺”前修改方案——容易推卸責任或拖延工期，每個沖刺交付最小可行化產品——基于各自利益對最小可行化無法定義，測試和迭代時也難對成果和方向達成一致。

舉例說明，如果某公司的開發團隊承接來自ABC三個不同產品線的需求，ABC對用戶價值的理解不同（都想讓自己的產品線占用盡可能多資源），在整個公司層面實現敏捷是很困難的。但是可以通過融合方式——關鍵點評審+盡可能晚確定最終方案，來結合兩種開發的優點

3. 每日立會

每天固定時間召集所有角色開一個簡短會議，盡量不超過15分鐘，目的是公告工作進展。

4. 成果展示和評估

開發完成并測試后，再次召集所有角色，展示成果，之后投入使用。

5. 沖刺回顧和新沖刺規劃

已完成的事項，大家坐下來回顧看看哪些比較順利，哪些可以做的更好。

回顧完成后立即開始下一個沖刺的規劃。

二、敏捷和線性的本質區別

如上文所說，個人認為沖探索輕預測是敏捷和線性開發方式的本質區別。如下所示：

• 敏捷開發：關照不確定性→探索式，注重應變→價值中心
• 線性開發：關照確定性→遵守規程，注重良好設計→過程中心

敏捷開發承認環境、團隊、用戶和自身的不確定性，認為市場需求難以預測，因此包容試錯、探索前進，在小步快跑中實時校對方向。校對的參照點是用戶價值，是否能為用戶創造價值作為評價工作的關鍵指標。

相對而言，線性開發關注確定性的內容，強調準確預測市場，根據預測進行盡可能完美的設計，設計出來的藍圖必須嚴格呈現，因此評價工作的標準也是藍圖實現程度，即使市場反饋可能并不盡如人意。

三、敏捷的適用場景

線性開發因為重預測，便于流程控制，但難點在于必須一開始就確定正確的設計范圍；敏捷開發因為是探索導向的流程，可以不斷深挖問題本質，提煉真正問題，但缺點是大項目跨部門時時間成本高。

由于敏捷方法以用戶價值為目標，瀑布方法以完美呈現藍圖為目標，項目制團隊中容易就價值達成一致，但是跨團隊跨部門甚至跨公司的項目中，各方理解的價值未必一致。如果能就用戶價值（也就是要交付的產品）達成共識，才能應用敏捷開發。如果無法達成共識，只能通過過程的控制減少溝通和時間成本，宜采用瀑布式開發。

根據優劣勢，不管是敏捷還是線性開發都有其適用場景——常用于戰略決策的Cynefin框架非常適合解釋敏捷開發適用的場景，如下圖：

1. 簡單域（simple）-已知的已知

當因果關系顯然而見時。處理手法為”感受－歸類－反應” （Sense-Categorise-Respond），如導出銷售額數據/制作巧克力蛋糕。Scrum不是好的選擇，更應該選擇已被證明正確的方法。

2. 繁雜域（complicated）-已知的未知

需要專家診斷后找出正確答案。處理手法為”感受－分析－反應”?。⊿ense-Analyze-Respond），如搭建底層數據庫/建造太空飛船。Scrum不是最佳方案，應該由專家處理。

3. 復雜域（complex）-未知的未知

因果關系只能從檢討中反映出來，難以預測，只能事后知道。處理手法是”試探－感受－反應”?。≒robe-Sense-Respond），如推出新產品/養育青少年。Scrum最擅長的領域。

4. 混亂域（chaotic）-不可知的未知

完全沒有任何因果關系的混亂情況，需要快速做出反應，沒有時間思考。需要的是”行動－感受－反應”?。ˋct-Sense-Respond），如911事件/系統宕機。Scrum不是最佳方案，需要的是立即行動。

5.?如果連屬于以上哪個情況都不清楚的，是一個無序的狀態（disorder），等待參與者把情況安穩至上面四個其中之一的情況。

軟件開發過程中可能涉及以上各個領域，但電商產品（尤其C端）大部分工作落在復雜域。需要實際工作中靈活適用。
 

本文由 @羊小雙雙 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。