Day 3 LeSS 如何誕生的

LeSS是 Large Scale Scrum縮寫, 由 Bas Vodde 和 Craig Larman 所整理出來的. 當初是怎麼來的呢? 根據 Bas Vodde 的回憶, 故事是這樣展開的 …

當初 Nokia 在 2004 年時, 他們要導入敏捷開發方法, 因此找了一些懂敏捷開發的顧問, Bas 是其中一位. 在那個時間點他遇到了另為一位: Craig. Craig 那時候是一本暢銷書的作者: Agile and Iterative Development: A Manager's Guide. 所以他們兩個就從那個時候開始合作, 也結成為了好朋友.

圖片來源: chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://agilecontracts.org/agile_contracts_primer.pdf

那時候 Nokia 的狀況是這樣的, 他們大多是一個產品很多團隊一起來開發. 因此, 這和 Scrum 所適用的狀況不同, Scrum 描述的都是針對一個團隊, 要如何來進行敏捷開發. 所以他們為了活下去, 進行了很多實驗, 來找出最合適 Nokia 的作法. 後來他們把當初針對大規模進行敏捷開發的作法整理起來, 記錄到以下兩本書中：

2010 - Practices for Scaling Lean and Agile Development - Craig Larman, Bas Vodde

2009 - Scaling Lean and Agile Development - Craig Larman, Bas Vodde

此外, 他們也參考了微軟的兩本書籍：

(1) Debugging the Development Process, Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams, Steve Maguire, 1994
(2) Dynamics of Software Development, Jim McCarthy, Denis Gilbert, 1995

除了這兩本書外, 他也發現到對手 Ericsson 的一篇文章:

XP and Large Distributed Software Projects, Even Andre and Lars-Goran Anderson

這是 Ericsson 他們實施敏捷開發的經驗談, 因為是相同產業的作法, 所以非常有參考性. 並且也很需要參考, 因為掌握對手是很重要的事情.

這些書籍或文章其實有不少共通點, 他們都選擇類似的實踐, 這些確實幫助他們很大. 其中有幾個日後對LeSS 的影響很深遠：

(1) Daily Build

微軟認為每天開發人員都要 check-in code, 以即時產生一個 build, 讓他們可以確認自己開發或別人開發好的程式碼, 是否能夠運作正常, 或者是否會影響到別人. 這就是後來衍生出來的持續整合 (Continuous Integration).

(2) Feature Team

微軟當年提出這個觀念, 認為開發團隊的最小單元就是 feature team. 由一群跨職能的成員所組成, 大家一起討論, 一起決定要做什麼. 讓大家有產品和代碼擁有權, 這樣運作起來才能更高效.

(3) 擴大學習

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

此外, 記錄做了哪些時間的那兩本書, 大家對他們的評價很好, 覺得他們提供了很多務實的做法, 可以讓他們知道有哪些作法可以嘗試. 但是同樣的他們也說到, 太多實務了不知道要先做哪一個, 是否可以直接告訴我們答案, 我們照著這樣做就好. 所以 Bas 意識到他們之前寫的兩本書, 是落在守破離中的破和離, 哪些人知道何時要打破規則, 哪些時候要創造出自己的規則. 因此, 他們需要再出一本書, 是落在守破離中的守的層次. 告訴人們要如何來進行多團隊間進行敏捷開發. 所以就有了 Large-Scale Scrum: More with LeSS 這本書的問世.

他們花了不少時間將前兩本書去蕪存菁, 把一些基本的東西保留下. 可是他們擔心一個問題, 到底應該要講多少. 如果跟大家講很多規則 (Rules), 大家就不會動腦, 直接就照著去做. 如果講很少, 大家就會認為不完備, 不想要去使用它. 這有點是蛋生雞, 雞生蛋的味道. 他們思考了很久, 忽然想到 Scrum Framework 的作法. 熟悉敏捷開發歷史的朋友應該知道(就是老一輩的人), 在 Kanban and Scrum – making the most of both 一書中, 有張圖片(如下圖所示) 說明了 Scrum 的規則很簡單, 只說了 要開會 必要的規則, 其他就是讓實施的自己決定要怎麼做. Bas 他們也採取這樣的思維去制定 LeSS, 只保留必要的規則 (Rules), 其他的就給實施團隊去決定怎麼做.

source: Kanban and Scrum – making the most of both

有些大規模敏捷框架的作法, 是定義出很齊全的流程, 然後讓你自己去客製化. 但是這樣的方式, 往往造成使用的人在初期不懂時, 根本不敢去客製化, 因此全盤接受去用, 導致用起來很卡, 很繁重. 並且人人往往是多一事不如少一事, 不太敢去承擔變動的責任, 所以初期不敢去客製化, 後期也就不會.

LeSS 規則是只列出基本必要的, 你必須一開始就針對你的環境去建立你的流程. 逼你一開始就要負責任, 要去思考事情該怎麼解決. 這就是如同 LeSS中的名言: 以少換多 ( More with Less). 用較少的規則, 來換取你的責任感.

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

(1) 根據實戰實驗得來：保留實際上在戰場上實戰過, 真的生存下來, 真的有用的必殺技.
(2) 保持簡單性：本來大規模就很複雜了, 如果流程又再複雜, 你很難可以應用地很好.
(3) 以少換多：避免提供鉅細彌遺的東西, 讓團隊失去思考能力和彈性.