Scrum團隊之持續產品開發模式

June 07 01:20~02:49

 

關於Scrum團隊的特性，鄉民們最常聽過的應該是以下兩點：

• Self-organizing team：Scrum裡面沒有專案經理或是主管來「盯進度」或是「指派工作」，而是由團隊成員自己管理自己，自己估算工作時間，自己負責產出物的品質，自己認領工作等等。
• Cross-functional team：團隊中包含著所有需要完成產品或專案所需的不同專業背景成員。

Teddy今天要談的是第三個平常比較少提到也容易被忽略的特點，那就是Scrum團隊採用的是所謂的「continuous product development model（持續產品開發模式）」。傳統的公司，尤其是規模比較大的公司，通常採用的是「project-centric model（專案中心模式）」。簡單的說，專案中心模式就是公司所有的開發活動都是以「專案」為中心來分配資源（好像沒有解釋到）。假設公司一共有20個開發人員分屬不同的部門（包含程式設計師、介面設計師等不同專長的人），公司目前手邊有四個專案正在進行，平均每個專案分配到五個成員。假設某一天增加了一個專案，公司便從原本每個專案中各抽調一個人到這個新的專案裡面。假設有專案正常結案或是被終止，則專案中的人員就歸隊到原本所屬的部門。也就是說，所有的開發人力被公司看成是一個「人力池子」，專案有需要，就從這個池子裡面拉人。如果池子已經乾枯了（沒有閒置人力），就從各個專案中抽調人力過來支援（南水北調？）。

這種專案中心模式看起來很合理，反正有案子就調人來做，案子結束就把人歸隊，似乎可以達到最大的人力使用與調配的效率，但缺點可能會造成無法形「團隊」的歸屬感。每個人都只是公司內可被「調用」的一種「資源」而已，到處打游擊，案子結束就歸隊。如果這種「案子」只是短期的計畫案，或是不像軟體開發這種會有「維護需求」的專案，那也許問題還不大。但是，如果是較長期的軟體開發案，或是案子結束之後還是會有滿長一段「維護週期」的專案，採用專案中心模式就不見得很合適。為什麼？

• 案子結束人都解散了，那誰來做維護的工作？不用擔心，反正公司還會有一個「維護專案」的團隊，他們會負責。但是，試想如果你是專案成員，只要負責開發，不必管長期維護或是未來後續開發的可能性，那麼你會用什麼樣的心態來看待目前手邊的開發工作？答案很簡單，就是「程式可以動就好了啊」。更精確的一點，應該說「程式在專案團隊解編之前可以動就好了啊」。反正專案結束之後就不關我的事了，所以幹麻花時間去考慮品質或是擴充性這種非功能需求。「程式看起來可以動就好了」。
• 採用專案中心模式的公司，專案未完成之前就被終止的情況並不少見。久而久之，參與專案的成員心裡會想：「反正這個專案可能有33%的機率可能會被提早結束，那我幹嘛花心思把程式的品質做好？」慢慢地，開發人員可能會失去原本「把產品做好」的動力，轉變成交差的心態。
• 專案中心模式的每個專案，都會搭配一位專案經理來負責專案的進度以及資源的調配。如果找到負責任有能力好的專案經理，那麼專案進行起來相對會順利很多。很可惜，這種好的專案經理百年難得一見。最常遇到的情況是，專案經理把開發人員當成「可置換人力」來使用，而沒有考慮到軟體開發的本質與「生產線的組裝工人」是不一樣的。在管理上專案經理經常會落入所謂的「形式管理」，翻成白話文就是「我才不管你怎麼做事，或是遇到什麼困難，反正時間到你就是把東西給我生出來就對了」。這種專案經理與開發團隊成員之間的不愉快合作模式，經常也是造成專案失敗的主因之一。
• 專案中心模式容易造成「分工但不合作」的工作模式，團隊中的成員各做各自負責的模組，彼此之間不見得知道其他人在做些什麼。只有要一個人出問題，其他人很難幫得上忙。換句話說，專案可能會卡在某個人的身上，而每個人也都卡在某個專案上面。

***

扯了這麼多，那到底什麼是持續產品開發模式？在這種模式之下，沒有反覆性的專案剛開始（找人）、專案進行中（找更多人）、專案結束（歸隊）。也不需要有專案經理來控管專案時程與分派工作。那Scrum團隊到底有什麼？

• Product Owner。
• 很長壽的自我管理團隊。
• ScrumMaster。
• 永不終止的sprint（除非專案退休不再有人使用為止）。

看到這邊鄉民們可能會覺得：「又不是每個專案或是產品都需要開發很久，有些專案三到六個月就結束啦，那這種持續產品開發模式不就不適用？」

持續產品開發模式的一個重點是「很長壽的自我管理團隊」，也就是說專案可以結束，但是團隊不要任意打散，因為要建立一個自我管理團隊是一件很花時間的工作。但是一旦有了這樣的團隊，他們的工作效率（生產力）與品質可以大幅提升，所以打散團隊，尤其是軟體開發團隊，是一件很笨的事情。

所以，維持你的團隊。讓這個團隊依序去執行不同的短期專案。換句話說，團隊不變，但是相同的團隊可以開發不同的專案。

那如果一個專案的工作量還是不夠塞滿這個團隊在一個sprint裡面工作該怎麼辦？例如，有一些專案已經不再開發，但是多多少少還有一些bugs需要修正。不過這些bugs又不足以讓團隊整個sprint都有事情可以做。作法很簡單，可以讓團隊同時負責多個專案，然後採用比較短的sprint（例如一週），然後在不同的sprint負責不同專案的工作。例如，sprint 1解專案A的bugs，sprint 2解專案B的bugs，依此類推。

最後，萬一同一專案的工作量還是無法讓團隊在一週的sprint長度裡面都有事情可以做呢？那就只好把多個專案的工作都安排到同一個sprint裡面。但是如果要這樣做，會造成所謂的「工作切換」的問題（請參考「消除浪費 (5)：Task Switching」），所以在挑選story的時候就要盡可能避免過多個工作切換（同一個sprint中，開發人員必須在不同的專案中切換來切換去）。

***

結論就是，要讓Scrum團隊有生產力，就要：

• 培養長壽的自我管理團隊。
• 一個sprint只專注於一個產品或一個專案。

***

友藏內心獨白：Scrum團隊口訣---自我管理、自給自足、長壽無疆。