[SCRUM] Scrum 是什麼（1）：雙重回饋機制－Foxbrush

Ref: http://teddy-chen-tw.blogspot.tw/2011/12/scrum-1.html

==========================================

以下為幾種常見對於 Scrum 的說明：

首先看看 Wikipedia上面的英文與中文解釋：Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.（Scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。）這可能是絕大多數鄉民對於 Scrum 的印象，一種敏捷專案管理框架。請把重點放在專案管理這四個字上面，所以想到 Scrum 就想到專案管理。
接著看看 Ken Schwaber 與 Mike Beedle 在 Agile Software Development with Scrum, p 2, 的說法：Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. 相較於專案管理這四個字，Scrum 是一種『management and control process （管理與控制流程）』感覺起來比較抽象一點。

把 Schwaber 與 Beedle 所寫得書讀到最後，會發現作者想要表達的『management and control process』的精神。不過，廣義的來講，專案管理也包含了『management and control process』。為了簡單起見，就先把 Scrum 當成是一種『敏捷專案管理方法』或是『敏捷專案管理框架』吧...雖然 Teddy 潛意識中不太喜歡把 Scrum 說成專案管理的方法。

***

接下來是重點，如果把 Scrum 看成是一種敏捷專案管理方法，那麼這個方法的內含是什麼？和傳統的專案管理方法有何不同？在介紹 Scrum 內含之前，先看一下 Scrum 與傳統一般專案管理最大的差異之一，在於 Scrum 有如下圖所示的『雙重回饋機制』。在軟體開發中，下圖左邊的『輸入』是『軟體需求』，中間『流程』那一塊表示軟體開發活動，最後的『輸出』表示軟體本身（也可以包含設計與使用文件等）。從輸入經過開發流程到產品輸出，在 Scrum 的術語中這一段時間稱之為『sprint（短跑或衝刺）』，另一個與 sprint 相同意思但卻更一般化的說法叫做『iteration』。廣義的來說，敏捷方法（agile methods）將一個軟體專案的開發時程（假設 6 個月）切割成若干個『時間長度固定（time-boxing），例如兩個禮拜』的開發活動，這種時間長度固定的週期就稱之為一個 sprint 或是一個 iteration。如果一個專案是 6 個月後要釋出產品，開發團隊採用為期兩週的 sprint，那麼這個專案就一共有 12 個 sprints（先不要管每一個 sprint 要做什麼，以及如何將需求分配到每個sprint 這些問題）。

所以，採用 Scrum 的團隊就是要在每一個 sprint 結束之前（每兩週）完成上圖從輸入端丟入軟體需求，然後經過開發流程，最後產生產品。圖中從輸出那端拉了『兩條回饋線』，一條透過『demo meeting（sprint demo or sprint review meeting）』回饋到『輸入的需求端』，另一條透過『retrospective meeting，回顧或是反省會議』回饋到『開發流程』。

這兩條回饋線的含意是：

Demo meeting: 每個 sprint 結束時，開發團隊要 demo 本此所完成的功能給客戶（或是客戶代表）看，讓客戶確定此次所開發的功能是否符合客戶期待。如果不符合則可以在之後的 sprint 加以修正（此為回饋機制的意義，有錯則改之）。由於每個 sprint 週期很短（一般 Scrum 團隊採用 2 週至 4 週的 sprint），所以可以避免傳統開發專案在專案晚期客戶才發現問題但卻沒時間加以修正的困境。
Retrospective meeting: 軟體開發除了需求可能不符合客戶所需，軟體開發流程本身如果沒有做好管理，也很容易開發出『低品質』的軟體。例如，bugs 太多，程式無法擴充，沒有自動化測試等等。所以，在每個 sprint 結束時，除了 demo meeting 以外，Scrum 還有一個稱之為 retrospective meeting 的活動，用來檢討與軟體開發流程有關的議題。在這個活動中，團隊成員們探討（1）那些開發作法是好的，應該要繼續維持下去。例如，有導入持續整合，或是有持續做 pair programming；(2) 有那些與開發流程有關的地方沒有做好需要改善的。例如，自動化單元測試做的不夠多，或是測試硬體設備不夠；（3）擬定改善計畫（action plan）。

在了解 Scrum 的內含之前，希望鄉民們先了解與細細品味一下 Scrum 『雙重回饋機制』的重要性。其實這個『雙重回饋機制』是一種很簡單的作法，但是對於改善軟體開發（需求與流程）卻是相當有用（PS:還有 time-boxing 的觀念也是很重要滴）。