前言

業(yè)務(wù)敏捷可以定義為一個(gè)組織重塑自我并快速適應(yīng)環(huán)境變化的能力挖炬〕克勞斯.利奧波德在他的書《Rethinking Agile》中提出，人們需要優(yōu)化交付客戶價(jià)值的流來實(shí)現(xiàn)業(yè)務(wù)敏捷威根。通過優(yōu)化流膀斋，你遲早會(huì)注意到需要組織結(jié)構(gòu)做什么樣的調(diào)整來加以支持。

首先获黔，關(guān)鍵是理解敏捷的真正含義蚀苛，就像敏捷宣言中構(gòu)想的那樣，它并不是組織交付客戶價(jià)值的速度玷氏，而是組織以低成本快速響應(yīng)變更的適應(yīng)性堵未。（參閱《Scaling Lean & Agile Development》中 Be Agile一章）。利奧波德對于組織變革還有這樣一個(gè)觀點(diǎn)：在持續(xù)地關(guān)注系統(tǒng)優(yōu)化目標(biāo)時(shí)盏触，人們會(huì)注意到那些阻礙改進(jìn)的因素渗蟹。然而通過系統(tǒng)思考，長時(shí)間在實(shí)地的觀察和實(shí)踐赞辩，對現(xiàn)存系統(tǒng)動(dòng)態(tài)的反思雌芽，人們也可以預(yù)見到那些阻礙快速適應(yīng)能力的相對明顯的現(xiàn)存組織障礙。在這個(gè)故事中辨嗽，一個(gè)組織學(xué)習(xí)并最終看到影響大規(guī)模適應(yīng)性的組織障礙世落，它經(jīng)歷了漫長而痛苦的過程。更糟糕的是糟需，很多管理層試圖保持傳統(tǒng)管理現(xiàn)狀而僅僅將事物標(biāo)記為"敏捷"屉佳，而不是去預(yù)見 - 或者愿意去預(yù)見 - 相對明顯的障礙并在一開始就進(jìn)行必要的變革谷朝。簡而言之，這個(gè)過程恰恰反證了LeSS中的關(guān)鍵導(dǎo)入原則（"對于產(chǎn)品團(tuán)隊(duì)武花，要在一開始就建立LeSS的組織架構(gòu)圆凰，這對導(dǎo)入LeSS非常關(guān)鍵"）以及由此帶來的后果。

所以体箕，接下來的案例說明了专钉，如果組織沒有在一開始進(jìn)行合適的組織設(shè)計(jì)，會(huì)發(fā)生什么情況累铅。從開始的傳統(tǒng)組織架構(gòu)和管理方式入手跃须，可能混有一點(diǎn)偽Scrum元素，LeSS要求的組織設(shè)計(jì)也許會(huì)浮現(xiàn)争群。但這將會(huì)是一個(gè)更長回怜、更危險(xiǎn)的旅程，因?yàn)樗赡懿粫?huì)帶來導(dǎo)入LeSS所預(yù)想的好處换薄。為什么玉雾？因?yàn)橐坏]有立即采用新的組織架構(gòu)，那股保持組織現(xiàn)狀的強(qiáng)大力量極有可能會(huì)獲勝（參閱拉曼組織行為定律）轻要。

本案例的關(guān)鍵"反事實(shí)"洞察：如果你想開始業(yè)務(wù)敏捷的旅程复旬，期望減少過程中的許多痛苦，并快速獲得LeSS所預(yù)期帶來的適應(yīng)性上的提升冲泥，一定要在導(dǎo)入LeSS的開始階段就建立合適的組織結(jié)構(gòu)驹碍，就象LeSS規(guī)則所倡導(dǎo)的那樣。

開始之前的評注

LeSS就是（多團(tuán)隊(duì)的）Scrum凡恍，Scrum就是單一團(tuán)隊(duì)的LeSS志秃。（參閱原則：大規(guī)模Scrum也是Scrum）。為了讓本案例中的描述更加準(zhǔn)確嚼酝，我還是會(huì)澄清哪些是Scrum指南中的規(guī)則浮还，哪些是LeSS指導(dǎo)方略中的規(guī)則。在參與這個(gè)案例的過程中闽巩，我受到less.works網(wǎng)站的積極影響钧舌，參加了Bas Vodde和Craig Larman的LeSS實(shí)踐者課程，并花費(fèi)了大量時(shí)間閱讀最初出版的兩本LeSS書籍涎跨⊥荻常可惜的是那時(shí)第三本書還沒有出版。在這個(gè)案例中隅很，我闡述了我們嘗試過的LeSS實(shí)驗(yàn)撞牢，并且也會(huì)關(guān)聯(lián)我們遵循的LeSS原則、規(guī)則和指南，盡管那時(shí)并不知曉普泡。

簡介

下面的案例涵蓋了我從2015年2月到2016年9月在一家公司Sys的IT組織做外部教練的時(shí)光播掷。Sys是一家來自德國的從事軟件行業(yè)的跨國公司审编。因?yàn)槲乙押炇鸨Ｃ軈f(xié)議撼班，所以不能在此公布公司的真名和其他相關(guān)的公司信息。時(shí)間回到2014年底垒酬，Sys著手用一個(gè)平臺(tái)來變革公司軟件銷售方式砰嘁，取代現(xiàn)有各種外部合作伙伴平臺(tái)。這個(gè)平臺(tái)的誕生標(biāo)志著Sys邁入電子商務(wù)新途徑的里程碑勘究，不僅重新思考了如何直接地向客戶銷售軟件矮湘，還重新定義了賣什么（例如，除軟件以外的數(shù)據(jù)）和怎么收費(fèi)口糕。

圖1: Tanja Wehr繪圖 - www.sketchnotelovers.de

2011年棠绘，我曾在負(fù)責(zé)所有內(nèi)外部平臺(tái)的Sys IT部門工作過件相，這些平臺(tái)跟Sys商店很像，那時(shí)我們整個(gè)部門開始將瀑布模式替換成Scrum氧苍。在用（單團(tuán)隊(duì)）Scrum的方式搭建了兩個(gè)平臺(tái)之后夜矗，我離開了這家公司，去支援其他客戶的敏捷之旅让虐；在2015年的早期紊撕，我又重新加入Sys來支持這次重要的旅程。

變革之前

系統(tǒng)架構(gòu)

圖2: 系統(tǒng)架構(gòu)

變革之前的組織結(jié)構(gòu)

圖3: 變革之前的團(tuán)隊(duì)結(jié)構(gòu)

圖4: 變革之前的組織架構(gòu)

痛苦的最后期限和變革的必要

當(dāng)我在2015年2月底加入時(shí)屿良，平臺(tái)基本上已經(jīng)可以使用圈澈，只差正式宣布。各團(tuán)隊(duì)還在沖刺最終官方發(fā)布日期：2015年5月5日尘惧。到時(shí)候公司會(huì)在美國舉行有史以來最大的會(huì)議康栈，首席數(shù)字官會(huì)當(dāng)場向公眾演示這個(gè)平臺(tái)。所有正在研發(fā)的功能都是官方需要發(fā)布的功能褥伴，所以谅将，項(xiàng)目辦公室制定了一個(gè)看起來能在5月2號(hào)發(fā)布所有功能的嚴(yán)格的項(xiàng)目計(jì)劃漾狼。該計(jì)劃包含了研發(fā)階段重慢、系統(tǒng)集成階段，用戶驗(yàn)收測試以及回歸測試逊躁，就像我們通常說的瀑布模式似踱。

在三月的最后兩周和整個(gè)四月項(xiàng)目進(jìn)入一個(gè)動(dòng)蕩期。時(shí)間表正漸漸延期稽煤。當(dāng)并行工作在不同功能的團(tuán)隊(duì)將他們的代碼合并到主代碼倉庫后核芽，很多之前已經(jīng)測試通過的功能不再能使用或者表現(xiàn)異常。不停修復(fù)這些問題又帶來新的問題酵熙，并且還經(jīng)常突然接到必須立刻實(shí)現(xiàn)的新需求轧简。在此之上，之前從未考慮過的安全問題和負(fù)載測試現(xiàn)在也必須解決匾二。管理層變得十分焦慮哮独，每個(gè)人不得不工作更長的時(shí)間來盡量滿足計(jì)劃。在四月的最后兩周察藐，還建立了一個(gè)"作戰(zhàn)室"皮璧，所有的經(jīng)理、團(tuán)隊(duì)負(fù)責(zé)人和架構(gòu)師都在這個(gè)房間從早到晚不停的清理障礙以保證發(fā)布的所有準(zhǔn)備工作都做好分飞。最后悴务，開完數(shù)不清的升級會(huì)議和成百上千小時(shí)的加班之后，團(tuán)隊(duì)終于能夠在大會(huì)的第一天發(fā)布平臺(tái)的新版本譬猫。

經(jīng)過了如此痛苦的發(fā)布讯檐，對管理層來說，毫無疑問現(xiàn)有的研發(fā)方式已經(jīng)不能支撐公司的雄偉目標(biāo)染服，那就是銷售指數(shù)級增長别洪，能快速嘗試新的商業(yè)模式和推出完全不同的產(chǎn)品。Scrum作為一個(gè)敏捷研發(fā)框架肌索，專注于首先交付最高業(yè)務(wù)價(jià)值蕉拢，持續(xù)關(guān)注透明性特碳、檢視和調(diào)整，這些都建立在基于經(jīng)驗(yàn)過程控制的理論之上晕换，它成了一個(gè)自然而然的選擇午乓。然而要導(dǎo)入Scrum或者LeSS都被認(rèn)為極其困難，不僅僅是因?yàn)榻M織層級設(shè)置和對分散在不同地方的各種技術(shù)專家的依賴闸准，還受到巨大營銷渠道的影響益愈，即每年有兩次不可更改的作為大里程碑的重要峰會(huì)。

引入變革

作為一個(gè)偏好大規(guī)模Scrum的經(jīng)驗(yàn)豐富的敏捷和Scrum教練夷家，我被要求建議"研發(fā)部門"應(yīng)該如何改變工作方式以應(yīng)對當(dāng)前的挑戰(zhàn)蒸其。 我的挑戰(zhàn)因此是（1）讓所有人都意識(shí)到為了應(yīng)對挑戰(zhàn)不只是研發(fā)部門而是整個(gè)組織要改變；（2）幫助參與者通過理解為什么來擁有變革背后的想法库快，而不只是跟隨我的想法遵循我的建議而已摸袁。 在一次上層管理者（包含Sys首席數(shù)字官）的會(huì)議中，我展示了從和業(yè)務(wù)和研發(fā)代表的對話中收集到的關(guān)于挑戰(zhàn)的總結(jié)义屏。它包括：

• 業(yè)務(wù)挑戰(zhàn)（摘錄）

  • 單個(gè)特性和產(chǎn)品能力的優(yōu)先級不明確
  • 明確標(biāo)注已完成的工作在后期出現(xiàn)問題

• 技術(shù)挑戰(zhàn)（摘錄）

  • 可用性和基礎(chǔ)設(shè)施問題（性能靠汁，端口關(guān)閉等）妨礙了日常運(yùn)行
  • 整個(gè)部署流程耗時(shí)太長。常常缺少某些部分（模版闽铐，后處理等）
  • "架構(gòu)師"們忙于做構(gòu)建流程蝶怔、合并代碼、以及基礎(chǔ)設(shè)施的建立/配置這樣的手動(dòng)任務(wù)
  • 使用各種分支而不是基于主干的開發(fā)兄墅，導(dǎo)致代碼合并的工作量巨大踢星；并且質(zhì)量很低，有許多缺陷/問題
  • 測試數(shù)據(jù)的的創(chuàng)建是一個(gè)非常耗時(shí)的過程并深受知識(shí)缺口的影響

在準(zhǔn)備這個(gè)會(huì)議的過程中隙咸，我還收集了管理層的整體改革目標(biāo)沐悦。基于與管理團(tuán)隊(duì)成員一對一談話和訪問扎瓶，我總結(jié)了如下幾點(diǎn)：

• 通過清除浪費(fèi)來優(yōu)化系統(tǒng)以更快地向客戶交付價(jià)值
• 給組織賦能以使其更加理解客戶并更快響應(yīng)新的需求所踊，還能從已發(fā)布的不足中學(xué)習(xí)和調(diào)整
• 改進(jìn)交付代碼質(zhì)量并減少缺陷/問題的數(shù)量
• 關(guān)注整體產(chǎn)品，對以客戶為中心的需求優(yōu)先順序可視化
• 增加各團(tuán)隊(duì)正在進(jìn)行的工作的可見性

第二個(gè)目標(biāo)跟LeSS中的整體系統(tǒng)優(yōu)化目標(biāo)是一致的概荷，即學(xué)習(xí)并交付給付費(fèi)客戶最大"價(jià)值"所需的最高適應(yīng)性秕岛。其他目標(biāo)可以通過對LeSS原則的特別關(guān)注而實(shí)現(xiàn)（例如：第一個(gè)可以用排隊(duì)論和精益思想）。所以我非常高興地看到研發(fā)團(tuán)隊(duì)和管理層都喜歡應(yīng)用Scrum误证，把它作為一個(gè)軟件研發(fā)框架并緊貼敏捷價(jià)值觀和敏捷原則继薛。我個(gè)人覺得，為了成功愈捅，我們不僅要激勵(lì)那些有著清晰目標(biāo)的個(gè)人遏考，還需要得到組織高層的支持來移除障礙并賦能變革。這已在LeSS指南三個(gè)導(dǎo)入原則（自上而下&自下而上）中體現(xiàn)蓝谨。

然而灌具，我也注意到這里并沒有對Scrum的理解形成共識(shí)青团，需要一個(gè)工作坊來培訓(xùn)所有人并對組織變革達(dá)成一致。這也體現(xiàn)在LeSS指南：開始中咖楣。

我在管理層會(huì)議中的總結(jié)報(bào)告中提出督笆，在開始變革之前需要一些前提條件：

• 業(yè)務(wù)和研發(fā)需要對工作模式達(dá)成一致，才能幫助達(dá)成上述目標(biāo)
• 我們需要（1）自組織的（2）跨職能的（3）同在一地的（4）長期的 團(tuán)隊(duì) （見LeSS結(jié)構(gòu)規(guī)則）
• 團(tuán)隊(duì)需要Scrum培訓(xùn)诱贿，創(chuàng)建工作約定并對于完成的定義達(dá)成一致
• 建立產(chǎn)品待辦列表娃肿，包含技術(shù)項(xiàng)和業(yè)務(wù)項(xiàng)

管理層一致同意上述幾點(diǎn)，給了一個(gè)月的時(shí)間來準(zhǔn)備過渡到新的工作方式珠十。

開始

下面幾段描述了我們當(dāng)時(shí)對組織變革還認(rèn)知有限的情況下所做的幾個(gè)啟動(dòng)步驟料扰。我會(huì)將它們關(guān)聯(lián)到LeSS的指南和規(guī)則 - 我們遵循了哪些；更重要的是強(qiáng)調(diào)了那些我們本應(yīng)做得不一樣的部分焙蹭。

首先晒杈，我們組織了一個(gè)兩天的工作坊，參與者來自研發(fā)部和業(yè)務(wù)部壳嚎。這個(gè)工作坊由我本人負(fù)責(zé)桐智，并帶了一個(gè)助教，主要是做Scrum培訓(xùn)烟馅。這個(gè)做法與LeSS的導(dǎo)入指南一致：LeSS指南：開始 0，培訓(xùn)每個(gè)人然磷。

在工作坊結(jié)束時(shí)郑趁，參與者理解到Scrum不是一項(xiàng)實(shí)踐或者一個(gè)定義好的方法，而是想be agile而非"do agile"所需要的組織設(shè)計(jì)變革姿搜。這個(gè)工作坊還在研發(fā)和業(yè)務(wù)之間建立了強(qiáng)有力的紐帶寡润。

回顧中得出的關(guān)鍵教訓(xùn)是下一次這樣的工作坊要包含所有的高層管理干系人（而不只是幾個(gè)）。通過讓高級管理人員思考LeSS組織設(shè)計(jì)的含義舅柜，例如團(tuán)隊(duì)結(jié)構(gòu)梭纹、層級結(jié)構(gòu)、所在地策略致份、角色变抽、流程和政策，不僅可以獲得對更改組織結(jié)構(gòu)和政策的支持氮块，還可以從一開始就建立正確的結(jié)構(gòu)绍载，這能省去很多麻煩 -- 正如我們經(jīng)歷的那些。

第二個(gè)關(guān)鍵教訓(xùn)是持續(xù)關(guān)注如何讓參與者探索滔蝉、理解Scrum和LeSS的意圖击儡、想法和組織設(shè)計(jì)變革的含義 ，而不是僅僅關(guān)注教授Scrum或LeSS的知識(shí)蝠引。為了更聚焦在原因上阳谍，在LeSS原則（例如：系統(tǒng)思考蛀柴、精益思想）的支持下，讓參與者從中導(dǎo)出他們自己的工作模式矫夯。這樣做使得他們參與更加深入名扛，因?yàn)槲覀兏訇P(guān)注拷貝"最佳實(shí)踐"或者一個(gè)方法理論，而是理解系統(tǒng)優(yōu)化目標(biāo)茧痒、現(xiàn)有系統(tǒng)動(dòng)態(tài)是如何符合（或不符合）該目標(biāo)的肮韧，以及系統(tǒng)可以通過怎樣的改變來更加符合目標(biāo)。

定義"產(chǎn)品"

就像指南:開始 1. 定義"產(chǎn)品" 中說的旺订，產(chǎn)品的定義是"你做出的最重要的決定之一"弄企，因?yàn)樗鼪Q定了導(dǎo)入的范圍、產(chǎn)品待辦列表的內(nèi)容区拳，以及誰是最合適的產(chǎn)品負(fù)責(zé)人拘领。在我們的案例中，產(chǎn)品的定義受到產(chǎn)品愿景和已有的組織結(jié)構(gòu)的約束樱调。想了解更多關(guān)于約束產(chǎn)品定義的因素约素，可參見LeSS指南：你的產(chǎn)品是什么？

產(chǎn)品的愿景是"創(chuàng)建一個(gè)簡單連貫的數(shù)字體驗(yàn)用于尋找笆凌、嘗試圣猎、購買和消費(fèi)Sys軟件以及其合作伙伴的解決方案"，并"簡化客戶的數(shù)字購買過程和體驗(yàn)乞而，準(zhǔn)確地提供他們想要的東西送悔，在他們想要的時(shí)間和地點(diǎn)"。目標(biāo)是通過這個(gè)由當(dāng)時(shí)的CDO（首席數(shù)字官）帶領(lǐng)的Sys數(shù)字部門負(fù)責(zé)的電子商務(wù)產(chǎn)品來實(shí)現(xiàn)爪模。電子商務(wù)站點(diǎn)用來提供來自Sys不同部門和其他公司的產(chǎn)品欠啤。在理想狀態(tài)下，產(chǎn)品的定義會(huì)隨著時(shí)間擴(kuò)展（見LeSS規(guī)則：產(chǎn)品的定義應(yīng)該依照實(shí)際情況屋灌，盡可能廣泛洁段，并以最終用戶/客戶為中心。隨著時(shí)間的推移共郭，產(chǎn)品的定義可能增加祠丝。 更廣泛的定義是首選）。然而從開始的角度來說落塑，有限的產(chǎn)品范圍給了我們更清晰的產(chǎn)品定義纽疟。

一個(gè)非常棘手的已有約束是Sys的IT部門沒有任何研發(fā)工程師有SAP Hybris Commerce Suite的經(jīng)驗(yàn)。于是他們聘請了一家專長于此的公司憾赁，為他們提供了散布在歐洲各個(gè)地方的工程師污朽。然而，就像我們將看到的那樣龙考，這極大地影響了團(tuán)隊(duì)的建立蟆肆。

建立團(tuán)隊(duì)

第三步矾睦，我們關(guān)注在建立團(tuán)隊(duì)和首次組織變革。

之前提過炎功，最初我們的特定組件團(tuán)隊(duì)（比如SAP CRM后端或SAP Hybris Commerce)與單一職能團(tuán)隊(duì)（比如架構(gòu)團(tuán)隊(duì)或測試團(tuán)隊(duì)）之間是割裂的枚冗。在培訓(xùn)時(shí)期，我們強(qiáng)調(diào)如果想要改進(jìn)我們的能力來交付以客戶為中心的最重要特性的話蛇损，就需要建立跨職能赁温、跨組件、穩(wěn)定并長期存在的特性團(tuán)隊(duì)淤齐。這反映了第二條LeSS組織結(jié)構(gòu)規(guī)則股囊，其背后的原因在LeSS指南：理解特性團(tuán)隊(duì)中作為總結(jié)出現(xiàn)，其細(xì)節(jié)可參考第一部出版的LeSS書籍《Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum》更啄。第二部LeSS書籍中的兩個(gè)實(shí)驗(yàn)也表明了這一點(diǎn)：避免單一職能團(tuán)隊(duì)和避免組件團(tuán)隊(duì)稚疹。

新建的團(tuán)隊(duì)用特性團(tuán)隊(duì)來組織，包含了擁有不同技能的各類專家祭务。最終我們建立了四個(gè)團(tuán)隊(duì)内狗，每個(gè)團(tuán)隊(duì)里包含三到四個(gè)SAP Hybris研發(fā)，一個(gè)SAP后端研發(fā)义锥，一個(gè)UI專家柳沙，兩個(gè)測試專家，以及一個(gè)專長持續(xù)發(fā)布的架構(gòu)師缨该。我們解散了專業(yè)測試組和架構(gòu)組（把他們?nèi)谌胩匦詧F(tuán)隊(duì)）偎行，并建立了社區(qū)，在那里專家們可以定期交流并對齊工作方式贰拿。在"社區(qū)"部分我會(huì)就此詳細(xì)說明。盡管很不幸合同需要我們依然有帶著專家頭銜（比如"解決方案架構(gòu)師"或是"測試專家"）的人熄云，但是我們從一開始就明確團(tuán)隊(duì)成員們"愿意把頭銜放在門外"膨更，學(xué)習(xí)必要的技能并幫助他人以便能夠在每個(gè)Sprint結(jié)束時(shí)創(chuàng)造一個(gè)已集成的產(chǎn)品增量。

開始時(shí)每個(gè)團(tuán)隊(duì)配備一個(gè)專門的Scrum Master缴允，因?yàn)榻^大部分Scrum Master和團(tuán)隊(duì)都沒有LeSS的經(jīng)驗(yàn)荚守。為了以身作則，我在其中一個(gè)團(tuán)隊(duì)里擔(dān)任Scrum Master练般。通過我的培訓(xùn)和輔導(dǎo)矗漾，一個(gè)前項(xiàng)目經(jīng)理逐漸可以滿足Scrum Master的要求并在三個(gè)月后替代了我的位置。

在第一年薄料，一個(gè)Scrum Master只能支持一個(gè)團(tuán)隊(duì)敞贡，后來有些Scrum Master可以同時(shí)支持兩個(gè)團(tuán)隊(duì)。他們的關(guān)注點(diǎn)從幫助團(tuán)隊(duì)改進(jìn)工作方式轉(zhuǎn)移到揭露阻礙團(tuán)隊(duì)提升績效的組織功能障礙上摄职。這反映在LeSS指南：Scrum Master關(guān)注點(diǎn)中誊役。

圖五：Scrum Master關(guān)注點(diǎn)隨時(shí)間變化

系統(tǒng)運(yùn)作

Sys的IT部門曾經(jīng)經(jīng)歷過許多項(xiàng)目的實(shí)施获列，系統(tǒng)在幾個(gè)月到數(shù)年內(nèi)被構(gòu)建，但到某個(gè)時(shí)間點(diǎn)蛔垢，預(yù)算就不再增長而只通過配備離岸團(tuán)隊(duì)對系統(tǒng)持續(xù)運(yùn)作和維護(hù)投資击孩。在過去，這種方式會(huì)在"實(shí)施預(yù)算"快耗盡前引入一個(gè)"交接"階段鹏漆。這里也包含了對離岸團(tuán)隊(duì)的知識(shí)傳遞巩梢。這個(gè)"交接"階段總是十分痛苦，關(guān)注點(diǎn)常常只在為維護(hù)團(tuán)隊(duì)創(chuàng)建"剛剛好"的文檔艺玲，而這樣會(huì)導(dǎo)致系統(tǒng)惡化括蝠，因?yàn)榫S護(hù)團(tuán)隊(duì)對每個(gè)功能最初背后的原因沒有足夠的理解，而提供的資金也只能增加一些小的功能而不足以改進(jìn)整個(gè)系統(tǒng)板驳。

我們在"培訓(xùn)工作坊"期間設(shè)法解決這個(gè)問題又跛，保證有部分"維護(hù)預(yù)算"來將離岸研發(fā)人員一開始就整合到特性團(tuán)隊(duì)中。他們剛開始對SAP Hybris Commerce系統(tǒng)或SAP后端系統(tǒng)一無所知若治，但通過結(jié)對和mob編程慨蓝，他們逐漸能從"僅僅修復(fù)問題"到實(shí)現(xiàn)系統(tǒng)新增功能。這對系統(tǒng)的代碼質(zhì)量產(chǎn)生了巨大的影響端幼，因?yàn)椋x岸）團(tuán)隊(duì)成員特別關(guān)注技術(shù)債和必要的文檔隨系統(tǒng)而增長的事實(shí)礼烈，而他們將是"實(shí)施預(yù)算"耗盡后的持續(xù)負(fù)責(zé)人，所以常常是他們來提醒其他團(tuán)隊(duì)成員關(guān)于系統(tǒng)質(zhì)量的問題婆跑。

開始時(shí)未解決的組織挑戰(zhàn)

在團(tuán)隊(duì)最初建立之后此熬，仍有兩個(gè)挑戰(zhàn)未得到解決：分散的團(tuán)隊(duì)和與業(yè)務(wù)人員的集成。雖然這在前期帶來了更大的問題滑进， 它們在后來還是被解決了犀忱。

第一個(gè)挑戰(zhàn)是我們團(tuán)隊(duì)太分散。之前說過扶关，內(nèi)部研發(fā)部門沒有人懂SAP Hybris阴汇，所以必須依賴外面的公司提供懂SAP Hybris的工程師。而這個(gè)公司的工程師散布在歐洲各個(gè)地方节槐，大部分人在家辦公搀庶。在那時(shí)，讓所有團(tuán)隊(duì)成員搬到一個(gè)地方長時(shí)間工作是不可能的事情铜异，也沒有資金哥倔，所以我們建議先做兩周的啟動(dòng)活動(dòng), 然后每六個(gè)月安排一次現(xiàn)場活動(dòng)史煎。讓所有人在一起辦公的效果太明顯啦番甩，以至于大家很快都意識(shí)到這種差別。而對團(tuán)隊(duì)結(jié)構(gòu)的調(diào)整也極大地改善了團(tuán)隊(duì)的績效秩冈。不到一年后，團(tuán)隊(duì)就又重新組織蜡秽，以使大部分成員在一個(gè)地方工作府阀。

新的組織結(jié)構(gòu)已經(jīng)變成了圖六這樣。

圖六：改變前后的團(tuán)隊(duì)結(jié)構(gòu)

第二大挑戰(zhàn)是與業(yè)務(wù)人員的集成芽突。之前說過试浙，組織里除了真正做市場調(diào)研或伙伴關(guān)系管理的產(chǎn)品經(jīng)理們，還有很多在真正的研發(fā)人員和真正的業(yè)務(wù)人員之間的中間人寞蚌。這些中間人忙于傳統(tǒng)瀑布中定義的任務(wù)田巴，比如識(shí)別下一步做什么、描繪系統(tǒng)藍(lán)圖挟秤，或做終端測試壹哺。同時(shí)，研發(fā)部門已經(jīng)習(xí)慣了與他們自己的（偽）產(chǎn)品負(fù)責(zé)人以Scrum的方式工作艘刚，這個(gè)產(chǎn)品負(fù)責(zé)人實(shí)際上只是一個(gè)中間人項(xiàng)目經(jīng)理管宵。在過去，這個(gè)人作為一個(gè)團(tuán)隊(duì)與業(yè)務(wù)的接口而存在攀甚。在研發(fā)這邊還常常有一個(gè)帶偽中間人"產(chǎn)品負(fù)責(zé)人"身份的業(yè)務(wù)分析師箩朴，負(fù)責(zé)編寫需求和為研發(fā)部門澄清需求，以及一個(gè)帶偽"產(chǎn)品負(fù)責(zé)人"身份的項(xiàng)目經(jīng)理充當(dāng)業(yè)務(wù)人員和研發(fā)之間的唯一橋梁秋度。當(dāng)我們在"培訓(xùn)工作坊"中討論這件事情時(shí)炸庞，大家都清楚這里有管理層的限制和缺乏管理層的支持來從一開始就直接改變組織結(jié)構(gòu)。但是就象在接下來的"唯一的產(chǎn)品負(fù)責(zé)人"章節(jié)所述荚斯，這個(gè)情況導(dǎo)致了非常多的組織功能障礙埠居。大約八個(gè)月之后，我們改變了組織結(jié)構(gòu)事期，只有一個(gè)產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整個(gè)產(chǎn)品滥壕，其他產(chǎn)品經(jīng)理則對其支持。

啟動(dòng)

"培訓(xùn)工作坊"結(jié)束兩周后兽泣，研發(fā)和業(yè)務(wù)的代表們一起組織了一個(gè)大型工作坊捏浊，讓所有團(tuán)隊(duì)成員都來參加這個(gè)最初的啟動(dòng)活動(dòng)。兩周內(nèi)撞叨，所有的團(tuán)隊(duì)成員都有機(jī)會(huì)相互認(rèn)識(shí)，相互討論浊洞、反思并就他們共同希望的工作方式達(dá)成共識(shí)牵敷。

這個(gè)大型工作坊還涵蓋了兩天的Scrum培訓(xùn)（所有人都參加），創(chuàng)建了最初的完成的定義（DoD)法希，建立了團(tuán)隊(duì)和整體工作公約枷餐，最重要的是幫助團(tuán)隊(duì)凝聚在一起。

對于我作為一個(gè)教練和其中一個(gè)團(tuán)隊(duì)的Scrum Master來說苫亦，有一個(gè)很重要的事情是讓團(tuán)隊(duì)盡快從"形成"階段過渡到"規(guī)范"階段和"高效"階段毛肋。當(dāng)然在兩周內(nèi)是不能達(dá)成的怨咪，但是理解了團(tuán)隊(duì)發(fā)展動(dòng)態(tài)，讓我們知道在這兩周內(nèi)我們最主要的關(guān)注點(diǎn)應(yīng)該放在建立一個(gè)共同目標(biāo)和建立團(tuán)隊(duì)成員之間的信任上润匙。因此我們做了非常多的團(tuán)建活動(dòng)诗眨，取得了巨大的成功。

完成的定義

在這兩周"啟動(dòng)"會(huì)議中孕讳，所有人都來到了現(xiàn)場匠楚，來建立一個(gè)適用于所有團(tuán)隊(duì)的初始"完成的定義"，如LeSS指南：創(chuàng)建完成的定義描述的那樣厂财。在這個(gè)工作坊芋簿，我們與所有成員一起探索為了交付產(chǎn)品（潛在可交付產(chǎn)品增量）我們需要做什么，并將所有團(tuán)隊(duì)那時(shí)已能在日常Sprint中做的活動(dòng)和產(chǎn)品發(fā)布所必需的其它活動(dòng)區(qū)分開來璃饱。這也是我們第一次深入討論不同類型的測試和文檔与斤，并設(shè)法讓大家對于工作方式達(dá)成一致的理解荚恶。

圖7: 潛在可交付物和完成的定義最初版

圖7中劃線的條目是大家一致同意放進(jìn)初始"完成的定義"中的條目撩穿。其他都算作"完成之外的工作"，即不在"完成的定義"中但也是交付產(chǎn)品需要滿足的條件裆甩。開始時(shí)這個(gè)"完成之外的工作"非常多冗锁，而我們最終目的是讓所有在"完成之外的工作"中的條目最終都包含在"完成的定義"中。在隨后的"發(fā)布Sprint"章節(jié)我會(huì)解釋我們是怎樣處理這些"完成之外的工作"的嗤栓。隨著時(shí)間的推移冻河，我們通過整體回顧會(huì)議漸漸擴(kuò)展了這個(gè)初始"完成的定義"。

唯一的產(chǎn)品待辦列表

對我們而言茉帅，重點(diǎn)之一是從一開始就有唯一的產(chǎn)品待辦列表叨叙。這也符合LeSS規(guī)則：一個(gè)整體交付的產(chǎn)品只有唯一的產(chǎn)品待辦列表。

業(yè)務(wù)方原有的組織結(jié)構(gòu)和不同產(chǎn)品經(jīng)理的職責(zé)分配給我們的開始帶來了不少挑戰(zhàn)堪澎。不同的產(chǎn)品經(jīng)理負(fù)責(zé)在電子商務(wù)網(wǎng)站上發(fā)布不同的Sys產(chǎn)品擂错，這導(dǎo)致了優(yōu)先級的沖突。在過去樱蛤，每個(gè)團(tuán)隊(duì)有一份他們自稱的"產(chǎn)品待辦列表"钮呀，由一個(gè)橫在真實(shí)的業(yè)務(wù)人員和團(tuán)隊(duì)之間的帶偽"產(chǎn)品負(fù)責(zé)人"身份的項(xiàng)目經(jīng)理來對團(tuán)隊(duì)待辦列表上的條目進(jìn)行排序。這導(dǎo)致了局部優(yōu)化昨凡，因?yàn)槊總€(gè)團(tuán)隊(duì)的"產(chǎn)品負(fù)責(zé)人"只關(guān)注交付產(chǎn)品的某個(gè)部分爽醋，而缺乏整體視野。結(jié)果就是每個(gè)"產(chǎn)品負(fù)責(zé)人"都在爭取交付更多的功能便脊，而期望"其他團(tuán)隊(duì)"來改進(jìn)整個(gè)產(chǎn)品和發(fā)布的流程蚂四。當(dāng)然，這并沒有發(fā)生。

我們的目標(biāo)是讓真正全局重要的（已經(jīng)確認(rèn)包含在里程碑中的）條目包含技術(shù)條目可見遂赠。我們嘗試了用戶故事地圖久妆。想法是在地圖上標(biāo)注所有的重要條目并重新組織它們以使得我們能夠把所有重要條目放在一起來討論和排序。通常情況下跷睦，在產(chǎn)品待辦列表梳理結(jié)束幾天之后筷弦，在Sprint計(jì)劃會(huì)議開始的幾天之前，基本上是每兩周送讲，產(chǎn)品經(jīng)理團(tuán)隊(duì)（包含偽PO們）會(huì)花大約兩個(gè)小時(shí)來展示和討論各個(gè)梳理結(jié)果奸笤，并就要帶到下次Sprint計(jì)劃上的產(chǎn)品范圍達(dá)成一致。這樣做的優(yōu)點(diǎn)是為業(yè)務(wù)方下次里程碑上需要實(shí)現(xiàn)的條目創(chuàng)造了可見性哼鬓，包含了團(tuán)隊(duì)在梳理中對條目所做的估算监右，以及有多大可能在一個(gè)Sprint里能實(shí)現(xiàn)這些條目。這樣做的挑戰(zhàn)在于异希，它引起了許多激烈的討論健盒，因?yàn)槊總€(gè)產(chǎn)品經(jīng)理都有一些"個(gè)人目標(biāo)"要實(shí)現(xiàn)，因此幾乎不可能達(dá)成共識(shí)称簿。這導(dǎo)致了一段時(shí)間之后在誰負(fù)責(zé)排序這個(gè)問題上的改變扣癣。

唯一的產(chǎn)品負(fù)責(zé)人

之前說過，開始的時(shí)候我們在研發(fā)方有一個(gè)帶著偽"產(chǎn)品負(fù)責(zé)人"身份的業(yè)務(wù)分析師憨降，在真正業(yè)務(wù)人員與團(tuán)隊(duì)研發(fā)人員之間有一個(gè)帶著偽"產(chǎn)品負(fù)責(zé)人"身份的項(xiàng)目經(jīng)理父虑，我來講講這件事的背景。在2011年早期開始把（單團(tuán)隊(duì)）Scrum作為研發(fā)框架導(dǎo)入組織的時(shí)候授药，由于不夠理解Scrum和真正的Scrum Master或產(chǎn)品負(fù)責(zé)人是什么樣的士嚎，來自Sys IT部門的項(xiàng)目經(jīng)理們被要求選擇是否想把自己變成所謂的"Scrum Master"和所謂的"產(chǎn)品負(fù)責(zé)人"來滿足新的工作模式，這當(dāng)然沒有真正改變什么（見拉曼組織行為定律 #1和#2）悔叽。一部分前項(xiàng)目經(jīng)理選擇成為"Scrum Master"莱衩，另一部分選擇成為"產(chǎn)品負(fù)責(zé)人"。這給大多數(shù)前項(xiàng)目經(jīng)理形成了巨大的挑戰(zhàn)娇澎。困難的部分并不在于學(xué)習(xí)新的未知技能（比如個(gè)人或團(tuán)隊(duì)輔導(dǎo)）笨蚁，而是與軟件研發(fā)團(tuán)隊(duì)工作時(shí)放棄原先的信仰和行為模式（比如在自組織不發(fā)生的情況下如何做）。這導(dǎo)致事實(shí)上在我們團(tuán)隊(duì)里只有一個(gè)前項(xiàng)目經(jīng)理后來保持作為Scrum Master（并且這個(gè)人向公仆式領(lǐng)導(dǎo)者的轉(zhuǎn)變非程俗快）括细。因?yàn)橹挥蓄^銜變更而組織結(jié)構(gòu)和政策都沒有相應(yīng)變化，并沒有真正的產(chǎn)品負(fù)責(zé)人成為"產(chǎn)品負(fù)責(zé)人"戚啥，而只是重新把項(xiàng)目經(jīng)理標(biāo)記為偽"產(chǎn)品負(fù)責(zé)人"勒极。

這種每個(gè)團(tuán)隊(duì)帶有兩個(gè)偽"產(chǎn)品負(fù)責(zé)人"的非常規(guī)設(shè)置，是基于沒有理解導(dǎo)入Scrum的意圖虑鼎，在開始的時(shí)候感覺還不錯(cuò)，因?yàn)檠邪l(fā)團(tuán)隊(duì)有了"業(yè)務(wù)現(xiàn)在已經(jīng)靠近研發(fā)"的錯(cuò)覺，并產(chǎn)生有了研發(fā)團(tuán)隊(duì)獲得客戶期望的"高效渠道"的假象炫彩。然而這導(dǎo)致了兩個(gè)主要問題：一是讓團(tuán)隊(duì)"產(chǎn)品負(fù)責(zé)人"們負(fù)責(zé)團(tuán)隊(duì)的"產(chǎn)品待辦列表"會(huì)導(dǎo)致局部優(yōu)化匾七，如上所述；二是團(tuán)隊(duì)的"產(chǎn)品負(fù)責(zé)人"們（業(yè)務(wù)分析師）逐漸成為團(tuán)隊(duì)理解需求的中介和瓶頸江兢。讓偽產(chǎn)品負(fù)責(zé)人編寫產(chǎn)品需求說明書昨忆，然后遞交給團(tuán)隊(duì)來"實(shí)現(xiàn)"，這樣的做法產(chǎn)生了大量的浪費(fèi)杉允，比如交接問題邑贴、延遲、過度處理叔磷、在制品和缺陷拢驾。

整個(gè)產(chǎn)品只有唯一的產(chǎn)品待辦列表，并按時(shí)（每個(gè)Sprint）討論改基，我們確保了團(tuán)隊(duì)"產(chǎn)品負(fù)責(zé)人"/項(xiàng)目經(jīng)理們可以改變一些條目的優(yōu)先順序繁疤，但還有其他人可以管理團(tuán)隊(duì)正在研發(fā)的所有條目的優(yōu)先順序。有時(shí)候秕狰，團(tuán)隊(duì)"產(chǎn)品負(fù)責(zé)人"們所定義的優(yōu)先順序并沒什么意義稠腊，因?yàn)閳F(tuán)隊(duì)最終會(huì)工作在其它相對于整體產(chǎn)品更關(guān)鍵的條目上。終于到了某個(gè)時(shí)刻鸣哀，其他項(xiàng)目管理部門的人在優(yōu)先順序上花費(fèi)的時(shí)間越來越少架忌，只有唯一的一個(gè)非常靠近CDO的人來負(fù)責(zé)對所有團(tuán)隊(duì)的所有條目排序我衬。

第二個(gè)問題的處理（團(tuán)隊(duì)產(chǎn)品負(fù)責(zé)人是信息瓶頸）更加困難叹放，主要是因?yàn)楣颈旧淼募s束。事實(shí)上低飒，團(tuán)隊(duì)成員對和客戶澄清需求感到不舒服许昨，或是缺乏這方面的技巧，或是相信由一個(gè)人來做需求澄清同時(shí)其他人專注在研發(fā)上會(huì)更加（局部）"高效"褥赊，亦或是偽產(chǎn)品負(fù)責(zé)人團(tuán)隊(duì)（項(xiàng)目經(jīng)理們和業(yè)務(wù)分析師們）有著不一樣的身份和薪水 -- 所有這些都讓它成為一個(gè)巨大的挑戰(zhàn)糕档。

技術(shù)卓越

技術(shù)卓越是一個(gè)對我們的LeSS導(dǎo)入非常重要的部分。在"引入變革"中說到拌喉，我們成功的標(biāo)志是在多大程度上能減少缺陷的數(shù)量以及我們可以以多快的速度發(fā)布新的功能速那，以此來交付客戶價(jià)值或者至少學(xué)習(xí)并理解客戶和變化方向。引入并持續(xù)改進(jìn)以下敏捷工程實(shí)踐使我們在這兩個(gè)目標(biāo)上都取得了巨大的進(jìn)步尿背。

邁向持續(xù)集成和交付的嬰兒步

從每個(gè)團(tuán)隊(duì)在不同的分支上工作幾周甚至幾個(gè)月才向主干合并代碼端仰，到持續(xù)集成，在我們這個(gè)案例中田藐，經(jīng)歷了漫長的過程荔烧，其中有很多教練課程吱七、對話/會(huì)議和討論。當(dāng)然鹤竭，最初的工作方式毫無疑問帶來了太多的問題踊餐，比如破壞系統(tǒng)、引入已經(jīng)修復(fù)過的缺陷臀稚、在與新功能無關(guān)的系統(tǒng)維護(hù)與穩(wěn)定等事情上耗費(fèi)太多時(shí)間吝岭。見避免...大批量的改動(dòng)。因此在研發(fā)這邊對遠(yuǎn)離大發(fā)布有很高的接受度吧寺。不幸的是窜管，沒有人知道怎樣才能做到。在案例中對我們有所幫助的是聯(lián)系了其他IT部門的人稚机，他們之前在Sys創(chuàng)建了一個(gè)內(nèi)部云系統(tǒng)來自動(dòng)化所有Sys IT系統(tǒng)的部署幕帆，因此對持續(xù)集成和持續(xù)發(fā)布有豐富的經(jīng)驗(yàn)。

每個(gè)團(tuán)隊(duì)都加入了一位構(gòu)建專家抒钱，他主要關(guān)注在兩件事情上：（和他的同行一起）構(gòu)建持續(xù)發(fā)布的流水線蜓肆；教導(dǎo)其他團(tuán)隊(duì)成員如何自動(dòng)化每次系統(tǒng)變更，并讓所有東西都放入版本控制系統(tǒng)（我們用Github)谋币。但是持續(xù)集成不只是讓所有東西都版本控制和自動(dòng)構(gòu)建仗扬，持續(xù)集成是一個(gè)開發(fā)實(shí)踐。見避免...認(rèn)為持續(xù)集成只是一個(gè)工具蕾额。它需要團(tuán)隊(duì)的承諾和紀(jì)律：將小的增量變更頻繁地合并到主線早芭；并一致認(rèn)為修復(fù)導(dǎo)致應(yīng)用程序崩潰的變更是最高優(yōu)先級的任務(wù)。因此作為教練诅蝶，我們關(guān)注在引入并維系這樣的思維方式退个，并不斷尋找改善下面事物的機(jī)會(huì)：

• 減少主線代碼提交時(shí)間間隔
• 增加自動(dòng)化測試套件的全面性
• 減少在服務(wù)器上構(gòu)建所需的時(shí)間
• 減少每個(gè)研發(fā)人員在開發(fā)環(huán)境里執(zhí)行測試所需的時(shí)間

研發(fā)人員已經(jīng)習(xí)慣通過分支來處理組件團(tuán)隊(duì)的復(fù)雜性和串行開發(fā)，他們無法想象與其他缺乏經(jīng)驗(yàn)的同事一起工作在主線上调炬，所以把分支立刻清除被認(rèn)為是不現(xiàn)實(shí)的语盈。我們的做法是挑戰(zhàn)分支的持續(xù)時(shí)間。團(tuán)隊(duì)從此開始只工作在兩類分支上：長期存在的發(fā)布分支和"短暫"存在的特性分支缰泡。在減少特性分支的持續(xù)時(shí)間上我們花了不少功夫刀荒，使之從長過一個(gè)Sprint的周期（如果該特性不包含在產(chǎn)品增量中）減少到幾個(gè)小時(shí)。有兩件事起了極大的作用：一件是持續(xù)討論分支的缺點(diǎn)并展示替代方案比如隱藏新功能或增量做改變棘钞；另一件是讓分支"活著的時(shí)間"透明化缠借。研發(fā)人員引入了一個(gè)代碼審查流程，每當(dāng)有新的小特性增量在特性分支上做了開發(fā)宜猜，為了合并這個(gè)分支到主線并刪除這個(gè)分支泼返，另外一個(gè)研發(fā)人員必須審核分支上的代碼變更和執(zhí)行代碼合并。通常情況下姨拥，研發(fā)人員在開始新特性增量開發(fā)時(shí)要通過主要交流工具（Slack）與其他團(tuán)隊(duì)成員一起討論這一步绅喉，并在變更實(shí)現(xiàn)渠鸽、研發(fā)環(huán)境測試完成后請求代碼審查。盡管從精益研發(fā)的觀念看這是一個(gè)大的缺點(diǎn)霹疫，因?yàn)樗黾恿搜舆t成本并引入工作交接拱绑，然而這種方式至少是沿著改進(jìn)的方向在走，增加了分支持續(xù)時(shí)間的透明性丽蝎，也加強(qiáng)了團(tuán)隊(duì)中互幫互助的氛圍。

在我離開的時(shí)候膀藐，分支的平均持續(xù)時(shí)間已經(jīng)只有一天（有很多分支只有幾個(gè)小時(shí)）屠阻，雖然不是最優(yōu)，但相對于以前的工作方式已經(jīng)是巨大的進(jìn)步了额各。

自動(dòng)化測試

如果沒有自動(dòng)化測試国觉，一次成功的構(gòu)建僅僅表示應(yīng)用可以被編譯和組裝。開發(fā)一個(gè)詳盡的自動(dòng)化測試套件包括單元測試和驗(yàn)收測試對于快速反饋至關(guān)重要虾啦，這也是持續(xù)集成的核心成果麻诀。見嘗試...單元測試，嘗試...驗(yàn)收測試驅(qū)動(dòng)開發(fā)傲醉。

團(tuán)隊(duì)里有一個(gè)對測試即有知識(shí)又有熱情的成員對我們幫助極大蝇闭，因?yàn)樗妹艚蒈浖邪l(fā)中的測試是指測試在實(shí)質(zhì)上的獨(dú)立性而并非與開發(fā)分離。獲得這種測試實(shí)質(zhì)上的獨(dú)立性是在開發(fā)之前就定義好測試硬毕，最好是通過跨職能團(tuán)隊(duì)（產(chǎn)品負(fù)責(zé)人或其代表呻引，以及任何其他了解需求的潛在干系人）在工作坊中來討論和澄清測試需求。見嘗試...需求工作坊吐咳。在"LeSS事件"產(chǎn)品待辦列表梳理中我會(huì)介紹我們的產(chǎn)品需求工作坊的流程逻悠。

開始階段，我們讓懂編碼的測試專家創(chuàng)建自動(dòng)測試套件來將手動(dòng)測試腳本自動(dòng)化韭脊，比如童谒，使用Selenium將UI測試自動(dòng)化。一段時(shí)間后沪羔，大家意識(shí)到這不是一個(gè)好主意饥伊，雖然在每次構(gòu)建之后都有一些反饋，但是反饋太慢而測試極其脆弱任内，需要很多的維護(hù)工作撵渡。見避免...在UI上做測試。測試常常有因?yàn)橛行︰I或功能改變而產(chǎn)生的問題死嗦，團(tuán)隊(duì)成員需要不停地檢查系統(tǒng)新的行為是否符合期望趋距。這還不是最大的問題。這里我們最大的教訓(xùn)是團(tuán)隊(duì)里的一組人負(fù)責(zé)測試自動(dòng)化同時(shí)另一組人負(fù)責(zé)實(shí)現(xiàn)新功能是災(zāi)難的根源 -- 這導(dǎo)致額外的復(fù)雜性越除、交接工作的浪費(fèi)节腐，以及知識(shí)分散外盯。見避免...單獨(dú)的自動(dòng)化測試團(tuán)隊(duì)。我們引入結(jié)對工作來解決單一技能團(tuán)隊(duì)成員間的分離翼雀，使得之前懂測試的成員逐漸擴(kuò)展了他們的編碼知識(shí)饱苟，而懂編碼的成員開始編寫自動(dòng)化測試案例。這不但使我們的測試轉(zhuǎn)向更少的UI測試而更多的API測試狼渊，還提高了代碼覆蓋率箱熬。

另一個(gè)重要因素是為了減少最初的痛點(diǎn) -- 大量的缺陷 -- 除了測試自動(dòng)化外還引入了"停止并立即修復(fù)"的規(guī)則。見嘗試...所有測試通過-停止并立即修復(fù)狈邑。把我們的構(gòu)建流水線和我們的消息傳遞工具（Slack）連接起來城须，這樣每當(dāng)有分支合并到主線，構(gòu)建就會(huì)啟動(dòng)并在構(gòu)建結(jié)束時(shí)米苹，一個(gè)測試通知會(huì)被發(fā)送到"通用"Slack頻道糕伐。如果自動(dòng)化測試套件里有測試失敗，這個(gè)失敗的測試信息會(huì)與觸發(fā)構(gòu)建的分支合并信息一同發(fā)布出去蘸嘶。面對這樣的信息立刻有自愿者行動(dòng)起來修復(fù)問題很快變成了團(tuán)隊(duì)文化的一部分良瞧，大部分時(shí)候會(huì)由感覺是自己的提交導(dǎo)致了測試失敗的那個(gè)人來承擔(dān)解決。

另外一個(gè)團(tuán)隊(duì)采納的的行為是在修復(fù)問題之前為每一個(gè)新發(fā)現(xiàn)的缺陷寫一個(gè)新的驗(yàn)收測試训唱。這樣褥蚯，我們的自動(dòng)化測試套件越來越大，我們對每次產(chǎn)品增量帶來的構(gòu)建都是可發(fā)布的信心也越來越強(qiáng)雪情。一年后我們測試套件中的測試達(dá)到了1000多個(gè)遵岩，發(fā)布前的回歸測試時(shí)間也從幾周減少到了幾個(gè)小時(shí)。

在修復(fù)缺陷或?qū)崿F(xiàn)新功能之前編寫（或更新）驗(yàn)收測試帶來的另一個(gè)積極影響是巡通，我們把Wiki或Jira中經(jīng)常過時(shí)且零散的文檔替換成了活文檔尘执，就象實(shí)例化需求（Specification by Example）中描述的那樣。驗(yàn)收測試變成了可執(zhí)行的需求規(guī)格說明書宴凉，也是永遠(yuǎn)更新的活文檔誊锭，與代碼在同一個(gè)倉庫中保存和更新。

社區(qū)

對LeSS中的重要話題特別有熱情的那些人會(huì)對導(dǎo)入帶來巨大的影響弥锄。Natascha是我們最資深的測試人員丧靡，她是實(shí)例化需求（Specification by Example）的鐵粉，把讓團(tuán)隊(duì)的關(guān)注點(diǎn)從測試執(zhí)行轉(zhuǎn)向測試確認(rèn)和測試設(shè)計(jì)作為她的使命籽暇。最重要的是温治，她拒絕成為所謂的測試主管因?yàn)樗X得成為測試瓶頸并沒有什么意義。因此戒悠，她盡全力地去傳播她的知識(shí)并培養(yǎng)團(tuán)隊(duì)對高效測試的理解熬荆。為了更有效地做到這點(diǎn)，她召開例會(huì)討論測試話題绸狐，參會(huì)的是主要關(guān)注于質(zhì)量保證和探索測試的團(tuán)隊(duì)成員（其他人也歡迎參加）卤恳。這些會(huì)議的成果主要是形成的共識(shí)累盗，比如，怎樣用Gherkin語言創(chuàng)建規(guī)格說明書突琳，或怎樣將規(guī)格說明書聚焦在測什么而不是怎么測若债。這些后來會(huì)被放在Wiki上與其他團(tuán)隊(duì)成員分享。她做的另外一件很棒的事情是向社區(qū)成員分發(fā)測試相關(guān)的書籍拆融。越來越多的人對這個(gè)測試的"新方式"充滿熱情蠢琳，并將這種熱情注入到團(tuán)隊(duì)。這些實(shí)踐也可見LeSS指南：社區(qū)工作镜豹。

除了測試社區(qū)挪凑，我們還有Scrum Master社區(qū)和架構(gòu)社區(qū)。

Scrum Master社區(qū)是讓Scrum Master們對齊和互相學(xué)習(xí)的好機(jī)會(huì)逛艰，也供大家分享和緩解他們在LeSS導(dǎo)入中遇到的挫折。跟其它兩個(gè)社區(qū)一樣搞旭，這里有一個(gè)單獨(dú)的Slack頻道散怖，也是一個(gè)特別小的組，僅有三個(gè)Scrum Master和一個(gè)教練肄渗，后來增加到五個(gè)Scrum Master镇眷。人少讓我們捆綁得更加緊密，本身也成為一個(gè)小團(tuán)隊(duì)翎嫡。在所有團(tuán)隊(duì)站會(huì)之后欠动，我們每天都有短暫的同步，但這不是Scrum of Scrum惑申。我們不討論團(tuán)隊(duì)的進(jìn)度而是討論在站會(huì)中發(fā)現(xiàn)的新障礙具伍，對齊下個(gè)LeSS事件并討論誰來作引導(dǎo)。大部分時(shí)間我們分享各自的觀察并擴(kuò)展我們的學(xué)習(xí)圈驼。我們互相交換Scrum的文章并組織會(huì)議討論它們人芽。特別是在開始時(shí)期，我會(huì)常常與新的Scrum Master們結(jié)對工作绩脆，先由我做會(huì)議引導(dǎo)再與他們討論萤厅，然后讓他們來引導(dǎo)會(huì)議并隨后反思一些觀察到的情況。甚至在Scrum Master們變得經(jīng)驗(yàn)更豐富以后靴迫，我們還堅(jiān)持了結(jié)對教練惕味，與團(tuán)隊(duì)成員做定期教練對話。這是一個(gè)Scrum Master們發(fā)起的實(shí)驗(yàn)玉锌，目的是在團(tuán)隊(duì)成員和Scrum Master之間建立信任關(guān)系名挥，使Scrum Master更加了解團(tuán)隊(duì)中的每個(gè)人，幫助他們應(yīng)對新的工作方式芬沉√赏考慮到團(tuán)隊(duì)的分散性阁猜，這樣每兩個(gè)Sprint一次、每次一小時(shí)的對話無論是對團(tuán)隊(duì)成員還是對Scrum Master來說都非常有價(jià)值蹋艺。

最后成立的是架構(gòu)社區(qū)剃袍。

設(shè)計(jì)/架構(gòu)社區(qū)是LeSS強(qiáng)烈推薦的社區(qū)，所以非常奇怪這個(gè)社區(qū)在半年多以后才成立捎谨∶裥В考慮到組織那時(shí)對架構(gòu)的理解，我能夠預(yù)見到人們開始時(shí)看不到建立這個(gè)社區(qū)的必要性涛救。

作為一個(gè)習(xí)慣了瀑布工作和用離岸/近岸的"便宜"研發(fā)來維護(hù)現(xiàn)有系統(tǒng)的部門來說畏邢，他們的理解是，軟件是可以被資深架構(gòu)師"架構(gòu)"好然后被"普通"程序員按照架構(gòu)實(shí)現(xiàn)的检吆。在我們團(tuán)隊(duì)里發(fā)生的關(guān)鍵意識(shí)轉(zhuǎn)變是理解"敏捷架構(gòu)源于敏捷地架構(gòu)行為 -- 有實(shí)戰(zhàn)經(jīng)驗(yàn)的程序員架構(gòu)師舒萎，卓越的代碼文化，重視結(jié)對編程蹭沛，培育高質(zhì)量的代碼/設(shè)計(jì)臂寝，敏捷建模設(shè)計(jì)工作坊，測試驅(qū)動(dòng)開發(fā)和重構(gòu)摊灭，以及其他代碼實(shí)戰(zhàn)行為"咆贬。見LeSS實(shí)驗(yàn)：嘗試...思考'培養(yǎng)'勝于'架構(gòu)' - 創(chuàng)造一個(gè)活著的、不斷成長的設(shè)計(jì)帚呼。

這是一個(gè)非常漫長的過程掏缎，從與負(fù)責(zé)系統(tǒng)維護(hù)（組織中完全不一樣的部門）的經(jīng)理們開展許多討論開始。通過將資深架構(gòu)師把設(shè)計(jì)交給研發(fā)做實(shí)現(xiàn)（見LeSS實(shí)驗(yàn)：避免...設(shè)計(jì)交接給'碼農(nóng)'）的系統(tǒng)動(dòng)態(tài)可視化煤杀，我們說服他們將近岸研發(fā)人員整合到團(tuán)隊(duì)中來眷蜈。這些人開始時(shí)做缺陷修復(fù)工作，然后就被加入到所有的團(tuán)隊(duì)會(huì)議中怜珍，參與結(jié)對編程課程并隨著代碼審查流程的建立端蛆。他們被鼓勵(lì)負(fù)責(zé)任何類型的實(shí)現(xiàn)，無論是新功能還是已有功能酥泛。從清晰地定義誰負(fù)責(zé)什么到整個(gè)團(tuán)隊(duì)集體負(fù)責(zé)產(chǎn)品的設(shè)計(jì)和質(zhì)量今豆，確實(shí)是一個(gè)巨大的轉(zhuǎn)變。除了按需安排的日常結(jié)對編程和上面提到的代碼審查流程之外柔袁，另一個(gè)幫助每個(gè)研發(fā)更好理解系統(tǒng)架構(gòu)的關(guān)鍵因素是在每個(gè)Sprint計(jì)劃會(huì)議中做試探設(shè)計(jì)工作坊呆躲。我會(huì)在下面"LeSS Sprint 計(jì)劃會(huì)議"章節(jié)詳細(xì)描述我們是怎么做的。

一旦理解到真實(shí)的軟件架構(gòu)會(huì)隨著每次編程而演化捶索，突然間就需要建立一個(gè)不一樣的架構(gòu)完整性方法插掂，來取代以前那種每次實(shí)現(xiàn)之前創(chuàng)建好設(shè)計(jì)文檔的方式。每個(gè)團(tuán)隊(duì)中最資深的研發(fā)人員想要經(jīng)常聚在一起，分享在設(shè)計(jì)工作坊中所做的試探設(shè)計(jì)和使用的架構(gòu)模式（見LeSS實(shí)驗(yàn)：嘗試...架構(gòu)和設(shè)計(jì)模式）辅甥。隨著時(shí)間的推移酝润，一些額外的會(huì)議涌現(xiàn)出來，它們不是LeSS事件但可以看作是架構(gòu)社區(qū)會(huì)議璃弄。一個(gè)"架構(gòu)對齊"會(huì)議在每次產(chǎn)品待辦列表梳理之后的幾天被安排舉行要销，使得資深研發(fā)工程師可以一起探索和討論新需求對大規(guī)模架構(gòu)的影響。這對下個(gè)Sprint的計(jì)劃非常有幫助夏块。還有一個(gè)我們稱之為"解決方案設(shè)計(jì)對齊"的會(huì)議在Sprint計(jì)劃會(huì)議之后的幾天舉行疏咐，主要是用來對齊在Sprint計(jì)劃會(huì)議2中單個(gè)團(tuán)隊(duì)試探設(shè)計(jì)的結(jié)果。我相信如果我們都在同地辦公并在需要時(shí)采用聯(lián)合設(shè)計(jì)工作坊（見Less實(shí)驗(yàn)：嘗試...討論更廣泛的設(shè)計(jì)問題做聯(lián)合設(shè)計(jì)工作坊）脐供，這些會(huì)議是完全不必要的浑塞。然而，因?yàn)殡x散的團(tuán)隊(duì)（甚至是多個(gè)離散團(tuán)隊(duì)）讓開展有效的會(huì)議變得困難政己，這些作為額外的會(huì)議也可以說是非常有價(jià)值的酌壕。

LeSS中的社區(qū)并不只是作為學(xué)習(xí)和知識(shí)傳播的支持系統(tǒng)而存在，它們也提供了一個(gè)理想的組織決策環(huán)境歇由。在這里管理者們并沒有妨礙決策的敏捷性（成為瓶頸）仅孩，決定是由領(lǐng)域?qū)＜遥o論他們來自于哪個(gè)團(tuán)隊(duì)）做出的。LeSS建議社區(qū)在他們?nèi)绾喂ぷ骱妥鰶Q定方面達(dá)成共識(shí)（見LeSS指南：社區(qū)）印蓖。在我們這三個(gè)社區(qū)里，我也非常驚訝地看到他們在沒有正式的決策協(xié)議的情況下做得如此成功京腥。我相信赦肃，這與以下事實(shí)有關(guān)，即團(tuán)隊(duì)成員通過早期參加社區(qū)活動(dòng)建立了非常深層次的相互信任和尊重公浪。在這樣的環(huán)境中他宛，社區(qū)基于每個(gè)人同意來做決定就變得容易。（同意意味著沒有人會(huì)反對這個(gè)想法欠气，而共識(shí)是指每個(gè)人都支持同樣的想法厅各。即使在這樣的環(huán)境中，那也不太可能發(fā)生）预柒。

LeSS 事件

圖8: LeSS 框架

我們的LeSS Sprint 儀式

我們從一開始就建立了所有的LeSS事件队塘，但是如你所見，因?yàn)槲覀兊膱F(tuán)隊(duì)是分散的宜鸯，這使我們在實(shí)現(xiàn)這些事件本應(yīng)具備的關(guān)鍵透明性和檢視上變得極其困難憔古。

我們所有團(tuán)隊(duì)都從兩周的Sprint開始：所有團(tuán)隊(duì)同時(shí)開始和結(jié)束一個(gè)Sprint（見LeSS規(guī)則：同產(chǎn)品級的Sprint）。

LeSS Sprint計(jì)劃會(huì)議

跟其他LeSS事件一樣淋袖，Sprint計(jì)劃會(huì)議因?yàn)橛羞h(yuǎn)程參與者而非常具有挑戰(zhàn)性鸿市。開始，所有的團(tuán)隊(duì)成員都參與Sprint計(jì)劃會(huì)議1，時(shí)間不超過30分鐘焰情。然而陌凳，隨著團(tuán)隊(duì)數(shù)量的增加，后來只派團(tuán)隊(duì)代表參加内舟。見LeSS指南：Sprint計(jì)劃會(huì)議1合敦。我之前在"唯一的產(chǎn)品待辦列表"章節(jié)說過，在Sprint計(jì)劃會(huì)議之前我們一直有一個(gè)"業(yè)務(wù)對齊"會(huì)議谒获。在那里蛤肌，業(yè)務(wù)代表、"業(yè)務(wù)PO們"和其他干系人一起討論和對齊產(chǎn)品待辦列表梳理的結(jié)果批狱。最后裸准，（后來的）產(chǎn)品負(fù)責(zé)人決定所有條目的優(yōu)先順序并在Sprint計(jì)劃會(huì)議1中由他或其代表向大家展示這個(gè)列表。通常情況下赔硫，這進(jìn)行得非常迅速炒俱，因?yàn)閳F(tuán)隊(duì)會(huì)自愿拿走他們梳理過的條目；但在有些情況下爪膊，當(dāng)那些條目并不在前列权悟，如果其他團(tuán)隊(duì)沒有產(chǎn)能，團(tuán)隊(duì)也會(huì)挑一些不熟悉的條目推盛。這時(shí)峦阁，團(tuán)隊(duì)代表會(huì)尋求在Sprint計(jì)劃會(huì)議2中以及接下來的整個(gè)Sprint中跨組合作的機(jī)會(huì)。他們會(huì)召開一個(gè)多團(tuán)隊(duì)的Sprint計(jì)劃會(huì)議2耘成，這樣所有相關(guān)團(tuán)隊(duì)就可以有共享的設(shè)計(jì)會(huì)議并協(xié)調(diào)共享的工作榔昔。

因?yàn)橛蟹稚⒌膱F(tuán)隊(duì)，Sprint計(jì)劃會(huì)議2不得不通過電話會(huì)議來完成瘪菌，使其更加困難撒会。在團(tuán)隊(duì)重組之后，這個(gè)情況得到了極大的改善：大部分成員坐在一個(gè)房間师妙，在一塊白板面前诵肛，僅僅少數(shù)幾個(gè)成員遠(yuǎn)程加入。這些團(tuán)隊(duì)在不同的時(shí)期嘗試了許多不同方式默穴，比如怎樣改進(jìn)Sprint計(jì)劃會(huì)議2怔檩。最終，我觀察到每個(gè)團(tuán)隊(duì)都有自己喜歡的方式來進(jìn)行這個(gè)會(huì)議蓄诽。有些團(tuán)隊(duì)喜歡把自己分成2到3人的小組珠洗，讓這些小組來把每個(gè)PBI拆分成任務(wù)；然后他們再聚一起展示所有的任務(wù)若专，讓整個(gè)團(tuán)隊(duì)來重新估算并評估所有的條目加在一起是否能放在一個(gè)Sprint中完成许蓖。另外一些團(tuán)隊(duì)傾向于把每個(gè)PBI逐個(gè)查看并確認(rèn)需要完成這些PBI的所有的任務(wù)，也用小時(shí)數(shù)作估算，用這樣的方式直到他們都"滿了"膊爪。雖然每個(gè)團(tuán)隊(duì)開會(huì)的方式不一樣 -- 這也是LeSS鼓勵(lì)的做法 自阱，因?yàn)閳F(tuán)隊(duì)?wèi)?yīng)該擁有自己的流程而不是租用別人的流程 -- 所有團(tuán)隊(duì)都關(guān)注在對約定的Sprint待辦列表達(dá)成共識(shí)上。無論使用哪種方式米酬，作為Scrum Master和教練的我們都意識(shí)到沛豌，團(tuán)隊(duì)對他們的"預(yù)測"充滿信心并為某些不可預(yù)見的工作保留一些緩沖是多么重要。我們注意到當(dāng)團(tuán)隊(duì)挑選比最初預(yù)測的更少的工作時(shí)有一種強(qiáng)大的積極影響赃额，導(dǎo)致團(tuán)隊(duì)士氣和績效的提升加派。

產(chǎn)品待辦列表梳理（PBR）

我確信在整個(gè)導(dǎo)入過程中，產(chǎn)品待辦列表梳理是LeSS事件里改變最多的跳芳。一開始芍锦，我們（錯(cuò)誤地）計(jì)劃了每兩周一次2小時(shí)的會(huì)議机打，只有團(tuán)隊(duì)成員和"業(yè)務(wù)PO"參加呛哟。業(yè)務(wù)分析師（也稱為IT"產(chǎn)品負(fù)責(zé)人"）與"業(yè)務(wù)PO"一起提前準(zhǔn)備所有的產(chǎn)品待辦列表?xiàng)l目屋确。所有的條目在PBR中展示货岭，團(tuán)隊(duì)主要關(guān)注在問需要澄清的問題和估算條目的大小上。

所有團(tuán)隊(duì)都有在每個(gè)Sprint后剩余一些未完成條目的情況魄幕，這在團(tuán)隊(duì)回顧會(huì)議上經(jīng)常被討論陕贮，其中一個(gè)根因是跟使用的梳理方式有關(guān)匣屡。我們根據(jù)咨詢教練的建議為PBI引入了一個(gè)固定結(jié)構(gòu)：一個(gè)用戶故事和史詩（Epic）模板包含了業(yè)務(wù)價(jià)值城看、用戶成功場景女气、假設(shè)、驗(yàn)收測試和開放問題测柠。就緒的定義（Definition of Ready / DoR）也被引入來保證未就緒的條目不會(huì)在Sprint計(jì)劃會(huì)中展示主卫。除此之外，業(yè)務(wù)分析師同意采用遵循Gherkin語法（Given...When...Then）的例子來寫下驗(yàn)收測試鹃愤。仍然，這并沒有為當(dāng)前的情形帶來多大的改善完域。許多PBI或用戶故事在Sprint結(jié)束時(shí)并沒有完成软吐，是因?yàn)橐婚_始他們都沒有被完全理解。我們還有很多"回旋鏢"（一類在發(fā)布之后兩個(gè)月內(nèi)又回爐重做的PBI）吟税。隨著時(shí)間的推移凹耙，人們開始意識(shí)到，無論在一開始采用了多么好的模板肠仪，最能幫助獲得真正理解的是在把事情寫下來過程中的討論和反思肖抱。不止這個(gè)，我們還注意到异旧，我們作為一個(gè)團(tuán)隊(duì)可以設(shè)計(jì)出比業(yè)務(wù)分析師和業(yè)務(wù)人員獨(dú)自在一邊做出的更好的解決方案意述；一個(gè)讓每個(gè)人都能理解真正問題并合作解決的機(jī)會(huì)。鑒于此，在產(chǎn)品待辦列表梳理上荤崇，我們慢慢地從討論技術(shù)性能規(guī)格說明和估算工作拌屏，過渡到討論業(yè)務(wù)嘗試達(dá)到的目標(biāo)或解決的問題，一起定義在一個(gè)Sprint里能夠?qū)崿F(xiàn)的目標(biāo)范圍或是幫助我們邁向目標(biāo)的范圍并決定潛在的解決方案术荤。業(yè)務(wù)分析師仍然負(fù)責(zé)整個(gè)PBR的運(yùn)行倚喂，但后來，我們給團(tuán)隊(duì)成員更多的機(jī)會(huì)來合作定義范圍和設(shè)計(jì)解決方案瓣戚，而不只是對提前確定的關(guān)鍵實(shí)例提出問題端圈。一種有效的方式是在業(yè)務(wù)分析師展示完一個(gè)清晰的實(shí)例（"快樂路徑"）之后分組討論，讓團(tuán)隊(duì)成員們分組尋找邊界并嘗試提出更多的其他實(shí)例子库。理想情況下舱权，每組都在同一個(gè)地點(diǎn)，但有些時(shí)候我們通過視頻電話會(huì)議一起用在線工具（比如wiki網(wǎng)頁）解決刚照。之后刑巧，我們會(huì)評審這些不同的實(shí)例，并約定隨后會(huì)被一起自動(dòng)化的關(guān)鍵實(shí)例无畔。

通過這種轉(zhuǎn)換和不同的方法啊楚，我們也認(rèn)識(shí)到業(yè)務(wù)分析師和"業(yè)務(wù)PO"并不能對所有討論出來的問題都有答案，所以我們開始邀請業(yè)務(wù)方面的專家參與進(jìn)來浑彰。

重要的是要記得整個(gè)帶有這些偽"PO"們的模式都是錯(cuò)誤的恭理，它既是強(qiáng)加于我們的，也是反映了我們對Scrum和LeSS的許多誤解郭变。

LeSS Sprint 評審

遵照LeSS的建議颜价，我們建立了一個(gè)所有團(tuán)隊(duì)參加的產(chǎn)品Sprint評審。由于組織中分散團(tuán)隊(duì)和多地點(diǎn)的約束诉濒，我們只能通過視頻會(huì)議來進(jìn)行這個(gè)事件周伦，以便來自不同地方的所有團(tuán)隊(duì)成員和業(yè)務(wù)代表們都可以參加。作為教練和Scrum Master未荒，我們很高興為所有團(tuán)隊(duì)提供了一個(gè)共同的Sprint評審专挪，以至于所有參與者都能聚焦于整個(gè)產(chǎn)品。通過持續(xù)集成實(shí)踐片排，團(tuán)隊(duì)在Sprint中就讓他們的干系人評審已完成的條目以盡快得到反饋寨腔。因此大部分PBI都在Sprint中已經(jīng)被產(chǎn)品負(fù)責(zé)人和業(yè)務(wù)代表們評審過了。在Sprint評審中率寡，我們更關(guān)注于產(chǎn)品全貌迫卢，討論我們實(shí)現(xiàn)了哪些又錯(cuò)過了哪些。不幸的是冶共，由于上面提到的組織約束乾蛤，我們的Sprint評審缺乏動(dòng)手檢視的特征每界。

在LeSS中，如同在Scrum中幻捏，Sprint評審是關(guān)于動(dòng)手檢視產(chǎn)品盆犁，并在團(tuán)隊(duì)、產(chǎn)品負(fù)責(zé)人和干系人之間進(jìn)行深度會(huì)談篡九，以共同了解產(chǎn)品谐岁、利潤驅(qū)動(dòng)因素、戰(zhàn)略客戶榛臼、業(yè)務(wù)風(fēng)險(xiǎn)伊佃、新的問題和機(jī)會(huì)，等等沛善。在我離開時(shí)的一個(gè)改進(jìn)重點(diǎn)是找到方法允許干系人航揉、產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)成員們在多站點(diǎn)環(huán)境中對工作的軟件進(jìn)行交互并檢視新產(chǎn)品，比如用多站點(diǎn)評審集市的形式并允許對檢視中的發(fā)現(xiàn)和下個(gè)Sprint的方向進(jìn)行討論金刁。

LeSS 回顧

另一個(gè)有影響力的改進(jìn)機(jī)會(huì)是使用整體回顧帅涂，就象在第三本LeSS出版書中描述的那樣：見LeSS指南：改進(jìn)系統(tǒng)。很長一段時(shí)間里尤蛮，我們在每個(gè)Sprint結(jié)束就只有一個(gè)團(tuán)隊(duì)回顧媳友，因?yàn)闆]人認(rèn)為額外的會(huì)議有任何價(jià)值。但是隨后人們認(rèn)識(shí)到只有讓每個(gè)團(tuán)隊(duì)的每個(gè)人都參與产捞，才能解決系統(tǒng)性問題醇锚。改進(jìn)代碼質(zhì)量或更多業(yè)務(wù)方參與這樣的事情，如果所有工作在上面的團(tuán)隊(duì)都共同努力坯临，影響會(huì)完全不一樣焊唬。起先，Scrum Master在團(tuán)隊(duì)回顧之后有一個(gè)同步會(huì)議來對齊不同團(tuán)隊(duì)承諾的改進(jìn)措施看靠，但后來他們認(rèn)識(shí)到他們不一定能說服他們的團(tuán)隊(duì)成員來執(zhí)行這些其他團(tuán)隊(duì)決定的措施赶促，為此他們掙扎了很久。最后挟炬，我們引入了"整體回顧"鸥滨，來自所有團(tuán)隊(duì)的成員都會(huì)參加，有時(shí)候（不幸的是這并不是一直）管理者也會(huì)加入辟宗。很多重要的改進(jìn)在"整體回顧"上被討論和解決，比如在產(chǎn)品待辦列表梳理中引入實(shí)例化需求的改進(jìn)吝秕。缺乏架構(gòu)完整性的問題也在整體回顧中被解決泊脐，設(shè)計(jì)/架構(gòu)社區(qū)從"解決方案設(shè)計(jì)對齊"和"架構(gòu)對齊"中被創(chuàng)建出來，以支持得到聯(lián)合的設(shè)計(jì)對齊烁峭。為了解決系統(tǒng)級的問題容客，就需要和管理層一起審視整個(gè)系統(tǒng)秕铛，討論系統(tǒng)動(dòng)態(tài)和心智模式，這個(gè)步驟我們已經(jīng)開始缩挑，但在整體回顧中仍然沒有成為標(biāo)準(zhǔn)但两。

發(fā)布Sprint

因?yàn)槲覀儧]有單獨(dú)的"完成之外的部門"，所有不在完成的定義（DoD）之內(nèi)的工作需要在發(fā)布之前被研發(fā)團(tuán)隊(duì)做掉供置。開始時(shí)谨湘，我們每兩個(gè)月一次發(fā)布，所以每四個(gè)Sprint就有一個(gè)發(fā)布Sprint芥丧，這個(gè)Sprint里幾乎所有的工作都是與完成之外的工作相關(guān)紧阔。這也符合LeSS實(shí)驗(yàn)：嘗試...在Scrum團(tuán)隊(duì)中包含一個(gè)發(fā)布Sprint。當(dāng)然我們的目標(biāo)是減少完成之外的工作并改進(jìn)DoD续担，以至于不再需要一個(gè)發(fā)布Sprint擅耽。在我離開時(shí)，完成之外的工作已經(jīng)減少到只需一個(gè)團(tuán)隊(duì)在發(fā)布Sprint中去做物遇，每次發(fā)布都由一個(gè)新的團(tuán)隊(duì)來負(fù)責(zé)乖仇，而其他團(tuán)隊(duì)大部分都工作在移除技術(shù)債上面。

結(jié)論

這個(gè)故事展示了應(yīng)用LeSS原則询兴、規(guī)則乃沙、指南和實(shí)驗(yàn)來在Sys IT部門改進(jìn)和形成一個(gè)更有適應(yīng)性的組織，使Sys商店得以成功實(shí)現(xiàn)蕉朵，即使有一些組織約束阻止了我們用推薦的方式導(dǎo)入LeSS崔涂。就如同開篇里提到的，這并非關(guān)于怎樣正確導(dǎo)入LeSS始衅。通過（1）當(dāng)許多團(tuán)隊(duì)創(chuàng)建一個(gè)產(chǎn)品時(shí)引入LeSS規(guī)則來去除反適應(yīng)的元素和（2）通過移除組織結(jié)構(gòu)和政策逐漸改變組織冷蚂，我們在適應(yīng)性方面取得了重大改進(jìn)。持續(xù)對系統(tǒng)動(dòng)態(tài)的反思和管理者支持為能持續(xù)改進(jìn)做必要的組織改變汛闸，支持和指導(dǎo)了我們通往低切換成本適應(yīng)的系統(tǒng)優(yōu)化目標(biāo)蝙茶。

應(yīng)用LeSS框架規(guī)則，比如實(shí)現(xiàn)唯一的產(chǎn)品待辦列表诸老、唯一的產(chǎn)品負(fù)責(zé)人和全體團(tuán)隊(duì)共享Sprint計(jì)劃會(huì)議隆夯，有助于保持對產(chǎn)品整體的關(guān)注，并在支持自組織和內(nèi)在激勵(lì)的同時(shí)對團(tuán)隊(duì)正在進(jìn)行的工作提供了可見性别伏。有五個(gè)分散團(tuán)隊(duì)蹄衷、許多干系人在不同的地方，這種情況的共同評審非常具有挑戰(zhàn)性厘肮。即使缺乏真正的Sprint評審應(yīng)有的深度會(huì)談和對齊愧口，這仍然有助于聚焦在產(chǎn)品整體上。整體回顧使得我們解決更大的組織變革問題类茂，這在團(tuán)隊(duì)層面不會(huì)得到多少關(guān)注耍属。除LeSS事件以外托嚣，許多LeSS推薦的指南和實(shí)驗(yàn)的采用對軟件開發(fā)工作也產(chǎn)生了巨大的積極影響。

在我看來厚骗，建立比如"停止并立刻修復(fù)"之類的規(guī)則示启，并成為我們的文化，對我們能夠在短時(shí)間內(nèi)交付缺陷更少更好的產(chǎn)品有極好的影響领舰。我確信夫嗓，這是基于建立了技術(shù)卓越（就像測試自動(dòng)化、持續(xù)集成等等）提揍，否則啤月，是不可能以簡單、快速劳跃、靈活的方式改變產(chǎn)品并快速獲得反饋的谎仲。沒有這些，"停止并立刻修復(fù)"是不可能的刨仑。

在我就職期間郑诺，有三個(gè)關(guān)鍵的組織方面使文化發(fā)生了轉(zhuǎn)變：移除組織壁壘和層級，去除團(tuán)隊(duì)內(nèi)部角色（所有團(tuán)隊(duì)成員在一起工作杉武，每個(gè)Sprint結(jié)束時(shí)創(chuàng)造一個(gè)已集成的產(chǎn)品增量）和拋棄了所有為"特殊人群"召開的特別會(huì)議辙诞，讓每個(gè)人更緊密也更貼近每個(gè)迭代交付高質(zhì)量產(chǎn)品的目標(biāo)。移除政策和會(huì)議轻抱，聚焦在整體產(chǎn)品和整個(gè)系統(tǒng)是讓我們能夠改變文化的主要因素飞涂。見LeSS指南：文化跟隨著組織結(jié)構(gòu)。我覺得另外兩個(gè)有利因素是社區(qū)和教練（對話）祈搜。

回想起來我最大的收獲是關(guān)于導(dǎo)入LeSS的方式较店。我們逐步導(dǎo)入LeSS組織架構(gòu)的方式是由于受到我們組織約束的限制而被迫為之，很幸運(yùn)我們能夠?qū)崿F(xiàn)上面所述的改進(jìn)容燕，并沒有制造出更多的問題梁呈。在大多數(shù)情況下，以錯(cuò)誤的組織結(jié)構(gòu)開始增強(qiáng)了案例中提到的拉曼組織行為法則描述的動(dòng)態(tài)蘸秘。通過（1）一開始就教育每個(gè)人了解背后原因官卡，（2）如預(yù)期從一開始就將組織設(shè)計(jì)落實(shí)到位，和（3）得到那些深入理解LeSS的組織含義醋虏、不遵循拉曼組織行為法則的高層管理團(tuán)隊(duì)的大力配合寻咒、達(dá)成共識(shí)并獲得支持，我們本可以更快取得更多進(jìn)展颈嚼，讓每個(gè)參與其中的人更容易些毛秘。

致謝

我想要表達(dá)我對Mark Bregenzer最誠摯的感謝。他是德國第一位LeSS培訓(xùn)師粘舟，從我見到他第一天起他就是我的導(dǎo)師熔脂，他不僅幫我構(gòu)造和設(shè)計(jì)了這個(gè)案例，還在我作為大規(guī)模Scrum實(shí)踐者柑肴、教練和培訓(xùn)師的成長路上產(chǎn)生巨大的影響霞揉。我還要感謝Craig和Bas在我寫這個(gè)案例過程中給我的有價(jià)值的反饋和支持。最后一點(diǎn)也很重要晰骑，感謝在這個(gè)轉(zhuǎn)型的旅程中參與和陪伴我的每個(gè)人适秩，特別是我夫人，Oksana硕舆。如果沒有你們所有人秽荞，我什么也寫不了。