大家在實施 Agile 時, 常會遇到一個問題, 如果人數很多時, 那我們要怎麼辦?
 
這以前確實是 agile 的一個大問題, 在最近幾年, 很多人提出不同的方法來解決 scale agile 的問題, 像是
 LeSS, SAFe, Enterprise Scrum, DAD, RAGE 等等.
 
xless-huge-framework.png.pagespeed.ic.QeG8WFpHTh  
source: http://less.works/less/less-huge/index.html
 
不管什麼方法, 個人覺得一定要很簡單, 要讓大家容易了解, 並且要該 scale 在對的地方. 可是很多方法都並沒有讓我有這種感覺, 總覺好難把他們搞懂.
 
今天在 Scrum Gathering Shanghai 2015 時, 聽到一個範例, 讓我覺得眼睛為之一亮.
 
講者出了一個題目, 問我們說, 如果現在你們部門很大, 切出 3 個 scrum 團隊時, 這時候你的 scrum role, scrum meeting, 和 scrum artifacts, 那些要保留三份(各個團隊各一份), 哪些只要精簡成一個就好?
 
這是非常有趣的題目, 大家討論得十分熱烈. 但是不管最後答案是什麼, 講師問了我們一個問題, 你是根據什麼準則寫出你的答案的?
 
後來大家歸納出, 我們大致是依這個準則去劃分的:
會只有一個的: 通常跟產品有關. 像是總共一個 product owner, product backlog 來對付多個 team等等.
會各自有一個的: 通常跟團隊有關. 像是每個團隊進行自己的 daily scrum, retro 等等.
 
所以講師要我們了解的, 我們應該要展延的是 dev team, 而不是 scrum team. 也就是你應該把展延的複雜度放在處理人多這件事, 而非放在把配合流程所產生的東西上面, 例如: 多個 product owner, scrum master. 
 
我們要加的是做事的人, 要讓做事的人方便. 而不是去加處理流程的人, 或是讓流程變得更複雜. 
 
或許我不知道哪個 scaled agile 的方法最後會勝出, 但是我想這應該是日後選擇的標準之一吧. 流程是要來幫助有效率的, 而非讓事情更難處理的.
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 kojenchieh 的頭像
    kojenchieh

    David Ko的學習之旅

    kojenchieh 發表在 痞客邦 留言(0) 人氣()