上一篇記錄完團隊層次之後, 接下來看項目集層次.
所謂項目集是指 Program, 不知要翻成什麼中文比較合適. 他是一個由一堆敏捷團隊所組成(也就是 team level 介紹的那種團隊), 持續交付對客戶有價值的增量.
1. 發佈列車
在 SAFe 中以 Agile Release Train (ART) 這樣的隱喻來形容 program level. 他是一個虛擬的組織, 由不同功能性部門聚在一起, 實施精實的原則, 排除不必要的交棒浪費, 來加速交付價值給客戶.
你必須依市場狀態, 來決定發布節奏和迭代長短. 通常 ART 會以 60 - 120 天的頻率, 來發佈可能交付增量(Potentially Shippable Product Increment). 在這個發佈會議中, 你需要考量以下事情:
- 建立共同的願景 (Vision)
- 根據市場預期, 規劃特性的優先順序
- 計劃下一個發佈所要交付的特性和時程, 並且做出承諾
- 調整資源以匹配所要做的事情
- 產生或更新路線圖 (Roadmap)
2. 團隊
(1) component team 或者 feature team
component team: 團隊負責某個元件, 或是多個元件. 因此他們精通某項技能.
feature team: 由多種角色組成, 會較多技能. 著重於交付某個有價值的功能, 而非元件.
這兩種組成敏捷團隊的方式, 有各自的優缺點, 各自有是用的時機, 因此混合起來使用會是比較好的做法.
(2) 發佈管理團隊 (Release Management): 雖然每個敏捷團隊是完成功能的人, 但是他們不一定有較高的視野, 能通西市場, 並且有權限來決定何時, 或是以何種方式來交付東西給客戶.
(3) 系統團隊 (System Team): 各個敏捷團隊產生的功能, 可能沒有進行整合測試. 或者在有些狀況下, 單獨的團隊無法進行這種大規模的測試, 因此需要有單獨存在的團隊做這樣的事情.
(4) Devops: 運維是不可或缺的一部份. 要有人來處理環境, 部署, 維護, 備份等工作. (我知道他很重要, 但是他也可能是因為流行的關係, 也把這個東西特別強調出來)
3. 特性 (Feature)
願景基本上是由一組特性去實踐出來的. 當系統為客戶實踐這些特性, 客戶將會得到他想要的需求.
也就是說, 客戶一開始會有些需求, 想要我們去解決. 因此, 系統會提供一些服務, 來滿足客戶的需求. 這些服務也就是所謂的特性, 每個特性會拆解成一些軟體需求(故事). 這些故事會放到代辦事項 (backlog) 中, 由敏捷團隊來處理.
故事完成後, 需要經過驗收測試來確認是否完成. 同理, 特性完成後, 也是要有特性的驗收測試來把關.
看起來, 遊戲越來越複雜了. 能包進去的, SAFe 都想考慮放進去....
全站熱搜
留言列表
