前情提要
自從開始接觸 Scrum 後, Fun Retrospectives 一直是我常常來作為參考的工具網站.
在工作上也會實際的運用, 在這裡特別記錄.
當然相同的方法在不同團隊使用, 我想會產生不同的效果,
所以也許未會有重複的活動也不一定.
角色期望矩陣
在 Fun Retrospectives 的分類之中, 是屬於 Team Building 的類型,
目的在於揭露團隊成員對不同角色的期望.
這個可以協助團隊同步對不同角色與自我角色的認知, 並且避免隱藏與未知的衝突.
進行的方式,
- 建立一列(橫軸)寫下所有(團隊中)的角色
- 建立一行(直軸)寫下所有(團隊中)的角色
- 承上, 畫出一個矩陣
- 詢問所有團隊成員, 請他們對所有角色的期望, 並且逐列(橫向貼)到白板之上
- 逐行討論所有角色的便利貼, 讓角色理解團隊的期待
A 社記錄
我額外作了一件事,
就是確定團隊成員中的角色, 主要原因是 A 社的 PO 功能是職責是有殘缺的.
討論的結果如下:
Dev
- 依需求/Spec/DoD 實作
- 溝通
- 拆分任務
- 自我測試/驗收
- 重構
- 架構不符需求時
- 效能
- 時間
- 空間
- 開發效能
- 研究
QA
- 測試
- 測試計劃
- 環境建立
- 寫測試案例
- 風險評估
- 優先序
- 自動化測試
PO
- 需求
- 設定優先序
- 設定 Sprint Goal/Product Goal
- 溝通
- 評估需求可行性
這裡有一個討論的觀點, 我覺得值得拿出來討論,
在探索的過程中, 有可能有以下幾種狀況
- 實際上有解法,有找到:這是最理想,也是最普遍的方案
- 實際上沒有解法,証實沒有:確定不可行,其實對產品也是一個重要的資訊,可以節省成本提早作出變化
- 實際上有解法,沒有找到:這是最糟的情況
- 實際上沒有解法,確說有解決方法:不是大好就是大壞,容我下面解釋
我原本認為, 如果實際上沒有解法, 卻研究出了解法, 可能是在溝通的過程中可能出現的了認知落差?
更嚴重一點, 也許是出現虛偽狡詐的情況. 但是團隊討論時, 出現了一種新的觀點,
現在作不到, 不表示未來作不到, 市場也許正好缺乏這個的解決方案.
反思一下,這不正是許多新創在募資時常用的方式,
當然不乏惡血、Juicero 或是 Nikola 這一類招謠撞騙的例子,
但是我們可以發現投資人其實是會為夢想買單的.
而要實現理論上可行, 但現實尚未成功或商品化的功能,往往是很燒錢的事.
新創產業正式將夢想與資金作結合, 而敏捷開發能加速我們探索未知.
有關於 PO 的探索, 會跑在 Dev 之前, 其中有一個很重要的目的是要提高 Dev 的勝率
排除「實際上沒有解法」或是「沒有市場價值的方案」是 PO 在探索重點方向.
參考
(fin)