close
上次提到 LeSS 的規則分成三個部分: (1) Structure, (2) Product, (3) Sprint. 我們已經看完 structure 的部分, 接下來我們來看剩下的兩個部分:
B. LeSS 的產品
1. 每個完整可交付的產品, 都只有一個產品負責人 (product owner), 一個產品需求清單(product backlog)
2. 產品負責人不應該單獨更新產品需求清單. 他需要團隊們來幫忙, 一起跟客戶和利害關係人來討論.
3. 所有的優先順序都須被產品負責人檢視過. 但是釐清這件事情, 盡可能團隊直接和客戶或是相關的利害關係人來討論.
4. 整個團隊有一份共享的做完的定義
5. 每個團隊有他自己擴充的做完的定義
6. 完美的目標是去改進做完的定義, 好讓每次的 sprint 可以產生可出貨的產品
C. LeSS 的 Sprint
1. 會有個產品層次的 sprint, 也就是每個團隊的 sprint 不會有不同長度的 sprint. 每個團隊同時開始一個 sprint, 並且同一時間結束. 每次 sprint 後會產生一個整體的產品
2. Sprint 規劃會議會分成兩個部分. 規劃會議第一部份是對於所有團隊的. 而規劃會議的第二部份, 通常是每個團隊自己完成的.
3. 規劃會議的第一部份, 會由產品負責人和團隊代表來參加. 他們會試圖選擇每個團隊下個 sprint 要處理的工作. 團隊會找機會一起工作, 並且確保最後的問題都已經被釐清.
4. 每個團隊有他自己的 sprint 需求清單 (backlog)
5. 規劃會議的第二部份, 是關於團隊決定如何處理所選擇的項目. 這通常涉及 sprint backlog 的建立和設計. 團隊會預測有多少項目, 他們認為可以在下個 sprint 中完成.
準則: 對於某些團隊, 他們會在共享的空間中進行, 以增加大家的協同合作
6. 每個團隊有他自己的 Daily Scrum
7. 跨職能的合作是由團隊間所決定
準則: 利用 Open Space 的方式來協同合作, 參與其他團隊的活動 (例如: Daily Scrum, Scrum of Scrums, 多團隊的工作坊, 或者單純地在相同地方工作), 彼此相互討論, 以及使用視覺化管理.
8. 產品需求清單精進會議(Product Backlog Refinement, PBR): 每個團隊對他們未來可能處理的項目進行此會議.
準則:
(1) 在每個團隊進行 PBR 之前, 先召開全體的 PBR, 由每個團隊的代表參加. 他們會探討那些項目是由哪個團隊處理, 並且從中增加學習和調整的機會.
(2) 召開一個由多團隊參加的 PBR, 以增加共同的瞭解, 以及發展協同合作的機會
9. 有個產品的檢視會議 (product review meeting), 對所有團隊來說是很普遍的事. 要確定有足夠的利害關係人, 對於 inspection and adaptation, 貢獻所需要的資訊.
準則: 使用分權式的"發散- 收斂”技巧, 以得到較好的回饋, 以及讓會議不會那麼無聊
10. 每個團隊有他自己的 retrospective 會議
11. 整體的回顧會議 (retrospective) 會在團隊的回顧會議後進行. 整體的回顧會議會討論跨團隊, 系統性的問題. 並且建立要改進的實驗. 這會議主要由產品負責人, Scrum Master, 團隊的代表, 以及經理們(如果有的話)參加.
準則: 整體的回顧會議是在下個 sprint 早期召開, 因為 sprint 的結尾通常會召開很多團隊層次的回顧會議
全站熱搜
留言列表
