最近教育了一間公司的產品團隊什麼是 Scrum，讓整個產品團隊開始真正的走上產品開發循環的道路，頓時有種「天啊，原來一套有效的管理制度，對新創公司的幫助是這麼的大！」的感覺，談技術開發者的工作，比較難談論如何幫產品提升價值，然而，身為一個技術管理者，最大的職責就是幫助公司用最有效率的方式，發揮所有技術工作者的最大效能，簡單來說，就是 Cost Down，不過並非一直加班或是壓榨工作者的方式，而是讓每項專業的工作者，都能在適當的時機發揮專業，這就是技術管理的價值所在。
什麼是 Scrum？
如果熟悉敏捷開發的朋友，應該對於 Scrum 這個名詞並不陌生，要認識 Scrum 之前，有一些基本的名詞是一定要先了解的：
Scrum Master
主要是維持 Scrum 體制的人，最常出現的地方就是在 Meeting 的時候負責主持會議的人，這邊必須特別強調，Scrum Master 不負責評估時數，而是為了避免在 Meeting 中忽然有人插入新的議題，Scrum Master 必須去負責擋住新的議題的產生。有的公司 Scrum Master 會用資深的工程師負責去協助解決技術上的問題，也有公司的 Scrum Master 會用 PM 來擔任 Scrum Master 的角色。
Product Backlog
描述產品的所有功能，可以用 User Stories 的方式來進行描述。通常會依據重要程度給予每一個 Story 一個分數，並且針對每一個 Story 工程師會進行時數的評估，而每一次的開發循環就會根據分數以及時間就選定部分的 Stories 進行，直到 Backlog 裡面不再有任何的 Stroy。
Product Owner
負責提出 User Stories 的人。通常 Product Owner 沒有資訊的背景，反而比較多可能是業務相關的背景，這樣才能將公司要做的產品銷售出去，Product Owner 跟工程師常常是處於背道而馳的狀態，但也因為 Scrum Master 在中間居中協調，所以讓 Product Owner 隨著 Scrum 運行的時間越久，越能夠了解產品的技術狀態，跟 User Stories 該怎麼提出是最適合的。
Sprint
短期衝刺。通常衝刺以一到兩個禮拜作為一個 Sprint，在每一個 Sprint 的開始會從 Backlog 裡面選定要做的stories，然後整個sprint 就是進行 stories 的開發，根據經驗，在 sprint 的過程中，會分為寫程式的時間以及解決Bug的時間，通常大概二比一的時間，而每個 Sprint 的最後，會有一個 Sprint Demo，最主要就是要展示目前產品做的狀況是什麼。
圖像來自寓意科技公司內部管理文件
Stand-up Meeting
Daily Scrum 最重要的一環，用10分鐘的時間，讓所有的開發者進行回報以及提問，通常每個開發者會回答三個問題，「昨天做了什麼？」、「今天預計做什麼？」、「有什麼被卡住的問題？」，這樣可以讓一個團隊之間的步調以及問題最快達到同步，然後大家各自繼續進行開發。
圖像引用自網站搞笑談軟工，相關Scrum 的介紹也可上去看更多
Scrum 最大的好處就在需求改變的時候
所有做產品的人都了解，產品走向改變的時候，通常都是最惱人的事，不過卻是大部分產品都一定會發生的，而 Scrum 的方法，最好的特點就在於每一個開發循環通常只有一到兩週，所以 Product Backlog 隨時都可以接受增加或是減少，而不會影響到當下 Sprint 的進展，對於工程師來說，每一個 Sprint 的開發，都是專注在當下的 Ticket 跟 User Story，因此即使其他的功能已經改的完全不一樣，也能夠讓工程師寫程式的時候不受外力干擾，這樣能夠將 Product Owner 跟技術工作完全切開，就不怕工程師一直跟 Product Owner 吵架了。
為什麼強烈建議要用 Scrum？
Scrum 這個概念生存的目的就是為了更快推出產品給使用者試用看看。因此，不管是管理外包還是自己的工程師，都該好好運用 Scrum。現行的軟體工程比的是上線的速度，軟體產品比的是貼近使用者的程度，越貼近使用者的工具，越能夠讓使用者願意掏錢使用，就像今天 Gmail 跟 Dropbox 如果空間不夠大，要每個月花個60元新台幣去擴充空間，你一定心甘情願。但如果是中華電信的雲端儲存硬碟要免費讓你試用三個月，你搞不好連開通帳號都懶，原因就是因為 Gmail 跟 Dropbox 已經讓你習慣了它的存在，而這就是軟體的世界 —— 先搶先贏。也因此，假設想做產品，不斷的進行開發的循環，Scrum 最大的好處就是建立一套有制度的溝通方式，讓 Product Owner 提出的需求不會亂掉，而工程師的思考邏輯，也不會因為大家天天討論產品方向，而亂了開發步驟。
結論
Scrum 只是一種制度、一種概念，不見得執行 Scrum 對每個團隊就一定有好處。不過我常常遇到一些團隊，在我剛去的時候提出的議題是：「工程師合作了一兩個月，有越來越懶散的趨勢，要管理也不知道從何下手。」、「系統架構變大後，規劃產品不知道從何下手，安排開發的優先順序，每次更新都要等好長一段時間」，其實這些都是管理以及溝通上的議題，在工程的議題上，最怕的是失焦，大家不在同一個世界講話，在這點上，Scrum 也許能夠進行一些協助，不過當然也仰賴團隊裡面對於技術管理比較有經驗的人來主持，會讓產品開發的循環順利許多。
關於 Scrum 這個議題，如果大家有任何問題或是想法，歡迎在下方留言指教或交流!
Photo Credit: Stephan Voigt
