在 Agile Summit 2018 時, 台灣敏捷社群 (AgileCommunity.tw) 舉辦一個活動: 敏捷突擊隊. 邀請企業提出問題, 然後社群的志工想辦法來解決.
為什麼會有這個活動呢? 主要是看到了對岸敏捷圈有這個活動, 覺得這樣的活動很有意義, 不但推廣了敏捷, 也驗證社群自己的實戰經驗. 因此, 就和上海的組織小夥伴說一聲後, 就在台灣這邊舉行. 如果你對對岸的活動有興趣, 可以參考以下文章
台灣敏捷突擊隊的處女秀, 是處理 X 公司(目前事主無法公開公司名稱) 所提出"如何切分 tasks”, 與會者如下:
X公司兩位員工
敏捷社群 兩位志工
問題背景
團隊結構
(1). 目前有兩位 RD，只是一位負責硬體產品上的 Android App，另一位負責 Web，在手機、平板上使用 Brower
(2). UI designer 是共用資源, 測試人員也是共用資源.
(3). 三個角色來自三個不同部門
(4). PO 負責很多專案, 這只是他其中一個專案, 不見得有太多時間能陪團隊
目前Task的切分流程
(1). PO 拿出要完成的 PBI (product backlog item)
(2). 由開發團隊(實際要開發的團隊成員)針對這張 PBI 進行實作 task 的切分
(3). 由開發團隊說明每一個 task
(4). 由開發團隊評估每一個 task 的大小(時數)
(5). 由開發團隊認領可在這個 sprint 時間內完成的 tasks
目前在 task 上的要求
(1). 使用預估工時取代 story point
(2). 單一task不得超過 6 hr，若超過，要求再切細，或是先換成一張 study 的 task，待 study 完再切分 tasks。
遇到的困擾
A. 在 planning 就可以把 product backlog item 的 80% 的情境都考慮到嗎? (*可以*: 完成的時間點可預估的較準確, *不可以*: 需要較多時間來做未考慮到的情境, 導致功能完成的時間點不如預期)
B. 遇到不清楚如何做的地方，所以 task 無法切細
目前作法: 先規劃一個 survey 的時間，但有些時候必須實作才能清楚。
C. 不知如何切細，要到多細？
D. 如何累積切 task 的經驗？
E. task 切不完整，之後會補 task，會造成 task 增加，導致 task 在整個 sprint 無法完成，做不完，有沒有機會減少這種情況。
F. 在預估時數時，仍然有一種在「承諾」必須達成的壓力。
如何產生需求
(1). PO 先簡述大老闆想要什麼
(2). RD, UI designer, PO 一起討論細節, 過程中會手繪畫面和操作流程
(3). PO 會利用步驟 2 結果, 跟大老闆再次確認需求
(4). UI designer 會產生步驟 2 結果的文件出來
(5). RD 根據此文件開始撰寫程式
(6). RD 在時做過初中發現問題, 會提出來, 讓 UI designer 來修改
===> 洞見: 發現步驟 4 中所產生的文件並不是很詳細. 很多細節或是 scenario 並沒有描述
建議的方向
基本上, 需求不明確, 導致後面有很多問題: 不知道怎麼估時間, 會做錯方向, 會追加功能. 因此儘早釐清需求, 可以減輕 A, B, E 等困擾
目前可以嘗試的方向如下
(1) 增加確認需求的關卡
a. UI draft 產生後, RD 檢視 UI draft 的內容
b. RD 架構設計完後, 有問題立刻和 PO 確認
c. RD 針對故事 (功能) 撰寫實例化需求, 然後請 QA 檢視
==> 以上三者, 都需要管理者幫忙, 確保這三個不同部門的角色, 彼此檢視活動的時程能夠配合
==> 這些檢查關卡可以視專案狀態逐步加以實施, 不見得一開始就要全部實施, 下重藥是會死人的.
==> 在專案結束後或者 retro 時, 可以檢討其效果. 沒人可以一開始就做對, 重點是持續改進.
(2) 如果目前無法增加確認需求的關卡
建議在這個版本記錄以下資訊
a. PO 追加什麼需求
b. RD 補了哪些需求的 task
在進行下次版本時, 這些資訊可轉換成
checking list: 提醒各個角色不要忘記考量這些事情
acceptance criteria: 可以當下次要怎麼寫實例化需求的參考
(3) task 切多細不是問題, 因為目前你們規範的大小 (6 小時), 已經算很小, 你們的問題在於需求不清楚, 導致會漏需求, 進而需要補 task. 如果需求明確, C 和 D 的困擾就不會是大問題
(4) "不知道 task 要怎麼實作, 要先 study, 並且 study 不知道要花多久. 或者 study 完後, 架構可能大改"
這個問題, 在一人團隊中很難有解法. 如果可以有額外資源, 可以幫忙進行 POC 的工作, 可以減輕此狀況.
愛因斯坦說: 如果給我一小時拯救地球，我會花59分鐘去界定問題，花一分鐘去解決. 如果軟體要開發的快, 前面花在處理需求的功夫就不能省. 這不一定要慢, 也不是強調要很多時間寫詳細的文件, 而是要花心思, 去思考如何梳理出好的需求.
軟體開發沒有太多神奇的地方, 基本上就是做好基本功, 多檢視, 多寫測試, 多記錄一些必要資訊. 很多問題就不會那麼嚴重.
下次, 我們會利用開放空間會議的方法, 來討論敏捷轉型和導入的問題. 有興趣的人, 千萬不要錯過 2018/8 月份的活動喔
全站熱搜
留言列表
