大規模敏捷之Big Room Planning
\\\本文要點
\\
- Big room planning是每季度舉行一次的為期兩天的計劃會議，參與人員包括所有專案和團隊成員\\t
- 如果正確地推進，讓100個或更多的人在一起做計劃是可能的，有利的\\t
- 人們一邊在所在的團隊中做計劃，一邊和其他團隊協作計劃\\t
- Big room planning讓每個人有個總體瞭解，知道其他人在做什麼，瞭解誰和誰之間有依賴關係\\t
- 達成共識和總體方向（總體規劃，the master plan）是一個成功的big room planning的先決條件\
在第一篇文章《Scaling Agile – a real story》中，我跟大家分享了來自某個專案的大規模敏捷真實案例。在第二篇文章《Slicing and understanding together》中，我描述瞭如何把需求分割成潛在的可釋出的史詩故事。第三篇文章《Master planning together》中，我講了步驟以及如何為整個專案設定方向。現在，這是最後一篇了，我要講講大事情——big room planning。
\\在我們更深入探討之前，讓我們先搞明白前後關係。我把它作為大規模計劃的一部分來講解（如果你已經讀了之前的幾篇文章，可以跳過這個部分）。
\\大規模計劃
\\大規模計劃，包括切片和總體規劃，是幫助你應對大規模計劃挑戰的程式化方法。大規模計劃把組織整體戰略目標（圖中央的目標）當做出發點，包括4個層面的計劃：
\\- 切片\\t
- 總體規劃\\t
- Big room planning\\t
- 衝刺計劃\
雖然不同規模的框架給每季度的big room planning提供有用的框架，所有的團隊和利益相關者會聚上幾天，大多陣列織知道如何做衝刺計劃，但是很多為了給big room planning做好完全的準備而苦苦掙扎。這就是含有1.切片和2.總體規劃的大規模計劃要切入的地方。
\\為什麼是big room planning？
\\一旦你試過了，就知道答案了：是的，可以的。事實上非常棒。而且，是的，很值得。我已經看到這樣的計劃方法從重大的時間問題中挽救了專案。還不止一次哦。
\\我來舉幾個例子。
\\第一個是深陷交付問題的金融工具市場法規(Mifid)專案。然後，他們開始以不同的方式自我組織起來，也開始比以往更投入地做計劃。現在，他們已經回到正軌上。這是第一篇文章《Scaling Agile – a real story》裡提到的例子。
\\更近的例子是我最近正在提供諮詢的為其客戶開發應用程式的專案。這個專案由三個團隊組成，分別是數字、IT和零售。這個專案已經進行了差不多兩年時間，但直到幾周前，才為其50位客戶提供了為期兩週的試點。
\\幾個月前我開始跟進這個專案時，我聽到很多這樣的話，“但是我們不知道零售那邊是怎麼想的”，還有“數字團隊的人真的什麼都沒做”，“我不知道”，“怎麼事情總是IT團隊在做”，“這只是一個應用程式？”
\\經過幾個月的工作、與來自各個團隊的人進行了數次總體規劃會議之後，大家終於不再談論所有那些不能完成專案的原因了。大家開始討論該做什麼，設法分割任務，並優先考慮某些史詩故事，一些潛在的版本。
\\各團隊仍然不情願優先把時間用於和其他團隊交流。他們只是忙於自己的事。構建這個應用程式的IT團隊不想放棄他們的Scrum流程、他們的衝刺目標，不想危及他們的計劃速度。他們對零售團隊為之苦苦掙扎的應用程式內容不感興趣，對他們認為是表面文章的板面設計、使用者體驗也絲毫不在意。他們把這些看作是其他人的工作。他們好像在造一輛沒有引擎，也沒法加油的汽車。
\\我設法讓他們聚在一起做了big room planning。每個團隊把史詩故事分解成每個團隊每週最多兩個主要任務。他們也建立了專案板，並討論了任務和成員之間的依賴情況。快結束的時候，IT團隊的某個成員建議每天早上9：15碰個面，瞭解其他人的工作狀況並加以協調。很多人在big room planning之後感激不盡，他們工作得很愉快，並說最終能和其他團隊的成員進行有意義的交流真是太棒了。
\\Big room planning只過去兩週，我們就準備好了。應用程式已經提交到應用程式商店，客戶開始下載使用並從中獲得益處。
\\那麼，回到關於big room planning是否值得，是否有效這個問題上，答案就是肯定的。
\\最後一個爭論：無論在專案中有多少人，每季度兩天就是人們工時的3.3%。因此，如果big room planning在交付價值上提高了3.3%的生產效率，那麼big room planning就是一個不錯的投資。
\\Big room planning簡介
\\
Big room planning是每季度舉行的為期兩天的計劃會議，所有專案和團隊成員都要參加。
\\根據總體規劃和專案目標，所有團隊要討論在接下來的三個月裡將如何完成專案目標。
\\他們通過把總體規劃的史詩故事分解成功能，討論、估算和優先考慮這些功能，並給出在接下來的4個兩週衝刺中可以完成多少功能的最佳選擇。
\\在這兩天裡，各個團隊幾次聚集在專案板旁，張貼和討論他們各自的功能。他們討論整體情況，梳理依存關係，不斷調整功能位置以建立最佳可能的整體規劃。
\\那兩天臨近結束時，大家就接下來三個月的團隊和專案目標達成一致，討論了風險並加以規避。
\\為big room planning做好準備
\\正如“規模計劃”插圖所示，你需要把切片和總體規劃安排妥當以獲得成功的big room planning。
\\還有，要完全做好準備，你需要更多：
\\- 就誰來分享和更新每個人的專案願景達成一致\\t
- 就誰來展示解決方案的現狀及整體架構達成一致\\t
- 跟專案利益相關者溝通，確保相關人員在場。你希望在big room planning上有足夠的瞭解和授權。\\t
- 掌握所有總體規劃的史詩故事，包括估算和優先事項。我傾向於把每個史詩故事都列印在A4大小的紙上並張貼於牆上，這樣大家可以隨時走近它們並討論。\\t
- 衡量團隊的敏捷及Scrum成熟度，並安排相應的協調人員。成熟度越低，就需要越多的協調人員。每個團隊至多一個協調人員，如果他們不熟悉敏捷，就分解史詩故事並利用計劃撲克（planning poker）進行估算。我傾向於擁有不屬於專案、在大規模敏捷上有豐富經驗的外部協調人員。\\t
- 準備好足夠的計劃卡、貼紙、標記筆、擁有標示依存關係的紅線、標籤等等\
準備好合適的房間並佈置好
\\雖然這是上面提到的“為big room planning做好準備”的一部分，那個房間也要考慮到。究其原因是都很重要，但是big room planning會議往往沒有得到組織足夠的重視。
\\
物質上的準備可以促成或破壞big room planning，因此，請嚴肅以待。
\\- 確保提供一個足夠容納所有人的房間，每個團隊要有一張專屬的桌子，另外要為其他專案參與者和利益相關者準備一張桌子。我的經驗法則是要找一個兩倍於能容納所有參與人員數量的房間。一定是一個房間，而不是兩個或更多靠近的房間，因為如果所有人不是在同一個房間裡，團隊和人們之間的交流會受到影響。\\t
- 佈置好房間——最好是在進行big room planning之前一天。擺好桌子。把總體規劃掛在每個人能看到的地方。在團隊桌子邊上的牆上貼好團隊計劃。準備好專案板，展示相關的專案海報等等，還有專案願景、用例圖等。\\t
- 錦上添花的是：\\t
- 在專案板上顯示每個衝刺階段的起始和結束日期，讓大家更清楚地明白這是事先確定的，對大家來說也更方便。\\t\t
- 讓各團隊在專案板上寫下產品負責人和Scrum master的名字，方便每個專案參與人員。因為有很多要理解和記住的事，我們就不必讓人們去記住這些名字了。\\t\t
- 為每個參與人員準備姓名牌，便於大家記住其他人的名字，也有助於建立關係。\\t
實施big room planning
\\Big room planning的那天早上
\\大日子終於來了。第一天早上，你應該在專案開始前一小時就到達。或者提前兩個小時，如果前一天沒有準備好房間的話。
\\我建議你跟同事和主要利益相關者做最後一次簡報，包括專案領導者、專案架構負責人、業務利益相關者（那些代表僱員/客戶，那些會從專案中得到好處的人），最後過一遍整個專案和角色。
\\我也建議給各團隊分配指定的協調人，這樣每個團隊就只能或者主要從一個協調人那裡獲得支援，從而比起從不同的協調人那裡獲取支援將獲得更一致的支援和建議。
\\確保你及時完成為你自己和其他協調人要做的最後準備工作，然後迎接其他人的到來並把他們帶到屬於他們的桌子那裡。
\\介紹
\\以介紹這兩天的目的和議程開場——就像這樣的：
\\| \\t\t\t 議程專案 \\t\t\t | \\t\t\t 備註 \\t\t\t | \\t\t\t 主持人/協調人 \\t\t\t |
| \\t\t\t 第一天 \\t\t\t | \\t\t\t\\t\t\t | \\t\t\t\\t\t\t |
| \\t\t\t 目的 \\t\t\t | \\t\t\t 今天我們在這裡為接下來的3個月制定計劃，專案要達到XYZ目標 \\t\t\t | \\t\t\t 專案領導者 \\t\t\t |
| \\t\t\t 專案願景 \\t\t\t | \\t\t\t 展示/提示人們（更新後的？）專案願景 \\t\t\t | \\t\t\t 業務利益相關者 \\t\t\t |
| \\t\t\t 解決方案\u0026amp;架構 \\t\t\t | \\t\t\t 我們離那個解決方案有多遠？我們是在什麼基礎（更新了的？）上做那個解決方案？ \\t\t\t | \\t\t\t 專案架構負責人 \\t\t\t |
| \\t\t\t 總體規劃 \\t\t\t | \\t\t\t 展示在接下來的3個月中，總體規劃特別關注的內容 \\t\t\t | \\t\t\t 協調人（也可以是專案領導者） \\t\t\t |
| \\t\t\t 團隊\u0026amp;史詩故事 \\t\t\t | \\t\t\t 哪些團隊在哪些史詩故事中有利益關係 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 團隊分組介紹 \\t\t\t | \\t\t\t 說明團隊把史詩故事分解成功能的具體情況，並對它們進行評估和優先排序且估算和優先考慮它們 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 團隊分組 \\t\t\t | \\t\t\t 人們在其所在的團隊中工作 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 專案板 \\t\t\t | \\t\t\t 各團隊在專案板上張貼其最初的計劃，開始和其他團隊協作 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 重複 \\t\t\t | \\t\t\t 重複團隊分組和專案板討論——一般在最後的專案板集合前要做2次 \\t\t\t | \\t\t\t\\t\t\t |
| \\t\t\t 第二天 \\t\t\t | \\t\t\t\\t\t\t | \\t\t\t\\t\t\t |
| \\t\t\t 團隊分組 \\t\t\t | \\t\t\t 接著第一天，團隊被鼓勵和其他團隊及利益相關者協作 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 專案板 \\t\t\t | \\t\t\t 專案板總結，包括所有團隊的功能和依存關係 \\t\t\t | \\t\t\t 協調人 \\t\t\t |
| \\t\t\t 風險 \\t\t\t | \\t\t\t 各團隊提出風險，然後在全體大會上討論並得到規避 \\t\t\t | \\t\t\t 專案領導者 \\t\t\t |
| \\t\t\t 專案目標 \\t\t\t | \\t\t\t 各團隊制定他們的基本業務目標，然後就接下來3個月的專案目標達成一致。 \\t\t\t | \\t\t\t 產品所有者和業務利益相關者 \\t\t\t |
| \\t\t\t 信任投票 \\t\t\t | \\t\t\t 以1-5為評分標準，看看每個團隊對自身計劃的信任度 \\t\t\t | \\t\t\t Scrum master和協調人 \\t\t\t |
| \\t\t\t 接下來的步驟 \\t\t\t | \\t\t\t 通常接下來的步驟是讓團隊制定衝刺計劃，然後開始工作 \\t\t\t | \\t\t\t 專案領導者 \\t\t\t |
| \\t\t\t 保持並嘗試 \\t\t\t | \\t\t\t 反思那兩天的big room planning \\t\t\t | \\t\t\t 協調人 \\t\t\t |
上面的議程受到了SAFe® PI Planning所建議的議程的啟發，但兩者並不完全相同。上面的某些步驟相當直接，我不打算深入下去。對於其他有點棘手的步驟，我會分享一些技巧和竅門：
\\1.目的
\\我們在這裡的目的是為接下來的三個月做個計劃，完成XYZ目標。
\\如果這是專案中的第一個big room planning，那麼我建議要講清楚大多數事情可能會很順利，但很有可能在那兩天裡會出現一些狀況。希望大家都能諒解，把這些當做學習機會，也就是下次可以改善提高的地方。
\\這個XYZ目標是接下來三個月的總體規劃的概覽，不只是單個的史詩故事，還包括計劃的目的及簡要描述。因此，這給每個人一個大大的提醒，作為整體來說，什麼是專案的目標。同樣重要的是小一點的提醒，什麼是接下來三個月的目標。
\\2. 專案願景
\\展示/提醒人們（更新後的？）專案願景
\\我們希望有一個主要業務利益相關者給大家鼓鼓勁，提醒我們大家我們在這裡的原因。解釋一下為什麼專案戰略目標對業務和整個公司都很重要。講個故事比用簡報的效果好，如果我們能讓利益相關者來講講他自己的故事，說說“為什麼這對我個人來說是重要的”，那效果更好，
\\3. 解決方案和架構
\\通過一個對實際產品簡單的現場演示，或者對於那些已經交付的東西給出一個視覺展示，以及還有哪些是缺失的，提醒大家我們離解決方案有多遠。同時重複架構的指導方針，分享最新的技術基礎的變化。
\\4. 總體規劃
\\在解釋的時候，要讓每個人都參與進來，走一遍總體規劃。把大多數時間花在接下來的三個月上。也要考慮接下去的每個季度，只是提醒大家我們現在在做的事，但不要花太多的時間。
\\5. 團隊和史詩故事
\\哪個團隊在哪個史詩故事有相關利益
\\解釋這個問題的最佳方法是本系列文章中的第一篇《Scaling Agile – a real story》中反覆提到的那一小部分。在第二個big room planning中，我們會講一下，我們會試試跟第一個big room planning中不同的方法，每個團隊選擇他們認為是屬於他們的史詩故事，和其他團隊就此討論一下或完全不討論。
\\然後各個團隊聚集在史詩故事概覽板周圍，那個時候我們就問他們一些問題，這些問題跟與團隊相關的史詩故事有關。接著，我們讓每個人在這些史詩故事上貼上一個代表他們團隊的彩色即時貼（參看圖Epics \u0026amp; teams II）。一個小時後，我們就會得到一個概覽，知道哪個團隊在哪個史詩故事上是主要的驅動者，在每個史詩故事中，有哪些其他團隊涉及其中。
\\讓我們感到驚喜的是這很有效果。在那塊板子前，兩天裡有很多人來來往往，通常是來自不同團隊的人們討論他們彼此的需要。他們如何來互相幫助？
\\
6. 團隊分組介紹
\\說明團隊把史詩故事分解成功能的具體情況，並進行評估和優先排序
\\提醒人們這兩天的剩餘議程，並展示進展的所有細節。通常包括這些事：
\\- 對每個團隊——誰是你們團隊的主要協調人\\t
- 每個團隊是否已經瞭解對於接下來的5個衝刺階段中團隊能力的概況。舉個例子：你有一個6人團隊，其中包括Scrum master和產品負責人。一個成員在為期2周的衝刺階段休假1周。每個人在整個星期中算4個點。因此，這個團隊的能力在這個衝刺階段的點數是5x8 + 1x4 = 44點。讓團隊在其團隊衝刺圖和專案板上寫下來。有一些備註：\\t
- 如果這是專案的第一個big room planning，那麼我通常讓所有團隊只做做這個步驟，並和其他團隊分享他們的團隊能力\\t\t
- 那麼，為什麼不是一週每人5個點呢？歷史證明，在做計劃時，人們總是太樂觀。每週只算4個點（約等於每週4天）是一種彌補樂觀的機制。\\t\t
- 為何把Scrum master和產品負責人也包括在團隊能力之內呢？那是因為構建一個產品遠不是把東西放在一起那麼簡單，比如在軟體專案中寫程式碼和測試程式碼。它還包括大量的業務討論、決策、協調等等事物。換句話說，這些是Scrum master和產品負責人的工作。\\t
- 接下來，解釋一下我們希望團隊如何把他們的史詩故事分解成每個史詩故事3-5個功能（再少的話，你只是涉及了一點皮毛；更多的話，不可能看到在專案層面上的概況）\\t
- 我們希望把功能寫在即時貼上。對於每個功能，要求有簡短的名字、說明、對史詩故事的引用和評估。參看pincode驗證的例子。
\\t - 開始估算時，從尋找一個人一週或兩個人在2天半內能完成的功能開始。算它5個點，然後以其為標準，估算其他功能。\\t
- 除此之外，團隊可以繼續工作，把史詩故事分解成功能，就好像他們在Scrum衝刺計劃會議中分解主題那樣。\\t
- 團隊被要求定期通過專案板和其他團隊分享他們計劃進行的結果。 \
7. 團隊分組
\\只需讓大家按照團隊分組介紹的指示做。確保各個團隊從利益相關者和協調員那裡得到恰如其分的關注。不至於太多而打攪他們，也給足了他們所需的引導。
\\8. 專案板
\\各個團隊在專案板上貼出他們最初的計劃，然後和其他團隊協作
在首次專案板集合之前，給各個團隊15-20分鐘的提醒。他們要為每個功能寫好一張即時貼，但是無需介紹專案板，這是為了創造一個更乾淨更好的概覽。
\\當時間到了時，讓每個人都站在專案板那裡，從每個團隊中選取一人（可能是Scrum master或產品負責人）把他們認為屬於他們的功能貼到衝刺階段那裡。
\\你可能需要鼓勵討論團隊和功能之間的依存關係，但是也有可能，當團隊遇到這類問題時在沒有你的幫助情況下就開始討論。
\\通過用紅線連線有依存關係的功能把依存關係視覺化。一旦識別出依存關係，鼓勵團隊結束依存關係討論，除非這個依存關係涉及所有的團隊。
\\小技巧：第一次專案板集合早比晚好，不要晚於第一次團隊分組開始之後那幾個小時。你也許會碰到團隊抵抗，因為他們覺得還沒準備好。如果你等得太久，就不能得到早早做好能獲得的跨團隊協作。看到團隊在第一次專案板集合後的相互影響更多會感到很不可思議。
\\9. 重複
\\重複團隊分組和專案板討論，一般在最終的專案板集合前要進行1-2次。記住溫和地推動他們每1-2小時在專案板前搞個碰面會，就算他們在各自的團隊中沒覺得準備好也要做。這將推動他們更多地跨團隊協作和協調。
\\10.團隊分組
\\接著第一天的工作，鼓勵團隊和其他團隊及利益相關者進行協調。
\\在這個團隊分組之後，你應該開始看到每個團隊的計劃大綱。如果他們還沒在其團隊計劃上貼出他們的功能，現在是讓他們做這個的好時機。它讓團隊更容易理解其他團隊正在計劃的東西，什麼時候要互相拜訪。
\\11.專案板
\\用所有團隊的功能和依存關係來總結專案板。記住，計劃夠好即可。每天都要重新審查計劃，稍後進行細節整理。
\\12.風險
\\各個團隊在冒風險，在全體大會上討論和規避風險。有些風險促成規避操作，那是我們想在團隊計劃和/或在專案板上做的，因此我們不只是討論它，還要實際做點事。其他風險我們只是接受。把大部分時間花在最主要的3-5個風險上，其他風險現在只需列出。
\\13. 專案目標
\\各個團隊制定他們基本的業務目標，然後就接下來3個月的專案目標達成一致。
\\在一個有著很多團隊、觀點、史詩故事和功能的專案中，人們經常需要幫助來尋找和記住整體目標是什麼。
\\為了幫助尋找，我們讓產品負責人通過介紹接下來3個月的一些總體目標來指導團隊。然後我們請產品負責人邀請業務利益相關者一起來討論，並對接下來3個月的專案目標達成一致。目標寫得越短小越好，它們幫助整個專案實現共同目標的能力也越強。
\\這裡有個例子是很難實現的專案目標：“在實時資料上執行（Run on live data）”。
\\14. 信任投票
\\按等級從1到5，看看每個團隊對各自計劃的信任度
\\作為最後的測試，我們可以讓每個團隊的Scrum master詢問團隊成員對於自己團隊計劃的信任程度，也可以詢問他們對整個專案的信任度，信任度等級最高為5。
\\我建議你只在跟進討論為什麼這些數字不高點時才這麼做，另外，更重要的是，計劃或情況如何改變才讓大家更信任計劃。一個好問題是：“做什麼能讓你更接近最高等級？”
\\15. 後續步驟
\\通常，下一個步驟是團隊做衝刺計劃，接著開始工作。也要討論在不久的將來會發生的事情，記得要感謝每個人，謝謝他們付出時間給予配合。
\\16. 不斷嘗試
\\反思big room planning那兩天
\\記得在big room planning的開場白中提到的可能出現的狀況嗎？
\\這就是你該為下次做得更好而收集資訊的時候。我自己喜歡讓人們在即時貼上寫下來：
\\- 用1-5（5是最好）給他們對於那兩天的想法進行打分\\t
- 為下一次保留一件事\\t
- 下一次試試用不同的方法做同樣的事 \
讓大家在出去時把它們貼在門上。當所有人離開後，拍下照片，或許讀一下，但要等到準備下一個big room planning的時候，再去想一想。在這個時間點，在兩天的big room planning之後，你的大腦也許不能正確運作了，無論如何都不能做合理的反應了。
\\在big room planning之後
\\如果你想擁有big room planning的好處和保持良好的跨團隊協作，那麼我建議每天在團隊的站立會後來個專案板邊上的Scrum-of-Scrum會議。
\\議程安排和站立會的一樣，除了在Scrum-of-Scrum上的分享是以團隊為單位而非團隊成員。
\\作為協調人或專案領導者，你或許想用我喜歡的這些問題中的一個來結束每個Scrum-of-Scrum會議：
\\我或其他人能做些什麼來幫助你更快實現我們的專案目標？
\\但是，只有你希望收集那些障礙問題，並解決它們的時候才問這個問題。我喜歡把這叫做障礙分離（impediment busting），因為它聽起來比利益相關者管理和風險規避更酷更有力。
\\結語
\\Big room planning給出了一個在下個季度所有要完成工作的概述。那是所有專案和團隊成員每三個月集結起來做計劃的兩天。
\\為了理解big room planning的目標，必須確保利用總體規劃對整體方向有共識。
\\協調在計劃的成功中扮演了很重要的角色。確保你有熟練的協調人，有個足夠大的房間以容納所有的人、桌子、計劃板以及讓計劃和依存關係可見的所需材料。
\\最後，與任何敏捷實踐一樣，暫停一下以反思什麼順利進行了，什麼在下次big room planning中需要改善是極有價值的。
\\行動號召
\\下次你如果有超過2-3個團隊的專案，可以試試。提前幾個星期定下總體規劃和big room planning的日期，然後邀請參加人員並開始準備。如果有太多阻力，就把它當做一次實驗。
\\如果你已經試過big room planning但感到失望了，那就再試一遍。如果你遵循這系列文章中提到的技巧和竅門，我可以保證下次你會有更好的體驗。
\\也許你最終像Martin一樣也說不定，Martin是我目前參與的一家銀行的CRM專案的負責人。在總體規劃和big room planning之後的幾個星期，他說：“我愛上這規模化計劃了。之前我們浪費了業務部門不關心的數以百萬計的支援流程，我們甚至都不知道。現在我們齊心合力再次為我們的客戶創造價值。”
\\然後，他還說：“我們早該這樣做了。”
\\本系列文章
\\本文總結了規模化計劃的系列文章，包括以下文章：
\\- Scaling Agile – A Real Story\\t
- Scaling Agile – Slice and Understand Together\\t
- Scaling Agile – Master Planning Together\\t
- Scaling Agile – Big Room Planning \
我希望你可以分享關於這系列文章的想法，嘗試一下其中的技巧和竅門，最後，讓我們知道結果怎樣。
\\作者簡介
\\
Ole Jepsen 是一位敏捷轉型顧問，與希望領導轉型的組織合作。利用其在敏捷方法論、基於意圖的領導力和便利化上的專業知識，Jepsen與企業和領導者一起努力以建立人們蓬勃發展和創造價值的開發組織和工作空間。
閱讀英文原文：Scaling Agile – Big Room Planning
\\感謝冬雨對本文的審校。
相關文章
- 如何貫徹規模化敏捷？敏捷
- 銀行規模化敏捷的窘境敏捷
- 如何領導規模化敏捷變革？敏捷
- SAFe敏捷框架下的工具，實現規模化敏捷開發敏捷框架
- 為什麼企業要做大規模敏捷？敏捷
- 敏捷規模化框架的思考-再談Spotify敏捷框架
- 實戰規模化敏捷：從8人到百人的敏捷之路敏捷
- 資訊系統規劃（Information System Planning, ISP)ORM
- 規模化敏捷LeSS（二）：LeSS*隊實踐指南敏捷
- 大咖佈道丨證券行業規模化敏捷和核心能力演進行業敏捷
- Planning Calendar
- 規模化敏捷LeSS（二）：LeSS團隊實踐指南敏捷
- Android Architecture Components 之 Room 篇AndroidOOM
- Android Room2.0之@TypeConverters使用AndroidOOM
- 規模化敏捷 LeSS（三）：LeSS Huge 是怎樣煉成的？敏捷
- Gmail全球大規模當機AI
- Android Room 之儲存 Objects 中的 ListAndroidOOMObject
- 大規模文字相似度計算
- 大規模圖嵌入 | 論文快訊
- 5G大規模MIMO技術
- 大規模圖訓練調優指南
- 大規模向量檢索與量化方法
- 如何開展大規模整合測試
- Scala在Databricks的大規模應用
- 大規模MySQL運維陷阱之基於MyCat的偽分散式架構MySql運維分散式架構
- 規模化敏捷沒準備好，就別想數字化轉型成功了敏捷
- Leetcode 252. Meeting Room 253. Meeting Room IILeetCodeOOM
- Android Jetpack元件之資料庫Room詳解(一)AndroidJetpack元件資料庫OOM
- 阿里大規模資料中心的效能分析阿里
- 大規模圖視覺化工具和方法視覺化
- MPP(大規模並行處理)簡介並行
- 大規模實施 OKR 的成功經驗OKR
- Node 在滬江的大規模實踐
- 雲端計算規模大嗎？可靠嗎？
- [譯] Room ? CoroutinesOOM
- SAP Integrated Business Planning 1805 New Features
- 攀登規模化的高峰 - 螞蟻集團大規模 Sigma 叢集 ApiServer 優化實踐APIServer優化
- 技術如何改變敏捷的規則敏捷
- 運籌優化（十三）--大規模優化方法優化