多團隊開發如何落實敏捷

在2004年時，Nokia要導入敏捷開發方法。那個時候他們找了不少懂敏捷開發的人，Bas Vodde是其中一位。在那個時間點，他遇到了另一位顧問：Craig Larman。他們兩個從那個時候開始合作，也結成了好朋友。

那時候Nokia的狀況是這樣的，大多是一個產品很多團隊一起來開發。這和Scrum 所適用的狀況不同，Scrum所描述的，都是一個團隊要如何進行敏捷開發。對於多個團隊合作的狀況下，Scrum到底要怎麼使用，並沒有提出作法。所以他們進行了很多實驗，試圖找出最合適Nokia的作法。所以就有了《Large-Scale Scrum: More with LeSS》這本書的問世。

有些大規模敏捷框架的作法，會定義出很齊全的流程，再讓你自己去客製化。但是這樣的方式，在初期不懂的時候，使用的人根本不敢去客製化，並且多數人會全盤接受，導致用起來很卡、很繁重。很多人會覺得多一事不如少一事，不敢去承擔變動後的責任。初期不敢去客製化，後期也就不會。

Large-Scale Scrum（LeSS）規則是只列出基本必要的，剩下的部分，你必須針對你的環境，去建立你的流程。逼你一開始就要負責任，要去思考事情該怎麼解決。如同LeSS中的名言：以少換多（More with Less）。用較少的規則，來換取你的責任感。

所以LeSS和其他大規模敏捷框架不同之處有三點：

（1）實戰實驗：保留在戰場上實戰過，真的生存下來，真的有用的必殺技。

（2）保持簡單：本來大規模就很複雜了，如果流程又再複雜，你很難可以應用地很好。

（3）以少換多：避免提供鉅細彌遺的東西，讓團隊失去思考能力和彈性。

LeSS所參考的實踐

一、Daily Build（每日建構）

早期微軟在產品開發時，認為及早除錯是專案準時的關鍵。因為在最後才處理這些問題，往往會發現這些問題修完後，會再帶出其他問題。或者因為離原先寫出來的時間有點遠，需要較多的時間去回顧和處理。這些理由導致專案時間會拉更長，並且很難評估。

此外，開發人員被教育成錯誤是很嚴重，不應該被忽視。並且會討論如何避免這個錯誤？有沒有方法可以簡單偵測出這個錯誤？如何避免問題再發生？從這個錯誤中學到什麼？

因此微軟發展出Daily Build的作法，認為每天開發人員都要提交程式碼，以即時產生一個Build，可以確認自己開發或別人開發好的程式碼，是否能夠運作正常，或者是否會影響到別人。這就是後來衍生出來的持續整合（Continuous Integration）。

二、Feature Team

微軟當年認為開發團隊的最小單元就是Feature Team，由一群跨職能（Cross- Functional）的成員所組成，大家一起討論，一起決定要做什麼。讓大家有產品和程式碼擁有權，這樣運作起來才能更高效。

那個時候，微軟認為Feature Team必須獲得上級充分授權，讓他們有責任感，可以獨立作業，團隊成員之間的地位必須平等，並且要培養出團隊成員間的共識。

在傳統的組織中，團隊成員大多只是聽命行事，所以當Feature Team成立時，一方面希望透過這樣的協作，打破功能型組織（Functional Organization Structure）的籓籬。也就是開發人員不該只是想開發，品質也不該只有測試人員會擔心。另一方面，因為產品面對的問題十分複雜，需要有不同的專家出來建議，不能只靠產品經理。

三、廣度學習

微軟認為員工應該要持續成長，這樣對個人和公司是雙贏。很多時候你原先擅長A，之後只要工作跟A相關，都會交給你做。所以過了5年，你是A的頂尖高手，可是你也就只會A。微軟認為這樣不好，應該要讓員工去做不同的東西，或許一開始會花比較多時間，但從中長期來看，這樣才能讓個人和公司都成長。

LeSS的簡介

根據Scrum的框架你可以知道他是針對單一團隊的方法。可是對於多個團隊的話，那我們要怎麼進行敏捷呢？

Bas Vodde和Craig Larman在Nokia工作時，面對的就是一群團隊，因此他們想破了頭，做了很多實驗，最後才歸納出多團隊敏捷開發要怎麼進行。他們重新思考了Scrum的本質到底是什麼。他們認為Scrum的本質，應該是強調團隊成員如何自組織，一起協調工作要如何分配，要先做什麼才能帶給客戶價值，如果做得不理想那要怎麼調整。重點不是在於有哪些會議要開，或者是有哪些角色要扮演。

在Scrum中是由Product Owner、ScrumMaster和Dev Team所組成。在LeSS中認為組織結構是由Product Owner、ScrumMaster和一堆Dev Team所組成。所以Product Owner和ScrumMaster並不在Dev Team（團隊中）。要規模化的話，LeSS要規模化的是Dev Team。Product Owner和ScrumMaster盡量不規模化，讓角色保持簡單。但是不代表LeSS中只有一個ScrumMaster。

根據之前Nokia的大量實驗，以及規模化的重點在於團隊，以及思考如何協作規模化等精神。Bas Vodde和Craig Larman把這些的東西整理後，來跟大家說明LeSS包含了哪些：

一、Experiments（實驗）

Experiments是指之前Bas Vodde他們在某些情境下，嘗試過的作法。當你遇到問題時，這些Experiments可以帶給你很多靈感。

二、Guides（指南）

指出最多被人使用的實踐（Practices），告訴你別人是怎樣去落實LeSS的Rules，例如：[Guide：Multi-Team Sprint Planning Two]。在LeSS中進行Sprint Planning Two，遇到某個需求會和一些團隊有關係，這時候可以讓這些團隊各自指派一些人員，一起來討論這個功能大約要怎麼做。

在迭代一開始先弄清大概要做什麼，讓大家有些共識。這樣之後要拆解任務（Task），就會比較清楚要怎麼弄。

三、Framework（框架）和Rules（規則）

框架是指LeSS Framework和LeSS Huge Framework，針對不同大小規模的團隊使用。

Rule是用來定義LeSS的Framework，告訴你LeSS裡面有什麼。這是LeSS最核心最基本的東西。例如定義ScrumMaster的相關Rule：ScrumMaster是一份全職的角色、一個ScrumMaster可以服務1-3個團隊。

四、Principles（原則）

這是從之前Experiments，整理出來的心法，幫助你思考要如進行Experiments，如何進行導入。Rule只是描述了一些定義，但沒有告訴你背後是怎麼思考的。而Principle就是背後如何思考的心法。

例如：有條Principle是以用戶為中心，所以在LeSS的Rule中，我們會定義Scrum團隊是跨職能的團隊。這樣才不會因為功能性的組織，導致團隊只在意他所負責的功能，而沒有以客戶的問題為優先考量。（本文摘錄整理自《多團隊高效協作密技》，博碩文化提供）

圖片來源_博碩文化

 書名  多團隊高效協作密技：大規模敏捷開發方法Large Scale Scrum簡單學

敏捷三叔公 柯仁傑（David Ko）／著

博碩文化出版

定價：650元

圖片來源_ DevOpsDays Taipei官網

 作者簡介 

敏捷三叔公 柯仁傑（David Ko）

目前在Odd-e擔任Agile Coach，幫助企業導入敏捷、改善流程和提供培訓，台灣Agile Tour Taipei的組織者之一，也是國內最大敏捷社群的創始人，致力於推廣敏捷技術。

擅長敏捷開發流程、敏捷測試、軟體測試、設計衝刺（Design Sprint）和DevOps轉型。

Agile Summit、DevOpsDays Taipei的主辦人，譯有《Scrum and XP from the Trenches》繁中版。