要寫一篇講下 Scrum / Agile 怎樣運作。
本地很常見 Scrum 都運作得不很正規；普遍觀察是少於一半是運作適當的。Scrum 運作不良，不單純是品味或名目上的問題。因為 Scrum 是設計得很精妙的，本身每個設計細節都包含著很多智慧和管理經驗。若違反 Scrum 方法，差不多都保證會有某些已知的管理問題。而這些典型的管理問題都是 Scrum 的設計想針對解決的。
~ Scrum 基本步 ~
最簡單、最普通的 Scrum 是由三方組成：
- Product Owner (PO)：用前篇（連結）的職位所分類，就是 BA/PM 類型的人。就是負責按企業和商業環境而提出需求和設計的人員。也是項目的 Sponsor，就是取得 Budget 和所需權限的人。
- Development Team (Team)：就是開發團隊。一般包括 Engineer、Tech Lead、Architects。
- Scrum Master (SM)：維護這個 Scrum 方法的人員。若 PO 和 Team 之間有不同意見，就需要負責解決。以維護 Scrum 方法的暢順運作。
基本方法或原則：
- Scrum 一般都有個循環週期長度。例如一週、兩週、一個月，等等。通常是以短為優。
- PO 有權提出需求。將需要放到 Backlog。但不可以強迫 Team 從 Backlog 中選取甚麼。也不可決定 Schedule（見下面 Team 操作）。
- Team 有權從 Backlog 中揀選項目作這週期的開發。基本上揀選後就要負責完成。當中可與 PO 協商，但 PO 無權干預。而若 Schedule 上脫期，即是完成不了，那麼作為失敗的項目論，重新排進 Backlog（企業在管理上可以有 Penalty）。
- 每個週期的末段，即 Team 完成開發後，PO 有權揀選任意項目，作為推出上線。Team 無權過問，而且需要確保項目上線後能暢順運作。這是 Scrum 與 Devops 連接的部份。
- 項目若有資源不足或缺乏的問題，由 PO 負責解決。因為 PO 是 Project Sponsor。
可以看到這個 Scrum 的設計，本身是兩邊的權力的限制與平衡。若有不同意，由 SM (Scrum Master) 負責調和。
Scrum 的設計是解決一些常見問題。若要窮盡需要很複雜的講解。篇幅到此不贅。
科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile
Stories Tech Biz 