7. 我們如何安排團隊的座位和空間
 
 
設計的角落
我發現到,大部分最有趣和最有價值的設計討論,通常自然而然發生在任務板前面。
 
基於這個理由,我們試圖把這個地方安排成一個明顯的"設計的角落"(design corner)。  
 
71  
 
這是真的相當有用,如果想要知道系統的概況,沒有比站在設計的角落前,看看牆壁上的內容,有更好的方法。然後再回來電腦面前,並嘗試一下最新版本的系統。(如果你很幸運的有持續整合的版本,請參見之後 "我們如何結合Scrum和XP")。
 
這個"設計牆"只是大的白板,它包含大部分重要的設計草圖,還有一些印出來的最重要的設計文件(循序圖(sequence charts),GUI的原型,領域模型(domain models)等等)。
 
72  
 
上圖:每日會議將發生在上述角落。
 
嗯……這個燃燒圖看起來太好,曲線看起來太直。但是團隊堅持說它是反映真實的狀況 :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展示會議除外)。
 
對於在敏捷環境下的經理們,上面的最後一句話,仍然是我能說的最佳綜合建議。有一位好的經理是關鍵成功的因素。但是身為一位經理,你應該試著讓你自己是多餘的。你可能不會因為那樣做而成功,但是在嘗試的過程會把你推向對的方向。多詢問”團隊需要什麼,才能讓他們自管理?”,而非”我如何可以管理這個團隊?” 這可能需要有透明度,明確的目的,有趣和激勵的工作環境,適當的保護,以及遇到問題時可以向上反映的管道。
創作者介紹
創作者 kojenchieh 的頭像
kojenchieh

David Ko的學習之旅

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