德國大保險公司（化名）的巨型LeSS轉型嘗試（下）

德國大保險公司（化名）的巨型LeSS轉型嘗試（上）

PBR結果分享會議的問題

初始PBR工作坊結束后，墻上可視化了排序的條目（便利貼）列表。在分享會中APO解釋了列表，目的是讓產品負責人團隊、PM＆BA＆CO團隊，測試經理，測試工具負責人，開發經理、發布經理及首席架構師獲得共同理解38。

目標是獲得以下方面的透明度：

哪些具有較高確定性的條目可以交付

哪些條目可能會產生

哪些條目明確不在范圍內

請注意，在LeSS中通常不存在這樣的“分享”事件，因為在初始PBR之后與之共享信息的人員應該已經積極地參與了初始PBR。必須進行單獨共享的事實表明，沒有進行有效的自上而下的變更去消除傳統的團隊和角色。

另一方面，LeSSHuge描述了產品負責人團隊（POT）在Sprint計劃之前進行同步的可能性，我認為這種同步在這里發生了很多，因此這很有用，但也包含了傳統團隊的無用的活動。

這次共享會議確實在POT內部，部門內部以及PM＆BA＆CO之間建立了信任和信心。此外，還播種了以定期進行重新規劃和重新排序的種子。進步！

新組織結構的問題

拉曼組織行為定律

組織會含蓄的優化會以避免改變中層經理、一線經理及“專家”的職位和權力結構的現狀。

作為（1）的推論，任何變更倡議都將簡化為重新定義新術語，以與現狀保持基本相同。

作為（1）的推論，任何變革倡議都會被嘲笑為“純粹的”，“理論的”，“革命的”，“宗教的”和“需要針對當地情況的務實的個性化”，這偏離了解決弱點和經理、專家的地位的現狀。

作為（1）的推論，如果在變更之后某些經理和專家仍然被取代，他們將成為變革的“教練或培訓者”，并常常加強了（2）和（3）。

在這種情況下，所有這些定律都必須遵守。以下段落更深入的描述了組織結構及各個小組和職能的功能失調。

PM＆BA＆CO確實是Alpha公司的一個單獨部門，這一事實使他們很難參與到LeSS實施中。在自上而下和自下而上的支持的變革中，兩個部門PM＆BA＆CO和Terra將合并為一個部門。

因此，這種功能失調設置的存在，造成了尤其是在早期對于如何完成事情理解的不一致性，例如：

他們不斷提供較大的需求定義。

發布內容的預期承諾（請參閱合同游戲）

通過指導，教育和舉辦共同的工作坊，隨著時間的推移合作得到改善。但是由于缺少高層管理人員的支持，從長遠來看，其他做法（例如預算，激勵機制，目標設定）可能會比這些改進更有價值。

LeSS的基本規則是只有一個產品負責人。考慮了幾個選項來回答這個問題，誰將承擔這位產品負責人的職責。很明顯，她不能來自現有的PM＆BA＆CO39部門，因為他們僅涉及B2B2C產品，而完全不涉及B2B產品。

開始巨型LeSS實施時，很明顯項目經理既是真正的產品負責人40，同時又是“開發負責人”，即領導整個組織（一個人擔任兩個不同的角色）。

產品負責人團隊（POT）由PO和三個APO組成。

POT經常開會，以重新規劃PB的短期和長期優先級。很難掌握產品負責人的職責，因此產品負責人團隊建立15分鐘的每日站會時間，以便能夠根據需要與PO同步日常問題。

后來，POT意識到需要定期重新確定PB的優先級。這是與PM＆BA＆CO的代表一起完成的。參與者花了好幾輪的時間才能夠集中討論短期（1-2個Sprint）和中期條目（接下來的2-3個月）。

對話沒有繼續進行合同游戲，而是逐漸朝著更具協作性的方向發展，并專注于信息交換和尋找方法，以使下一次發布盡可能有價值。

LeSS的規則還定義了每個團隊都是自組織，跨職能，在同一地點且長期存在的。

在命令和控制環境中工作了多年之后，特性團隊開始學習自組織。開發人員迅速重新調整自己，以便特性團隊的所有成員坐在一起。“合同承?！盧A有5個團隊，其中4個與APO在同一地點，而另一個團隊在印度。

在自設計團隊工作坊之后，所有特性團隊都是跨職能和跨組件的，能夠完成以客戶為中心的特性，即結果而不是輸出。

從某種意義上說團隊是穩定的，因為團隊成員沒有被抽調到其他小組中。由于大多數團隊成員來自合作伙伴，因此每1.5至3年會進行一次成員交換。

許多團隊成員（和經理）是合作伙伴（或分包商），有時甚至是競爭對手。這個事實大大限制了團隊的自組織能力。

成員經常在這里進行改變的事實是另一個功能失調，這阻止了組織和團隊的整體學習。個人確實學習了，然后就帶著所有的知識去了另一家公司。

尤其是Scrum Master都沒有大規模Scrum和LeSS的經驗。所有人都對如何支持1-2個團隊的Scrum轉型有很好的想法，但沒有足夠的知識和理解來支持更大規模的實施。他們在指導PO、管理層和組織方面，或者換句話說，“為人們創造成功的環境”方面，都沒有Scrum Master角色的豐富經驗。41

不幸的是，關于Scrum Master的LeSS規則僅得到了部分實現。

最大的差距是缺乏對LeSS的知識，以及他們無法專注于組織、開發實踐和整個組織的系統。隨著LeSS Huge的實施，所有Scrum Master都致力于擔任這一角色，并在一個RA中為1-2個團隊提供服務。

在我輔導的時間里，Scrum Master 開始學習LeSS規則、原理、指南和實驗。特別是，他們學會了支持LeSS事件，APO和整個組織作為一個復雜的系統。Scrum Master尚未將重點放在開發實踐上。

Scrum Masters在所有RA中形成了一個社區，這對他們的技能，思維方式以及他們可以互相支持的地方有很大幫助42。此外，他們還學會了引導大型團體活動43。

一名Scrum Masters具有SAFe背景，他拒絕了我們計劃的所有結構的改變。項目經理已經清楚了這種情況需要解決。因此，這個Scrum Master的合同（他和其他人一樣都是外包人員）提前終止了。

通常未完成的部門是功能失調的。首先應避免使用未完成部門，隨著時間的流逝且團隊越來越多地完成“未完成的工作”，這肯定會消除它們。

在Terra部門中，“未完成的部門”包括：

系統測試和驗收測試

測試工具

新功能的系統測試由團隊完成，但是系統級的回歸測試主要由印度44的“測試工廠”進行，而測試工廠是由測試經理“監督”的。大多數測試是手動執行的。

這種功能失調會導致較長的反饋周期、交接、用工具進行溝通、我們與他們、學習不足、責任從行動中分離出來，以及對產品增量準備交付的方式的不清楚。

此外，“測試工廠”來自戰略合作伙伴，該合作伙伴與另一合作伙伴互換，后者承諾在自動化回歸測試中也將提供更快的速度。這個改變延遲了大多數所需實驗的開始。簡而言之，這是非常麻煩與混亂的，對于LeSS實施而言這并不是最佳選擇，但這是朝著可能改善情況的第一步。

總的來說，目標是從長遠來看使回歸測試和系統測試自動化，并完全消除該功能或至少顯著降低其功能。但是，我認為這個目標實際上與合作伙伴的目標和利益相抵觸，因為通過提供手動進行測試的“主體”可以使合作伙伴獲得很好的收益。從整體上看這是另一個功能失調，從而被管理層忽略了。

測試工具團隊負責構建和開發驗收測試框架的一部分，維護服務器并運行測試框架，在計劃發布產品時執行驗收測試。測試工具團隊與特性團隊一起參加沖刺事件。

這種功能失調的設置禁止（或至少阻礙了）團隊學習有關驗收測試驅動開發和所需工具的知識。此外，這種情況造成了交接、更長的反饋周期、依賴性以及協調的需要。

該團隊的存在是由于歷史原因，即測試工具始終由X部門來完成。此外，該工具的體系結構是X部門的主管建立的，據我所知，沒有足夠的文檔證明團隊可以自行繼續開發工具。管理層允許這種情況，我認為延遲開發的風險被認為是這種設置的影響。據我所知，這個小組沒有任何消除它的計劃。

隨著巨型LeSS的實施，本地45CuDo團隊被解散并整合到團隊中。

支持功能包括：生產管理，發布管理，架構師和資源經理。

通常，支持功能是LeSS實施中的功能失調。首先應該避免，并且隨著時間的流逝一定會消除支持功能，因為這些浪費的工作要么被消除，團隊進行有用的工作，而且在團隊中建立這些能力。

通常，這些職能阻礙了團隊進行自組織，進行交接并延遲信息的流動。

生產管理包括兩個團隊：缺陷管理和配置管理。

B2B2C產品具有大量累積的缺陷。原因是Terra部門的結構，印度有“測試工廠”的事實以及測試工廠與開發團隊之間的溝通是通過缺陷工具完成的事實。因此，當印度的測試人員發現系統測試或回歸測試中的缺陷時，他們在系統中開一個ticket，他們將工作視為“完成”。然后，開發團隊來找出解決方法。

Terra部門有自己的團隊來協調來自測試工廠、最終客戶、生產系統和產品其他用戶的缺陷。該團隊提供了一級支持，并為團隊之間的一級支持之外的問題提供了協調。

協調效果不佳，因為這試圖通過像“APO的影子”一樣向特性團隊注入工作。與APO和團隊溝通不暢是一個持續的摩擦點。

當該團隊的一個關鍵人員離開公司時，我們討論了將缺陷管理的職責移交給團隊的可能。但是，這些想法被生產主管否決了，不幸的是這些想法永遠消失了。幾個月后，生產主管離開了部門。

最大的功能失調首先是問題的根本原因，即系統測試和驗收測試小組的存在，以及通過工具進行的溝通，以及試圖從側面將工作注入團隊（譯者注：工作不是由APO或者PO確認的）。

配置團隊負責構建系統，并將最終軟件投入生產46。他們還負責部分運營，因此需要與測試工具團隊和特性團隊密切合作。我不了解有關合作和分工的詳細信息。無論如何，這增加了工作的復雜性，并增加了特性團隊的工作量。

這個團隊的存在造成了交接，限制了團隊學習構建系統他們所需的真正的知識，創建了較長的反饋周期，并將責任轉移到了團隊外部，從而使預測變得更加不可預測。這個責任應該在團隊中。

版本管理團隊的作用是幫助PO，APO，非常規團隊47，并維護Jira中麻煩的PB的團隊，他們負責檢查數據一致性和支持團隊，APO向Jira中輸入數據，創建和維護電子表格和Jira之間的鏈接，向高層管理人員報告，幫助APO創建燃盡圖以及PB排序所需的其他信息。

就LeSS實施而言，此團隊的工作顯然是浪費的，并且存在該功能的最大原因是因為使用了Jira（當然，沒有人會計算出增加的價值或增加的成本）。使用更合適的PB工具，此功能可以很快消除。

實際上，由于隨著LeSS Huge的實施開始，對“發布管理”的需求（即協調）大大降低，因此該功能的規模減小了，團隊的負責人離開了并且沒有換人。

資源經理負責支持項目經理，以創建和維護該部門工作人員的概況，建立能力矩陣，確定戰略性的未來需求和潛在的問題領域。

原來的生產線管理結構被徹底淘汰，項目經理沒有自由的認知能力來處理生產線人員的所有方面（例如在LeSS框架中，開發負責人將擔任這一職位），并且作為快速解決方案，引入了資源經理。

在實際LeSS實施的過程中，架構師加入到團隊中，沒有形成自己獨立的部門。

由4名架構師48組成的職能部門，幫助APO拆分較高層級的需求（分到不同的RA），從而拿走了本該屬于團隊的職責。這種功能失調的設置會導致例如前期設計決策，從而給團隊帶來不必要的約束和負擔，并且可能導致實施中的解決方案不理想。交接、延誤和等待只是一些典型類型的浪費。

另外，我想強調的是，這樣一個（架構師）團隊的存在支持了X理論模型，在該模型中，“一些人思考，其他人只能動手”，即架構師思考，團隊“只能動手執行”，這是許多組織中的主要問題。

然而，架構師在團隊49中的行為大多像導師，參加了梳理工作坊50，并主持了架構師社區51。這些團隊已經具有足夠的基礎架構能力，他們可以自己梳理大多數的需求。然而在實施之初，團隊常常需要架構師的支持。

據我了解，架構師團隊存在的原因如下：

項目經理認為，將架構師整合到團隊中的風險太大

該產品是較大系統52的一部分，該系統具有與其他系統的關鍵接口，并且項目經理不想更改此設置中的任何內容以向外部過渡

架構師認為他們不需要改變

我的工作結束時，首席架構師來到我身邊，詢問開始第一步的時候，是否將架構師團隊解散并加入需求領域的團隊會更有意義呢。所以隧道里有了燈光（譯者注：意味著LeSS實施引發了新思考，后續有新的可能）。

運營任務的問題

Terra部門還負責運行軟件，并承擔各種運營任務。這些任務主要包括，回答客戶如何使用該軟件的問題，前期分析由PM＆BA＆CO提出的相關問題、監視數據（和正常運行時間）以及支持向Alpha公司其他部門提供產品相關的報告（不是狀態）。

分析工作坊的目的是確定并細化那些運營任務，使其透明化，并識別是否還有其他方法來處理（例如，將一些澄清工作移入梳理工作坊，就像通過消除多余流程的“少即是多”原則）。

當時基本上確定了兩個選項：

A. 開發該軟件的團隊也負責運營問題。 B. 一個專門的團隊負責運營任務

LeSS建議的另一種解決方案是輪換角色，這就是說其中一個團隊（在LeSS Huge中，每個RA可能需要一個輪換團隊）是“快速響應團隊”，因此，剩下的隊伍減少了。例如，每1-2個Sprint輪換一次該角色。

那些任務每個本身并不大，而是有大量的小任務[^53]。將它們單獨放入PB會使PB模糊并數量大增。解決此問題的另一種方法是（事后檢查）檢查這些任務將花費多少時間，然后PO和團隊將保留一定比例的時間用于這些活動（請參閱指南：處理特殊條目）。

解決方案（A）在LeSS實施之前52和實施中就已到位。這造成團隊的工作范圍出現一些令人不愉快且令人不安的變化，并影響了Sprint的預測。

該解決方案的優點如下：

團隊可以感受到他們的產品實際運行的現實情況

減少交接和排隊的數量

為團隊提供了機會，學習和改善當前客戶面對的挑戰

使問題透明化，以便團隊可以解決這些問題

注1：如果這些任務是浪費的和不必要的，則解決方案（A）可能與“少即是多”原則相矛盾，因為這增加了復雜性，支持現有過程而不是問我們為什么需要這樣做。但是，將這些特殊的工作條目交給專家團隊會使協作更加復雜。因此，當時的解決方案（A）顯得更有意義。

注2：事后看來，達到Sprint預測非常重要，即“需要可預測性”。這支持“合同游戲”53的概念。這個概念在最初（仿造）Scrum的實施之初肯定存在，但是在我擔任教練的過程中減弱了。

Terra部門在自我設計團隊工作坊期間嘗試建立解決方案（B）但失敗了，因此解決方案（A）得以繼續。

沖刺事件的問題

巨型LeSS的一項規則是，每個需求領域只有一個產品級別的Sprint，而不是不同的Sprint。Sprint結束時有一個集成的完整的產品。LeSS規則還暗示著一個產品級別的Sprint，而不是每個團隊有一個不同的Sprint。每個團隊同時開始和結束Sprint。每個Sprint產生一個集成的完整的產品。

整個部門遵循相同的兩周節奏54。

在進行Sprint計劃的第一部分之前，POT舉行了一次簡短會議以分享他們的情況并討論協調一致的機會55。

在每個RA中，Sprint計劃分為第一部分和第二部分56。通常，每個團隊都會派兩名代表參加到Sprint計劃的第一部分，并從PB中選擇幾個條目。

通常情況下，每個條目都經過較好的梳理，在這次活動中沒有任何驚喜。團隊代表回到他們的團隊進行Sprint計劃的第二部分57。作為Sprint計劃第二部分結果的PBI是對APO做出了預測。

在sprint計劃會期間有可能的共同工作時，團隊自己進行協調。

APO開始在卡上寫好PBI，以加快Sprint計劃。這種方法演進并包括了一個跟蹤系統，因此APO直到數據錄入Jira工具才知道哪個團隊選擇了哪個條目。

然后將物理板安裝好，這提供該RA中正在進行和即將進行的工作的可視化。APO進行了兩次“記賬工作”，將主要內容保留在物理板上，然后數據輸入到Jira中。

每個RA的所有團隊一起進行Sprint評審58。每次Sprint之后，都會與PM＆BA＆CO和其他干系人組織一次產品演示。

在團隊層面59舉行Sprint回顧會。較小的改進通常是立即完成的，而無需等待回顧會。每個RA都有一個總體回顧會60，而該部門每月有一次全部門的回顧會，跨所有的RA包含所有職能都會參加的回顧會61。幾個月后，每個RA都建立了整體回顧會。

在部門范圍的回顧中，與管理層、POT、Scrum Master、團隊代表以及其他職能部門的參與者一起識別障礙和改進的主題。有些障礙已轉發給AGC進行處理，其他障礙可由參與者解決。通常，在許多方面都進行了改進，例如每日站會（跨團隊學習），PO與APO的合作，如何處理缺陷，以及建立了多個社區。

PBR會議通常是多團隊梳理62，PM＆BA＆CO63常常需要參加。對于涵蓋多個RA的需求，需要組織多個RA一起參加梳理會。

僅在極少數情況下，才會按照LeSS規則邀請最終客戶，即在團隊、客戶、用戶和干系人之間盡可能多地進行澄清。

跨團隊協調是通過團隊非正式地請求其他團隊支持64或通過常見的Scrum of Scrums會話來進行的。集中的會議似乎是使問題引起團隊注意的快速方法。

此外，APO與架構師每天同步，和其他人（例如教練、部門主管）進行討論，以解決有關公共產品的問題。

Sprint待辦列表清單

每個團隊都有自己的Sprint待辦事項列表65。至少每個團隊有一個物理板，團隊還可以在Jira中使用。板子就在團隊附近。

完成的定義

在最初（仿造）Scrum實施期間，團隊與APO就所需功能的代表的共同的完成定義（DoD）66達成了一致。這是在兩個共同的工作坊上完成的67。只要我在場，共同的完成的定義便保持不變。不過部門意識到，增強DoD是一種改進68的可能。有些團隊確實增強了其團隊級別的DoD69。

在LeSS實施開始的時候，客戶文檔已集成到團隊中，團隊的DoD已經包含了這項工作。

單元測試和系統測試被認為是至關重要的，因為當前的設置產生了較長的反饋周期，并且通過Jira進行了尷尬的通信。在創建環境方面正在進行重大變化，因此可以改進測試領域的DoD。

工程實踐

所有團隊都集成到一個產品中。最初采用“Scrum”時，該部門已經有一個自動構建系統。單元測試覆蓋率很低，并且在系統測試階段發現了許多缺陷。系統測試和回歸測試通常是手動完成的。隨著越來越多的測試自動化，隨著時間的推移情況得到改善。

這是該部門通過增加單元測試覆蓋以及顯著增加自動化測試量來改善總體測試狀況的主要工作之一。我提供了指導，以在所有團隊（和所有團隊成員）中傳播測試驅動開發（TDD）和驗收測試驅動開發（ATDD）70的能力。部門采取了具體步驟（我沒有完全詳細了解）以將缺少的能力帶入團隊。

但是，特別是對于使用“舊”語言進行編程的開發人員來說，這是一個真正的挑戰，我在（輔導）的期間團隊并沒有掌握。

結對編程和編程(mob programming)被推廣為一種獲得學習能力的方法。舉行共同編碼活動以總體上提高編碼質量。

需求處理

LeSS的實施使需求梳理的方式從根本上發生了改變，從組件視圖到以客戶為中心的71拆分。

如果沒有以這種方式劃分需求的技能，就不可能在基于RA的結構中獨立工作。

APO，架構師，Scrum Master以及當然還有團隊成員都需要接受培訓，這是一條陡峭的學習曲線，存在許多障礙。能夠通過了解產品的性質和需求領域來留在客戶問題空間中是至關重要的，并且對如何制定和拆分需求的理解對于初始PBR工作坊的成功也是至關重要的。

在新客戶（例如保時捷）想要提供車輛保險的情況下，所有三個需求領域都涉及到。通常，承保是開始工作的第一個領域，其他RA在邏輯上是建立在此之上的。

在PB工具中（記住Jira?。┬枨罂偸怯懈讣?，該工具對于獲得關于產品整體功能就緒性的某種信息是必不可少的。

有時PB（電子表格中的第1級）中還包含中等粒度的條目，這是由于拆分較大的條目而產生的，例如，當您創建新客戶（例如“保時捷”）時，您不需要一開始就完成承保的所有細節。

簽訂合同一年后可能才需要某些功能。然后，通過拆分父級的需求，將這些特性拆分并在PB中排序，然后再進行基于單元的拆分。

這時，拆分主要遵循樹狀拆分，而不是推薦的細胞狀分裂[^75]，這是因為開始使用這種方法（對于Terra部門而言）已經是激進的新思維方式。這是一種在LeSS實施開始階段足夠好的方法，且相關人員可以一起合作。

此外，在極少數情況下，較小的PBI確實會出現在電子表格PB中，從而提供了像單元格一樣的拆分。這些條目為PM＆BA＆CO部門提供了證明，“敏捷”似乎在創造適應性方面發揮了作用。這創造了積極的勢頭，并在部門之間建立了信任。

管理文化的問題

對于開發人員，產品負責人，架構師和管理人員而言，典型方案如下：一個人在以下方面最多有三個上級：職業，職能和項目。大多數人來自外包公司，只有一小部分直接由Alpha公司雇用。來自Alpha的員工很少屬于Terra，而是按（長期）“借用”的基礎分配給Terra。

這是我所見證的責任的描述：

職業：這位上級負責薪水、休假的正式簽核以及長期發展。

職能：此人負責功能能力的所有問題，例如業務分析、編程語言、領域和測試

項目：此人向人們提供了應執行的實際任務。

有時，一個人同時擔任職能經理和項目經理。

功能和項目維度已刪除。取而代之的是，這些任務的一部分是通過自組織的團隊和“假PO”來完成的，“PO”主要是技術輸出負責人（現在仍然是某類子項目經理）。職業維度仍然存在。

情況發生了巨大變化。由于巨型LeSS的結構，APO通過減少他們在團隊工作中的參與而從其早期的虛假“分析師”和“指導者”PO角色成長而來。這些團隊提高了自組織的程度。對于大多數人來說，職業上司仍然沒有受到影響。來自戰略合作伙伴的所有人員在其母公司中均有職業上司。

很明顯，在這種情況下，“文化遵循結構”這一說法得到了確認。新文化顯然是值得注意的。

幾個Sprint之后

重組后的兩個月，由于幾個人離開了部門，三個RA中的兩個RA需要再次進行重組。這是通過以自我設計團隊工作坊的形式自愿提供的，工作坊的主持人（Scrum Master）和受影響的APO對此問題進行了解釋。在短短的兩輪中就解決了問題，并成立了新的特性團隊。繼續進展！

LeSS實施的第一階段以6.6版本上線結束。這次活動仍然具有與舊風格類似的風格，即星期六人們在辦公室發布，管理層提供食物并查看該軟件順利投入生產的舊風格。

然而，在編寫第一版本報告“發布活動日”之后的一個星期，沒有出現預期的缺陷風暴?？梢蕴岣哔|量嗎？進展！

可能需要注意的是，該部門尚未決定正式轉向巨型LeSS。然而，該部門從仿造Scrum的實施中學到了經驗，并開始在很大程度上遵循LeSS框架和結構，基本上沒有做出有意識的選擇。但是，持續改進和學習還有很長的路要走。

從一開始，我72就與一位“內部”教練73?74結對。

“有人可能會受到傷害”?75：經過總共6個月的訓練，我的教練期突然結束了。顯然，我的方法又太過急，或者部門還沒有做好真正改變的準備，而我的看法也太不舒服了。有幾個初級教練在我之后來了（又走了）。為了持續改進，需要更合適的高級教練。

結語

在2017年12月，我與項目經理以及部門其他成員進行了討論。項目經理說…

“盡管對新功能的吞吐量還不滿意，但他承認其產品質量已得到顯著地改善，并且對于連續三個版本來說，以前預期的新版本出現的常見缺陷風暴并沒有發生。該部門搬到了另一棟大樓，那里的房間不像以前那樣支持團隊合作。該公司在2017年夏季也面臨了一些裁員，更多的開發工作轉移到了印度。保留了RA的基本結構，但是失去了一些重點。工程實踐、特別是測試（代碼覆蓋率和回歸測試的自動化）得到了改善。”

在這段時間之后，我基本上與團隊失去了聯系。因此，從長遠來看，LeSS Huge的實施是失敗還是成功的任何陳述都是推測。

從最初的“Scrum”實施到巨型LeSS的實施，這非常令人著迷。突然，“事情”開始發生并對人們有意義。人們更快樂，他們喜歡承擔挑戰和承擔責任。結果產生并且質量提高。見證工作場所的這種轉變是一次壓倒性的積極經歷。進展！

致謝

我要感謝Ran Nyman，他提出了將此案例用作案例研究的想法，感謝他對本案例的支持和最初的評論。我還要感謝ME允許發布此案例。此外，我還要感謝Ran Nyman，Elad Sofer，Bas Vodde和Craig Larman的寶貴意見和評論。

注釋：

PM＆BA＆CO，測試經理，測試工具負責人，生產經理，發布經理和首席架構師形成了功能失調的設置，在“新組織結構的問題”一章中進行了更多討論。???

據我所知，后來兩個部門都考慮APO是來自PM&BA&CO部門的。???

根據LeSS指南“五種關系”，PO工作得非常有效，并與APO進行密切合作。???

參考書籍Large-Scale Scrum More with LeSS（英文版）第135頁???

參見指南：社區工作???

參見指南：大型團隊的引導???

參見實驗：避免…開發與測試分開；避免…測試部門。???

本地CuDo團隊由位于愛爾蘭的的按需支持的團隊三名專家組成。???

我沒有參與這個團隊的輔導，因此對此的了解非常有限。???

參見指南：“產品負責人助手”???

另請參閱需求處理一章；Terra的高級管理人員不敢放手架構師團隊。請參閱“避免…獨立的架構師團隊”???

避免…宇航員架構師（PPT架構師）???

嘗試…專家參與設計工作坊而不是事后批準審核???

嘗試…設計、架構師實踐社區，團隊成員就開始學習更多相關知識???

“構建軟件并運行軟件”的概念.???

避免…產品管理與研發部門就“發布合同”（范圍和日期）進行談判、???

周四是Sprint計劃會，周三是Sprint評審、回顧和產品負責人團隊會議。Sprint Planning on Thursday, Sprint Review & Retro, POT meeting on Wednesday.???

請參閱LeSS規則（產品負責人和領域產品負責人頻繁同步。在進行Sprint計劃之前，他們確保團隊工作在最有價值的條目。在Sprint評審之后，他們進一步啟用產品級別的實施。）和指南 ：產品負責人團隊會議。???

請參閱LeSS規則（Sprint計劃由兩部分組成：Sprint計劃第一部分所有團隊都參加，而Sprint計劃第二部分通常是每個團隊單獨進行的。在共同空間中進行多團隊的Sprint計劃第二部分以緊密合作相關的條目。）???

請參閱LeSS規則（“Sprint計劃第二部分”是由團隊決定他們將如何處理所選條目的方法。通常涉及設計和創建團隊的“Sprint待辦事項列表”）。???

請參閱LeSS規則（只有一個產品的Sprint評審；所有團隊共同一起的。確保合適的干系人加入并貢獻了有效的檢視與調整所需的信息）。See LeSS rule (There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the informa- tion needed for effective inspection and adaptation).???

參見LeSS規則（每個團隊有自己的Sprint回顧會） See LeSS rule (Each Team has its own Sprint Retrospective).???

參見LeSS規則（在團隊回顧之后舉行總體回顧，以討論跨團隊或系統范圍的問題并創建改進的實驗。產品負責人、Scrum Master、團隊代表和經理（如果有）參加）。???

參見LeSS指南: 多領域的評審會與回顧會。???

參見LeSS規則（PBR中每個團隊梳理他們將來可能要做的條目。進行多團隊或總體PBR可以增進共同理解，并探索協作的可能性，這發生在密切相關的條目或者需要更廣泛的投入和學習中。）???

謹記，“中間人分析師”的那些人，這種設置是功能失調的。???

參見LeSS規則（跨團隊協調由團隊決定。相對于集中式協調，LeSS更偏好分布式的和非正式的協調。通過代碼溝通、跨團隊會議、組成導師、旅行者、偵察員以及開放空間來強調只交談和非正式的網絡。）???

參見LeSS規則（每個團隊有自己的Sprint待辦事項列表）。???

參見LeSS規則（有一個整體產品的完成的定義，所有團隊是一樣的）???

參見避免…質量團隊定義的完成的定義???

參見LeSS指南：擴展產品定義???

參見LeSS規則： 每個團隊可以通過擴展通用的DoD有自己更嚴格的完成的定義。???

參見實驗：嘗試…驗收測試驅動開發。???

參見實驗：嘗試…編寫客戶為中心的需求。???

我完全是外部的。參見實驗：嘗試…外部敏捷教練。???

我將內部用引號括起來，是因為該人確實來自合作伙伴組織，并且被錄用只在這里工作。???

參見嘗試…內部教練和外部教練；盡管該主題在TDD章節中，但我認為它總體上也適用于教練。???

Leading Teams: Setting the Stage for Great Performances by J. Richard Hackman.???

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。