[Scrum] 使用 Scrum 進行敏捷軟體開發

來源 : http://www.intelligentbee.com/blog/2015/02/20/should-you-do-scrum/

團隊專案 在進行團隊專案時，我一直感受到如果沒有特定的流程，效率會很低。這次在感受到新村、江南地區軟體成員（SoMem）以 Scrum 方式進行開發後，我深受啟發，因此讀了一本書，想了解 Scrum 並將其應用到專案中。

「必須時刻小心，不要讓 Scrum 或敏捷變成團隊本身的目標。」

「Common sense isn't common. 常識並不普遍。」

「若要用一句話定義 Scrum，那就是：『讓我們更早、更頻繁、更多且持續地給予與回饋吧。』」

書中提到 Scrum 很簡單，它還說明了只需要不到 10 分鐘就能解釋完所有規則。然而，它也提醒，理解 Scrum 的哲學與「為什麼」可能需要 10 天，而要真正落實 Scrum 可能需要超過 10 週的時間。即便如此，它依然說 Scrum 很簡單。

Scrum 簡介

來源 : http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/2000px-Scrum_process.svg.png

產品待辦事項清單 ( Product Backlog )

首先，產品待辦事項清單是列出系統需要解決或包含的所有事項，即功能 (Functionality)、特性 (Features) 與技術的清單。所謂產品待辦事項清單，是指依照優先順序排列的產品所有需求清單。產品待辦事項清單永遠不會是最終確定的，而是會隨著產品一同成長與演進。產品待辦事項清單中優先順序最高的項目就是最需要的項目。任何人都可以提出產品待辦事項的內容。使用者、客戶、銷售部門、行銷部門、客戶服務部門以及技術部門皆可提交項目。

然而，只有產品負責人 (Product Owner) 才能賦予產品待辦項目優先順序。產品負責人實際上決定了什麼會先被開發。

衝刺待辦事項清單 ( Sprint Backlog )

Scrum 團隊是自我組織且完全自主的。Scrum 團隊僅受限於其所屬組織的標準與慣例，以及他們所選擇的產品待辦事項。如何將選定的產品待辦事項轉化為產品增量 (Product Increment)（這裡的產品增量似乎意指衝刺待辦事項清單），完全取決於開發團隊的決定。團隊會管理該衝刺 (Sprint) 要執行的任務清單，即衝刺待辦事項清單。

衝刺 ( Sprint )

每個 Scrum 團隊都會進行開發，團隊會設定一個 30 天的循環週期，稱為衝刺。在衝刺期間，會選擇認為能夠開發完成的產品待辦事項。每個衝刺結束時，都必須交付一個已加入新功能且可執行的產品。事實上，架構與設計並非在第一個衝刺就完成，而是經過多次衝刺後才會逐漸顯現。

Scrum 主管 ( Scrum Master )

為了讓 Scrum 順利進行，團隊必須具有自發性與信念。在衝刺期間，管理人員（即 Scrum 主管）會強制要求團隊成員實踐 Scrum，並幫助團隊做出決定或取得必要的資源。 在衝刺期間，團隊不應受到團隊外部任何人的干擾或指使。

每日 Scrum ( Daily Scrum )

Scrum 團隊每天會進行稱為每日 Scrum 的簡短現況會議。在每日 Scrum 中，管理人員會審查進度並確認需要消除的障礙。每日 Scrum 是確認團隊進度的絕佳方法。

衝刺結束時

團隊會與管理人員一同召開衝刺檢視會議，針對此次開發的衝刺待辦事項進行審查。測試完每個衝刺待辦事項（產品增量）後，管理人員通常會整理產品待辦事項，以利活用團隊成果。產品待辦事項相對於部分開發完成的產品，具有更大的意義。一旦產品待辦事項穩定，團隊會在下一個衝刺再次從中挑選優先順序最高的項目。重複這一系列過程並完成衝刺。這種循環結構——基於經驗主義的管理成本、時間以及功能與品質進行評估——將持續進行，直到判斷產品具備潛在的發布能力為止。與此同時，也會規畫發布衝刺以準備產品發布。

Scrum 是？

Scrum 很直接。

Scrum 拋棄了不適當且惱人的管理慣例，只保留工作本身。

Scrum 讓團隊自由發揮並專注於工作。

Scrum 為開發人員提供了專注於工作並快速產出高品質產品所需的一切管理與控制權。

來源 : http://www.codeproject.com/KB/architecture/scrum/diagram02.png

## 參考資料 ：Scrum：極大化團隊生產力的敏捷方法論，肯·舒瓦伯 (Ken Schwaber)