執行SCRUM-23 -使用者故事(5)

最近對於使用者故事User Story的撰寫，對於團隊成員的意見，產生了一點反思。緣起是，團隊開發的怪手PMIS系統，由於客戶希望知道每周，專案人員在怪手的使用情形，所以需要增加系統報表功能。
針對客戶的需求，產品經理寫下了User Story，

這是管理者的需求，要向專案的PM回報怪手的使用情形，
1.我能夠知道某個時間區段(1周、2周、1月、或自設)怪手各個專案的活動紀錄，包含登出入的人員與次數、在怪手中的各項作業(每個功能的增刪修，人與時間)。
2.包含統計資料及列表，例如新增公文10筆，若需要可以觀看列表
3.可以在畫面呈現資訊，可以產生PDF報表
團在討論這個User Story時，團隊成員認為應該依Scrum建議的格式來寫，如下(參考：https://www.tenlong.com.tw/products/9789863479468https://medium.com/3pm-lab/3-use-cases-for-writing-effective-user-stories-cd42625fef53)
User Story 的形式通常為一句話：
As a ______, I want to ______, so that ______.
身為 ______，我需要一個方法來 ______，因為 ______。
1.身為管理者，我需要一個方法來顯示怪手使用者登錄及資料，因為我要了解某時間區間，系統負載及有無異常登錄情形
2.身為系統設計者，我需要顯示每個頁面的熱度，因為我要了解使用者行為及系統操作是否正常
後來，我反思這2者區別在於，先前的敘述是根據我腦中的畫面，寫成類以User Story的情形，好處是，後續工作者只要依樣畫葫蘆就可以完成功能，但是缺點會被我的思考所限制，或許有更佳的解決方法而被忽略。我覺得2種方法並沒有對錯，運用之妙，存乎一心，在時間受限的狀況下，或許第一種方式可以先解決問題，並快速進入疊代修正；而在時間寬裕的情形下，依第二種方式，可以發揮腦力激盪，提出更好的解決方案。