Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
7. 我們如何安排團隊的座位和空間
設計的角落
我發現到, 大部分最有趣和最有價值的設計討論, 通常自然而然發生在任務板前面.
基於這個理由, 我們試圖把這個地方安排成一個明顯的"設計的角落"(design corner)
這是真的相當有用, 如果想要知道系統的概況, 沒有比站在設計的角落前, 看看牆壁上的內容, 有更好的方法. 然後再回來電腦面前, 並嘗試一下最新版本的系統.(如果你很幸運的有持續整合的版本, 請參見之後 "我們如何結合Scrum和XP")
這個"設計牆"只是大的白板, 它包含大部分重要的設計草圖, 還有一些印出來的最重要的設計文件(循序圖(sequence charts), GUI的原型, 領域模型(domain models)等等)
上圖: 每日會議將發生在上述角落
嗯...... 這個burndown chart看起來太好, 曲線看起來太直. 但是團隊堅持說它是反映真實的狀況 :o)
讓團隊坐在一起
在安排座位和桌椅佈置時, 有一件事情再怎麼強調也不為過:
讓團隊坐在一起
說的更清楚一點, 我所說的就是讓團隊坐在一起
大家都懶得動, 至少我工作的地方是這樣. 他們不要去收拾他們的東西, 拔下電腦插座, 把所有東西搬到新的座位, 在插上電腦電源. 當距離越短, 他們越懶得去搬. "拜託, 老闆, 搬這這5公尺的作用是什麼?"
然而, 為了建立有效率的scrum團隊, 沒有其他選擇. 就是要團隊坐在一起. 即使你必須親自威脅每個人, 幫他們搬他們的裝備, 清除他們的咖啡污漬, 也要搬在一起. 如果空間不夠, 那就創造空間. 就算你必須把團隊放到地下室, 也要去做. 把桌子搬在一起, 賄賂辦公室管理員, 竭盡所能, 只要團隊能在一起.
一旦團隊坐在一起, 好處就馬上出現. 只要一個sprint完後, 團隊會同意搬在一起是一個好的主意(從我個人經驗來看, 你的團隊有可能因為太固執而不承認這一點).
現在, "坐在一起"是代表什麼意思? 桌子應該要怎麼擺? 好的, 我沒有太多意見怎樣擺最好. 即使我有, 我會假設大多數的團隊沒有這麼有錢, 可以決定桌子可以怎麼擺. 通常會
有一些空間上的限制 - 鄰近的團隊, 廁所的門, 在房間中大型的自動販賣機, 等等.
"坐在一起"代表:
# 互相看到: 團隊中所有人都能彼此交談, 不需要大聲喊叫, 或是離開座位.
# 互相聽到: 所有人都可以看到彼此, 看到任務版. 不需要靠的太近也能夠看到上面的內容, 至少可以看到大概的樣子
# 隔離: 如果你的團隊突然站起來, 會自動地進行熱烈的設計討論. 沒有團隊以外的人會被打擾到, 反之亦然.
"隔離"並不是意味著團隊需要被完全的分隔起來. 在一個隔間式的辦公環境中, 只要團隊有他自己的隔間, 並且夠大, 可以去屏障大部份外面的噪音, 那這樣就足夠了.
如果你是一個分散式的團隊呢? 好的, 那就沒那麼幸運了. 可以用一些高科技工具來幫你降低傷害 - 視訊會議, 網路攝影機(Webcams), 桌面分享工具(desktop sharing tools)等等.
讓產品負責人坐在隔壁間
產品負責人應該坐的離團隊很近, 所以團隊可以走過去問問題, 產品負責人也可以走過來看看任務版. 但是他不應該和團隊坐在一起. 為什麼呢? 因為他可能無法控制自己, 去管一些更進一步的細節, 導致團對無法"凝結"的很好(也就是,無法達到合作無間, 自我管理, 有超高生產力的狀態)
老實說, 這是我自己的猜測. 我並沒有實際遇到過產品負責人和團隊坐在一起的狀況, 所以我沒有實際根據去說那是一個不好的主意, 只是個人直覺和聽別的scrum master的訴說
讓經理和教練坐在隔壁間
這時候, 對我來說有點困難去提到這件事, 因為我既是經理, 又是教練...
我的職責是盡可能和團隊緊密工作, 我建立數個團隊, 在團隊之間切換, 和成員搭檔編程(pair programmed), 培訓Scrum master, 組織sprint規劃會議, 等等. 事後, 大部分的人認為這是件好事, 因為我在敏捷軟體開發方面很有經驗.
但是, 另一方面, 我同時(這時星際大戰中黑武士出場的音樂響起)也是開發團隊的主管, 在行政上是經理的角色. 也就是說, 每當我來到團隊時, 自主性會自動降低. "好討厭, 老闆來了, 他可能又很多意見, 是有關於我們應該做什麼, 或是誰應該做什麼, 讓他去說吧"
我的觀點是: 如果你是scrum的教練(可能也是經理), 就應該盡可能貼近團隊. 但是只是有限的一段時間, 之後就離開, 讓團隊凝聚在一起和自我管理. 每隔一段時間(不要太頻繁), 藉由參加sprint展示來查看團隊的狀況, 看看任務板, 參加他們每天早上的每日會議. 如果你看到可以改進的地方, 把scrum master叫到一旁去指導他, 記得不是在團隊的面
前這樣做. 如果你的團隊非常相信你, 不會看到你就不說話, 那就去參加他們的sprint回顧會議, 這是另外一個好的方法.(請參考後面的章節"我們怎樣做sprint的回顧")
對於運作良好的scrum團隊, 確認他們可以得到一切他們所需要的東西, 然後就可以讓他們自行處理 (除了sprint展示會議除外)
留言列表
