f:id:mouseface99:20200420151152p:plain

在前一篇說明了，其實有許多的企業跟團隊，其實並不適合單純的導入 Scrum，或者其實根本就不需要單純的 Scrum。

可能是企業/產品屬性，團隊特質或是組成特性造成的。

由於台灣我待過的許多開發團隊中，公司本身可能就是屬於代工/外包性質，開發團隊本身對於產品本身可能基本上就沒有自主權，而是被動地被交付需求與時程。

或是分工較細的公司部門中，設計就得由設計團隊負責，測試就得由測試團隊負責。其他部門可能沒有餘力，或是沒有足夠的能力（或是公司不允許）跨越部門間的那道牆。

但是在專案管理上，又需要一種能夠快速迭代管理，快速反應市場，快速應對需求改變的方式。

或是某些團隊在導入單純的 Scrum 後，有意無意的發展出了這樣傳統與現代的混合模式。

f:id:mouseface99:20200420142910j:plain

傳統 Waterfall 的特性為：從產品需求的發想，設計，實作，測試，上線。一關一關都由特定單位負責，是有依序性的一個部門負責完之後再交付給下一個單位接手。

在這樣的前提下，如果把產品的功能/需求，利用 Scrum 的思維。拆分成許多相對獨立的 User Story 後。每一個 User Story 被標注了優先級後，透過一個既定的節奏/時間表，進行前期的準備/設計工作。

將實際執行 Sprint 的團隊限縮在只有開發/測試團隊。設計團隊必須在 Sprint planning 前準備好基礎的設計工作（不用到細節，但是至少要到可以開工的狀態）

然後一樣透過 Sprint planning / Daily Stand-up / Review / Retrospective meeting，以及 Backlog / Burn-down chart 等工具，來進行進度與成員的管理。

這就成了一個 Water-Scrum-fall 的雛形

具體作法

或許我所知道的做法不是正統~~（我也不確定是否有 Water-Scrum-fall 正統這回事...）~~

但是至少在我待過的幾個團隊中，這樣的方法是可行而且能夠還算良好的進行產品/專案開發以及運作。

首先，是一個 Timeline 框架。

f:id:mouseface99:20200421230434p:plain

這個框架，以開發 Sprint 的時間為核心，端看產品的開發迭代節奏（通常為 2~4週，但是很多是14天），然後以 Sprint Day 1 為中心，往前推估需求，設計需要進入/準備好的時間節點。

這邊以最常見的 14 天開發週期舉例，開發的前一週為設計與準備週，基本上進入準備週的時候，此迭代的需求就必須確定，然後進行一週的準備/設計工作

這部分可能會依據產品屬性不同，假設是外包屬性的產品，需求相對比較明確（且不能修改），開發團隊只需要知道 flow 以及底下的技術架構如何設計，這樣的話 Developer 與 QA 大約需要一週時間就可以完成準備
但是如果是自主產品，需要 UI/UX 團隊花時間設計功能/流程，並且可能還有要上級/市場部門簽核或討論的部分，這樣的話可能就需要把準備時間拉長到兩週左右。

不過具體的時間還是以各團隊的實際狀況動態調整

接著就是兩週的開發+測試期，務必在這兩週內把這個迭代的 User Story / Task 完成以及驗收完畢

所以這時候內容量的把控就很重要，通常一個新接觸的團隊可能需要 3~4個 sprint 才能慢慢抓出一個迭代能夠承擔的工作量（這時候 Story point 跟 Burn-down chart 就幫助很大了）

接著產品上線後，市場端與營運端會根據實際上線的狀況即時提出需要調整的內容（但是按照時程，這時候提出的需求其實會在 Sprint 3 的時候實作）

有些團隊可能還會把 QAT 的時間另外拉出來，也就是兩週的開發加上一週左右的測試。

這樣不是不行，但是要知道這樣的調整帶來的影響。

某種程度來說，這也就是把開發週期拉長到３週（由於要開發+測試完成才是能夠上線的產品）。

所以連帶影響的就是：

開發拉長到兩週，所以相對的可以完成的 User Story 會變多，但是前期準備時間是否足夠？是否要更拉長到兩週或甚至更多？
準備時間拉長後，連帶的影響的就是需求收版的時間也會跟著提前，然後加上三週的開發，這樣從需求確認到產品上線的週期就會跟著拉長。市場反應就會相對慢一些。

這些都是要連帶考慮的，並不是單純拉長一點，可以做更多東西而已。（極端一點，無限拉長到一整個產品的 scope 的話，其實就又打回成原始的 Waterfall 了）

考慮產品屬性、市場特性、團隊組成以及能力分佈，不斷調整到一個最適當的節奏，是每個團隊要持續優化的（這也是每次 Retrosprctive 要討論的重點）

所以從這個時間軸來看，其實團隊的迭代是一直不斷進行的，這部分要能夠跑得順暢不停滯，而且又能夠保持產品的品質（不然每次迭代都在修之前的技術債，或是 hotfix 的話也沒用...）

以下幾點就需要團隊從每次的迭代中慢慢去調整

兩週的 Sprint，這個團隊到底能吃下多少 Story point？
不只是開發/測試團隊，一週的準備時間，設計團隊是否足夠與市場/產品團隊討論/設計出符合市場需要的解決方案？（要到可以開工的程度）
兩週的開發+測試，開發與測試人員如何搭配？很多時候開發人員塞了過度的功能，導致幾乎做到最後一天才丟給測試團隊，導致測試時間或是修整 bug 時間不足，整體產品還是不合格的。開發/測試工作怎樣去平衡？或甚至可以並行的執行，但是又能夠確保產品整體品質。

實務經驗分享

雖然這幾年 Scrum 變成一種軟體開發的流行，好像公司不導入一個 Agile 就是食古不化一樣。

所以很多公司相繼的進行嘗試，但是可能針對台灣的公司屬性，產品特性以及團隊特質，很多時候都還是會或多或少演變成 Water-Scrum-fall 的模式

其實能演變成這樣還是比較好的結果，畢竟還是有一個能跑得順，能相對快速反應市場變化，又能夠有效管理的方法。
很多不好的例子甚至變成一個四不像的狀態，導致整體產出更低，更沒效率。

所以這邊提出幾個這幾年在實際參與甚至自己導入時，遇到的一些挑戰或是一些建議

概念上來說，其實 Water-Scrum-fall 就是把傳統 Waterfall 的流程，拆分縮減成到 2~4週左右的小 milestone，而且盡量在每個 milestone 都可以有一個「可上線」的產品
要享受到上面提到「能相對快速反應市場變化，又能夠有效管理的方法」，其實 Scrum 裡面的幾個原則與精神還是要盡可能遵守
- User Story 的定義與彈性還是要仔細定義
- Story point / Burn-down chart 是否有確實執行
- Sprint planning 確認後，盡可能地不要變動（就算有也要整體團隊都評估，確認完之後才能改變）
- 該有的 Planning / Daily Stand-up / Review / Retrospective 還是要確實執行
- 溝通 over 文件，但是該有的設計/定義文件還是要有，而不是只有淪於口耳相傳
對於需求管理，透過 Scrum 既有的 Product backlog / Sprint backlog 進行有效的管理與優先級評估
甚至在多個團隊需要相互依賴與合作時，可以利用 scrum of scrum 的架構下進行依賴管理

基本上，把 Product scope 的東西，拆分到多個 sprint 之後，其實開發/設計/測試團隊都需要在心理上做一些調整。傳統的先把大架構/框架定出來，然後再慢慢補上的那種 Waterfall 設計思維需要慢慢調整
Agile / Scrum 講求的是快速反應，快速做出最小可行方案（minimum viable product, MVP）然後去市場上驗證，再調整，再驗證，再調整。

所以如何快速的將目前已知的 User Story 做出來，但是又能夠在保持產品設計一致性，技術框架夠彈性的，這也是技術/設計團隊可以追求/提升的一個重點之一

很多時候，執行的重點其實都不在這些「方法」本身，盲從的去追求一些像是「儀式」的行為，但是不了解這些方法背後的意義以及目的是很可怕的。

所以， Agile 的一個核心精神，其實就在於團隊能夠隨時能夠動態的調整，如何在每次 planning / review / retrospective 的時候不斷讓團隊跑得更順，效率更高，單位時間產出更多，品質更好。才是團隊應該追求的目標。