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