敏捷在設計團隊中的實踐

除了理想的設計團隊外，從以往設計師工作的歷史也可看出和軟體開發相似的痛點：環境快速變化的不確定性、頻繁的需求變更、產品完整交付過程中跨專業的溝通落差。

以往這些軟體業的痛點被歸咎在採用了工業時代瀑布式的開發方法，敏捷的出現希望可以一定程度的協助團隊優化這些問題。
既然痛點如此相似，那又如何不能深入理解後，嘗試跨出工程團隊做應用呢？

理解那些是敏捷基礎功後，就可以更順利的應用好框架。
甚至在理解每個方法的本質後，可以彈性調整滿足不同情境。

整個 Scrum 框架在做的就是用一個流程，幾個簡單的活動，讓團隊可以面對複雜（Complex）的環境與需求。

我們的 Scrum Team 分成兩種：設計團隊、專案團隊。

設計團隊內的 Product Owner 是組長，Product 是內部系統設計規範，Product Goal 是「協助公司所有內部系統打造視覺一致、體驗一致、員工用起來省時有效率的軟體介面」。
在團隊產品的遠中長程策略中，更包含了「易維護的永續系統」願景。

專案團隊內的 Product Owner 是專案經理，Product 是特定資訊系統，Product Goal 是專案 KPI/OKR。

接下來我們用假設的角色情境來讓大家更容易明白整個運作方式。

設計團隊：共 8 人。
每日 9:15-9:30 開設計小組站立會議，同步工作內容和問題，有問題馬上或會後處理，組長隨時觀察同仁狀況提供協助。
每 2 週一個 Sprint，約一個月開一次 Review（團隊內），一季開一次深度 Retro（團隊內）。

專案團隊：共 12 個，設計團隊中每個設計師負責 1-2 個專案的 UIUX。
每週「固定時間」開 1-5 次不等的例會，頻次依經驗判定（產出相依性、時程緊急度、需求穩定度等），例會上成員同步工作內容和問題，有問題馬上或會後處理，Scrum Master 隨時觀察成員狀況提供協助。
每 2-4 週一個 Sprint，1-2 個 Sprint 開一次 Review （團隊+利害關係人），2-4 個 Sprint 開一次 Retro （團隊+主管）。

設計專業的內容和問題在設計團隊中揭露和處理，專案相關的內容在專案團隊中處理，彼此之間形成有效率的正向循環。
組長也需要適時參與專案的會議，實際了解組員的執行狀況，甚至觀察到更多可優化的問題。