最近飽受產品需求不清楚之苦, 因此, 想知道敏捷這邊, 對於大型系統的需求是如何處理, 所以, 病急亂投醫, 隨便拿了一本書來看:
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise
後來才發現, 其實這算是一本講解 SAFe 的書, 對於人多的狀況下, 公司或團隊要如何進行敏捷開發. 但是對於處理複雜需求, 或是不確定的需求, 似乎沒有什麼可以馬上採用的解法.
不過, 既然看了, 就簡單整理一下 SAFe 的想法, 讓自己印象深刻一點.
基本上, SAFe 把整個組織分成三個層次: 團隊層次, 產品層次 和 組合管理層次.
首先, 我們先來看看團隊層次 (Team), 主要包含以下概念:
A. 敏捷團隊
- 由 7 +- 2 名成員所組成的團隊. 這些成員包含完成故事所需的所有角色, 以及所需的所有技能.
- 在每個迭代中, 成員會進行定義, 建構與測試使用者故事.
- 然後在數個迭代後, 會發佈一些有價值的東西給用戶
B. 團隊成員
- Scrum Master
- 產品負責人: 最好和團隊在同一個地方工作, 並且參與團隊的活動
- 開發人員: 包含架構師, UX, 程式開發人員, 以及其他相關專案需要用到的人員.
- 測試人員也包含在其中, 因為敏捷團隊要能對自己的產生的品質負責.
基本上, SAFe 提倡組織的基本單元是 Scrum 團隊, 不喜歡 silo. 另外, 即使是 scrum 團隊, 你可能有兩種組成的方式: feature team 和 component. SAFe 並沒有限制一定要哪一種, 他認為混合的狀況, 比較可以應付較多情形.
對於測試人員, 很多人可能不太清楚, 他在團隊中需要做什麼, 書上有敘述了一下, 基本上和大多 agile testing 的書差不多
- 在 RD 撰寫程式碼時, QA 撰寫測試個案
- 和 RD, PO 討論故事, 確保真的了解, 以開立正確的驗收測試
- 執行驗收測試
- 不斷發展測試自動化
C. 團隊代辦事項
在 Scrum 中稱為 product backlog. 但是在 SAFe 中, 認為團隊要做的事情不見得單純跟 product 有關, 因此用 product backlog 來描述, 並不是那麼精準. 所以擴大解釋成 backlog, 以用來包含團隊所有要做的事情.
代辦事項清單中包含: (1) 使用者故事, (2) 其他工作項目 (重構, bug, 基礎建設, 部署等等).
對於每個代辦事項會要求進行驗收測試, 或者是單元測試.
總觀起來, SAFe 在團隊層次:
- 接受企業內有不同專業角色存在, 說明各自要做什麼事情.
- 把測試工作說明清楚, 強調要進行單元測試和故事驗收測試.
- 其他和傳統 Scrum 要做的事情差不多
好啦, 目前看起來, 保留角色這招對很多企業很管用, 尤其是那種正規軍, 或者比較傳統型的企業. 人總是不喜歡被改變太多地 ….
全站熱搜
留言列表
