實無眾生得滅度者

August 26 13:37~14:28

 

昨晚〈C.C. Agile#48 - 組織導入敏捷的困境、機會、挑戰與疑惑〉繼續嘗試「開放空間技術」（Open Space）的形式。Teddy發現上個月也有參加的兩位朋友，在上次討論中提問很多Scrum團隊的問題，怎麼這次沒有發起討論議題？一問之下原來在上次活動中這兩位朋友獲得許多建議，而他們回去之後也努力嘗試，短短一個月之內解決了原本非常困擾他們的主要問題，所以這次就沒發起新的討論議題，改派他們另一位同事提問。

在上次聚會中，原本這兩位朋友很擔心團隊合作與開發進度這個兩互相影響的問題。在一般專案中，當「有人」認為開發進度不如預期的時候，很多負面情緒就會跑出來。例如懷疑員工偷懶、不認真、沒有企圖心、能力不足等，然後就會想要怎麼「控管」這種現象。

在上次討論中小組成員提供的建議其實很簡單，主要有兩點：

• 縮短sprint長度。不少Scrum團隊原本的sprint長度可能是兩週，但發現許多功能在兩週內無法完成，於是就自然覺得如果把sprint長度延長成三週或四週應該可以解決這個問題。殊不知sprint長度延長之後更多的需求會被放入sprint中，所以事情還是做不完。更糟糕的是，原本兩週可以發現這個現象而有機會加以調整，sprint長度拉長之後回饋週期變長，問題變得更加複雜。
• 採取pair programming。「開發進度是否正常」這件事是很難加以預估，因為軟體開發是複雜性很高的工作，一路上遭遇到的風險、不確定性太高，所以很難準確預估。有些人採用Scrum之後發現原本sprint planning會議中團隊成員預計要完成5個user story，但實際上只完成了3個。於是主管可能開始討論怎麼樣才能「預估準確」，或是私底下懷疑團隊成員某某人（或全部）都在打混摸魚，要想辦法來「盯進度」。所謂「疑人不用，用人不疑。」比較正面的方式可以鼓勵團隊成員採取pair programming的方式來完成每一件工作。兩兩一組一起工作，往「壞的方面想」可以互相監督，往好的方面想可以互相學習，技術交流，而且開發出來的程式碼品質通常會比較好。

***

以上兩個建議，這兩位朋友回去之後全面落實。而且出乎預料之外，pair programming居然大受團隊成員歡迎。他們現在的困擾反而是當人數是奇數的時候有一個團隊成員會落單找不到人pair programming。

***

友藏內心獨白：很少遇到一個月之內改變這麼大的團隊。