團隊從二月初導入 Scrum 專案管理方式，到現在將近三個月，
Run 了 6 個 Sprint 共 10 個 Story，
Success 了 9 個 Story，
Fail 了 1 個 Story，
現在正在 Run 第 7 個 Sprint 兩個 Story。
什麼是 Scrum？Scrum 的本質、精神是什麼？
可以參考以下兩篇：The Scrum Guide、Scrum是甚麼?
Scrum 和傳統專案管理的方式比較起來，更著重於溝通與合作，
將傳統方式的事後維護、翻修等成本，挪了部分到事前，
轉化為綜觀瞭解和集體溝通達到共識的成本。
以國家體制來比喻， Scrum 像是民主，傳統方式像是專制。
民主和專制沒有對錯或優劣，完全視人事時地物而定。
凡事先從好的來說，
有一個非常有能力、果斷和遠見的領導與一群願意拼命刻各式螺紋的人們，
專制的效率產能會極高，
有一個和藹親民的領導與一群平均水準、素質、獨立思考高的人們，
民主的氛圍就會比較好；
反之，
碰到相反條件的領導，專制就是一種毒藥，
碰到無法凝聚共識、沒有主見、不夠成熟的人們，民主讓事情進展緩慢且紛亂。
觀察
使用 Scrum 至今，觀察到的幾個點：
1. 產品方向與受眾不明
若並非因考慮過專案和團隊是否適用 Scrum，單純為了用 Scrum 而用 Scrum，
像是讓家長買單 E 化課程卻沒什麼內容和品質的兒童美語班，
容易淪落於字面上的「敏捷式開發」而趕 Sprint，卻未好好思考產品走向，
開發一個又一個 Story (需求)，卻未好好觀察市場 (使用者) 反應適時調整，
甚至並未明確鎖定主打市場。
2. 意外成本累積
由於 Story 敘述的是一個使用情境，
而
為了讓 Story Success 而趕時間，若沒有在 Sprint Planning 階段思考周詳，
往往會有漏網之可能性或暫時的解法，導致後期的翻新、維護成本劇增。
3. 角色定位及分工方式混淆
傳統方式將角色分為 Product Manager、Project Manager、Designer、Developer、QA等，
而光 Developer 又分為前端、後端、架構等等，
轉換到 Scrum 時，一般定義為 Development Team，並不再細分角色，像個大熔爐，
每個人可能這次任務是前端，下次任務是後端，每個人都 cross-functional。
然而，這衍伸出一些問題：一般工程師前端接後端、後端接前端問題比較小，
至多多花一些時間適應、調整，但設計師呢？QA 呢？
每個人看的會的似乎變廣，那深度呢？過去說的「術業有專攻」、「機會成本」？
建議
綜合以上，有幾個建議：
關於第一點和第二點，建議於每幾個 Sprint 之間插入修整期一至兩週，
Stakeholder、Product Owner 與 Scrum Master 在這期間可以重複調查與評估產品走向，
Development Team 則可以將實際使用發現遺漏的地方修補，
也可以將暫時的解法代換為更佳的解法，避免累積至後期牽一髮動全身之尷尬處境。
第三點則建議，在 Development Team 內仍舊分工，Designer 做設計、QA 做測試。
Designer 在前期將大方向設計出好，細部圖的部分可以先用暫時圖替代，再設計細部圖；
Developer 在前期可以先處理架構，再依據大方向的設計開始開發；
QA 在前期則能進行測試的規劃和撰寫，接下來依據 Developer 開發完成的項目測試；
若使用 TDD (Test Driven Development)，測試的規劃甚至要更先於開發。
如此，將免去角色定位及分工的問題，也不致於人力資源的空轉，
而分工至多細，如：前後端要再分？QA 也轉為 Developer？則依團隊情況而定。
總結
使用 Scrum 要著重在 Scrum 的本質與精神，而非邯鄲學步，
因應產品、團隊狀況做調整，才能發揮得淋漓盡致、擁有最佳效能！
沒有留言:
張貼留言