1月16日，Agilean 咨詢團隊在 Adapt 規模化敏捷框架第七期直播中，邀請了多位群友觀眾來到直播間進行連麥互動，通過大量實例問題的分析解答，對 Adapt 框架第一個系列直播活動進行了收尾總結。限于直播時長，我們無法對這些問題一一解答，特撰此 Q&A 并與大家分享。

直播回放

文末有本次直播關于敏捷導入、業務協同、項目&產品管理、大規模敏捷交付等話題的回放，可點擊原文鏈接查看。

1月31日，我們將組織一場 Adapt 規模化敏捷框架的線上培訓課程，感興趣的同學，可識別下圖二維碼報名。

識別二維碼報名周日 Adapt 培訓課程

1

敏捷轉型四問

Q1：在向業務人員宣導敏捷實踐的時候，應該宣導哪些方面，才能更好的讓業務人員參與和支持敏捷實踐？

A1：促進業務側更多參與敏捷實踐確實是很多組織面臨的難題。在宣導時，建議結合業務自身的痛點以及業務與研發協作的痛點出發，有針對性的進行宣導。（By 雷晶晶）

首先是協作上的痛點：

交付時效痛點：可以通過小批量交付，縮短交付時效。

交付內容「貨不對板」痛點：該問題來源往往是交付時效太長，導致需求澄清重要細節的損耗，或因為交付過程太長，期間出現需求變更。采用敏捷實踐后，基于頻繁的溝通與持續的交付，讓業務有機會不斷校準需求細節，促進交付內容更符合業務目標

交付質量痛點：采用敏捷方式后，由于測試左移、開發 Showcase 等實踐，每次交付的內容能得到更充分的測試與驗證，質量將有改善。同時由于每次交付的「容量」降低，問題定位與修復將更快

過程黑盒痛點：持續溝通、雙層看板都將向業務透明進展與實際情況。

其次是業務痛點：

創新痛點：業務的產品創設與創新，本身有業務敏捷的實踐。落地時都需要研發具備持續交付與快速實驗能力，這都是研發敏捷實踐可以輔助的內容

降本提效：研發交付的內容不是業務和市場需要的，就是最大的成本浪費，敏捷對于交付內容的準確性的提升有助于幫助業務節省成本；研發和業務更好協作，可以讓研發從系統角度給業務更好的實現建議。

跨部門協作：研發敏捷劃分部落以后，能夠對齊業務條線，一定程度上降低跨部門協作難度

案例分析

金融機構前端業務的常見痛點是上線慢，如果涉及與合作方對接，經常需要三個月甚至半年時間。宣導時可以著重表述，通過需求的梳理、優先級的排序，高質量快速交付合作項目的核心內容，幫助業務快速抓住市場熱點與趨勢，輔助業務快速落地。

但是，在宣導過程中，應該注意避免以下幾個坑：

單純將敏捷描述為研發能夠快速交付；

將敏捷描述為研發的實踐，沒有事先與業務對齊參與敏捷的「投入」與「產出」。

如何理解敏捷的投入與產出

常見的投入包括：頻繁的需求澄清、定期與研發集中辦公（尤其針對業務研發不在一個職場的情況）、小批量驗收測試等。更進一步的實踐中，需要將業務目標與產品規劃、需求管理進行關聯和掛鉤。

常見的產出包括：支持快速實驗、交付內容更符合業務訴求，交付質量提升等

Q2：項目制中，項目經理的管理能力較弱，同時疲于應對向上匯報，雖然有團隊內敏捷教練，但是本身不關注也不了解敏捷，對敏捷轉型中形成阻力，如何優化？

A2：不過分糾結「某一小部分」的問題，將大部分精力投入規模化。（By 周麟）

在面向組織做轉型的過程中，天然的存在人員能力的差異與不同態度問題。首先，本著轉型的長期目標與短期要解決的問題為主，不要過于糾結為某一小部分人員的執行程度。

從個人經驗，分享幾個導入的小 Tips:

找到著力點：多觀察，總能抓到幾個對轉型有支持態度的人，以及有一定影響力的人，這些人的引導非常重要，要多花些心思；

樹立標桿：組織的轉型道路長遠，困難重重，先挑選與輔導出一兩個標桿團隊，說明我們真的是可以做得到的；

擴大影響力：有了標桿團隊后可以到領導面前拉拉票，借取更大的力量，逐漸規模化；

個別邊緣化：在一定規模化后，仍然會有一些反對的聲音。要注意，不管理無理由的反對，還是個別能力問題執行不到位，對于我們導入來說，大部分精力應投入在規模化。個別的人可以先放一放，因為很多人不一定想得第一，但非常害怕到掉隊到最后，形成邊緣化。當然，若反對的聲音是客觀存在的問題，我們應該認真溝通與引導，持續優化改進。

Q3：傳統到敏捷的轉型階段問題

A3：這個問題很大，這里推薦敏捷流暢度模型，在 Adapt 中，也有轉型路徑可參考。（By 程萃）

Q4：一個現有的研發小隊，讓他們做敏捷轉型，在宣導敏捷思維時，應該著重宣導哪些方面，才能讓他們感覺到敏捷轉型會給他們帶來收益？

A4：先問題驅動，讓研發小隊成員知道敏捷是什么，能給他們帶來什么幫助，目前管理方式的痛點又是什么。（By 徐哲&李黃容）

從具體問題出發，去了解研發小隊真正的痛點是什么。比如敏捷轉型后，覺得工作節奏更快。或者交付質量沒有帶來質變，業務滿意度還是不高。我們可通過先透明團隊工作來幫助團隊發現問題和痛點。

敏捷更強調的是小批量交付業務價值，盡快獲取市場用戶的反饋，及時調整、持續改進，形成自我優化的閉環。

敏捷轉型是一個長期積累的過程，是一種工作模式的優化。對研發小隊成員本身來說，持續交付高價值的需求，也是提升成就感、獲得感和實現自我價值的過程。

同樣，我們敏捷導入可從「多快好贊」的角度出發，量化交付成果，比如需求產能的提升，需求交付時效的提升，缺陷率的降低，業務滿意度的提升。通過提升，來逐步提升研發小隊成員的士氣和業務方的參與程度及信心，來促進更大范圍、更大深度的改進。

2

外部資源的協作與管理

Q1：合作方人員分布資源匹配，是匹配到每個項目里面的人數么？如果不是的話，告知下是匹配到哪個維度里面？

A1：資源管理不應割裂，幾個維度推薦（By 李黃容&徐哲）

基于組織自身運作需求，有些組織會整合外部專業化資源，此時即會涉及內部自有人力和外部合作人力。

人員管理是整體的，從組織層級來看，內外部人力資源的整合分布信息對管理層來說一樣重要。

觀察：內部人力情況的黑盒

我們觀察到，很多組織不僅外部合作人力情況是黑盒的，甚至內部自有人力情況也是不透明的，或對領導管理層非實時可見。基于本問題來說，不同組織對人力資源分布的統計信息，期望看到的維度可能會有所差異，建議先從最關注和最易獲得的維度入手，再持續迭代。

此時，我們可以在人員上有一些崗位標簽，比如角色、小隊、部落、職能線、公司、專業領域、產品、項目等等。科技類工作需要更細化、靈活可變的崗位標簽體系，以支持實時人力盤點和人才畫像。

同時，結合 Adapt 三層需求分解體系（下圖），個人任務落到單個人，可關聯到更細的顆粒度，通過工時向上匯集到個人任務關聯的需求/系統任務，展現不同需求和任務的人力投入。

有了如上基礎原始信息之后，可以單維度或多維度的進行統計，獲取全組織關注維度的人力分布地圖，建立人員效能評估的數字化管理體系，幫助管理層更好地進行資源分配和整合管理，并有針對性地提升各團隊的交付能力。

補充一個例子，根據人員的公司歸屬信息，可單維度統計出各公司人員分布；根據人員的公司歸屬和項目信息，可多維度統計出各公司在各項目的人員分布，或各項目中各公司的人員分布：

Q2：對于合作方的資源和項目串聯進行管理，衡量合作方人員的交付速率，可以建議些方法么？

A2：先聚焦關注業務/用戶認同并有感知的維度，多個交付指標推薦（By 李黃容&徐哲）

本問題基于項目團隊且含合作方人員，分兩種情況：

• 研發團隊由自有人員和合作方人員共同組成

• 完全是合作方人員

無論是哪種情況，我們建議應首先從團隊整體出發，聚焦關注業務/用戶認同并有感知的度量維度，當團隊超過一定規模，團隊自身亦需分層級精細化管理和度量，持續過程改進。

就團隊交付速率的核心指標，可計算團隊單位周期的需求交付量或單位周期人均的需求交付量，如月度人均需求吞吐量，經過一段時間觀察趨勢，建立基線數據后，可設定階段性改進的目標值。

這里的目標值，更多為相對值，而非絕對值，更多為縱向比較，而非橫向比較，即更多關注該團隊本身或項目整體的交付速率在單位周期內的改進情況和變化趨勢。具體可參考上圖 Adapt 「多快好贊」度量體系。

Q3：在敏捷大規模交付中，多家廠商如何管理？

A3：理解該問題最主要的點，是傳統向敏捷轉型時，對合作供應商管理的變化點。（By 李黃容&徐哲）

多家廠商管理，傳統或敏捷交付中都會有涉及，以下從采購和外部合作人員管理兩點進行說明：

1. 采購轉向人力外包，時間投入和工作項關聯

傳統采購更多的是以項目外包的形式，與供應商進行談判合作，固定范圍、成本、時間。

在不確定性的環境背景下，項目外包的采購方式難以滿足目標的實現，因此采取敏捷的方式來應對，建議轉向人力外包的形式，通過對外包人員的工時管理，將人員時間投入與工作項進行關聯，促進整體資源更合理的分配，最終實現目標驅動，甲乙雙方合作共贏，采購按目標達成進行滾動驗收的工料合同。

2. 盡量避免差異對待

我們觀察到，團隊中外部合作人員的管理方式，一方面，在很多組織依然存在說「我是內部人員，你是外包」的現象，十分不利于團隊合作。

正如敏捷宣言所說「客戶合作高于合同談判」，因此團隊管理者應避免造成諸如此類的差異對待，無論來自哪家公司，都應強調我們是一個團隊，讓團隊成員有歸屬感，共同朝著統一的目標，促進甲乙方共創的敏捷交付。

另一方面，通常外部合作人員會涉及結算，此時的確需一定的約束，如遵守內部的行政管理要求，對供應商服務人員有面試選擇權利，人員的考勤和工時管理，團隊管理者對內外部團隊成員的績效考核等。

3

跨系統跨小隊協同

Q1：受到后臺系統進度影響，速度快不起來怎么辦 ？

A1：分兩種情況來分析找答案（By 郭陽）

這個問題分幾種情況：

第一種，經常性的被后臺進度慢影響。看看這幾個方面是不是出現了問題：

• 事先排期的時候沒有做足準備，沒有提前把需要后臺做的部分講清楚，約定好聯調和上線時間。注意，此處需要后臺去明確優先級，確定這個任務被放到了他們的高優先級去做。

• 事中沒有定期（根據重要程度和情況調整頻率）與后臺做進度跟蹤。

第二種，不是經常性的。任務已經在研發中，計劃做的沒問題，溝通也沒問題，那應該是有未預測到的技術難題。此時應該及時升級給大領導協調資源攻克難題，把失去的時間搶回來。

Q2：規模級，如信貸、核心、國結、票據、支付等，幾十個同時交付中，如何評估項目交付時間，制定版本計劃，應對需求變更，做到按預定時間上線。?

A2：三種風險管理方式推薦（By 熊小龍）

• 約定交付時間：應該先有時間窗，明確交付日期。這類似 Adapt 中的版本日歷（下圖）。

• 制定最小可交付范圍：根據項目的交付目標，各團隊評估能完成多少功能，尋找到最小可交付的平衡點。

• 依賴管理：迭代中，有依賴關系的盡早約定好接口，明確聯調時間點，保障交付可控。

• 同步機制：項目周例會機制，同步進展和風險，需求變更等。

通過以上方式，一般能盡早暴露風險，使風險得到有效管理。

Q3：跨部落對齊，或者同一部落內各小隊間的具體優秀實踐是哪些？

A3：該問題的實踐分享（By 郭陽）

• 制定定期的溝通對齊會議計劃。會前準備會上需要討論的問題，發給所有參會人員并注明需要誰重點關注。會上產生行動項，記錄下來并持續跟蹤。

• 跨部落對齊部分，可以參考即將發布的Adapt3.0跨部落協作部分

• 小隊間的溝通要運用好公司內部的即時信息軟件、郵件，做頻繁的對齊。必要的時候升級給部落級角色進行協調。

• 心法：不要怕麻煩，不要覺得這個事會有別人處理。

Q4：各個系統的關聯性、耦合度太高，可以是說是錯綜復雜，該如何做到版本節奏的統一？

A4：先統一小隊迭代周期，版本與迭代解耦（By 周麟）

在 Adapt 中，版本與迭代是解耦的。版本節奏是各系統的投產節奏，迭代是各小隊各系統的研發與測試計劃。

版本節奏統一，可以根據實際情況來看遇到的問題來對癥下藥，是擔心執行不到位，還是有某些系統的客觀因素，等等。

題干上提到系統的關聯性與耦合度高，更多是要解決版本節奏不一致的情況下，多系統協同問題。建議先統一小隊的迭代周期（例如兩周），這樣哪怕各小隊的迭代起始時間不同，也不會存在過長的時間差。根據需求的期望上線時間，定期的提前與關聯小隊做迭代計劃便可。

4

關于人的問題

Q1：團隊測試人員每個版本都有不同怎么辦？

A1：三個固定（By 熊小龍）

優先固定：首先思考為什么會不同，如何增加固定。無論開發還是測試，是需要領域知識的，人員高度復用并不能提高效率，僅是看上去提高了利用率。

相對固定：如果推動力不足，可以考慮核心人員固定，核心人員保障知識傳承、案例設計，變動人員主要做測試執行相關工作。

領域固定：在某個小領域內的人員復用，讓測試人員漸漸掌握2-3個小隊的業務知識。

Q2：如何培養團隊骨干？

A2：內驅力輔助，激發和引導工作分配。（By 周麟）

團隊的骨干培養可以通過內驅力來輔助，管理 3.0 里將內驅力分為 10 種類型（好奇、榮譽、認可、能力、權力、自由、關系、有序、目的、地位）。

通過人員的內驅力不斷的去激發和引導工作的分配。同時，根據各人員的角色與崗位不同，應制定不同的培養路線。有對人員本身的培訓賦能輸入，也給予實踐的機會和空間，不斷的引導與反饋，激發其學習成長動力。

Q3：團隊規模太大怎么辦？

A3：化繁為簡，降維管理。（By 熊小龍）

可以嘗試把大團隊用虛擬部落制的方式，細化到小隊。部落與業務對齊，小隊與產品經理對齊，本質上管理復雜度就限定在一個細分的業務領域了。使組織從千人級的管理，降維到一百人左右的管理維度。

5

關于需求拆分

Q1：市場變化快，業務壓力大，要求 IT 要更快響應，例如兩三天上線，但是需求一句話，交付質量差，可是業務和 IT 不敢停，如何化解？

A1：關鍵詞：價值優選、優先級置換、產品經理輔導（By 徐哲&李黃容）

首先，需要將一些當前優先級較低的，正在研發階段前期中的需求挑選出來，置換為高優先級的業務需求，盡快啟動需求澄清、排期、研發、驗收、上線。

其次，輔導產品經理的能力提升，將業務負責人的一句話需求明確驗收條件和完成標準，同時分析關聯系統的影響，避免關聯方未及時配合修改，導致需求最終無法上線。從源頭開始，也就是需求本身開始，加強需求質量。

再次，業務和產品加強價值優選環節，保證輸出給研發團隊的迭代需求列表，是當前時點業務最高價值的；同時，團隊規劃時建議納入迭代系統任務的總估算不超過團隊容量的 80% （具體數值也可根據團隊實際情況而定），保留 20% 作為 buffer 或排優先級較低的，以及時響應變更。

Q2：需求顆粒度和系統任務的拆分，如何在實踐過程中做好衡量和規范？

A2：盡量拆小，顆粒度相對統一即可。（By 徐哲&李黃容）

需求顆粒度一般拆分到產品經理和小隊長可以溝通對齊，讓小隊長理解的程度，滿足INVEST原則（獨立的、可溝通的、有價值的、可估算的、足夠小的、可測試的）。

需求顆粒度沒有絕對，盡量拆小，保持顆粒度的相對統一即可。然后再根據需求分析的結果，去完成系統任務拆分，系統任務的工作量要求小于10人天，否則就很難在一個迭代內完成系統任務的交付。

6

度量與績效

Q1：實行敏捷之后，怎么樣配套的去做績效管理？

A1：不建議直接將度量體系搭建剛開始，即用作績效考核。（By 李黃容）

指標的選定也需要試點和正式推廣，度量的主要目的是幫助團隊用于過程改進。穩定后如需利用研發效能數據可參考上圖的建議。

7

關于知微的問題

Q1：知微是否可實現項目WBS管理，看項目進度燃盡？

A1：藉由靈活的卡片類型和關聯配置能力，知微可實現項目的拆分（項目群-項目，項目-任務等）管理和進度燃盡監視。（By 知微產品團隊）

一方面，列表甘特圖實現對項目/任務進展與風險的監控，綠色線代表進度正常，紅色線代表進度異常/有延期風險；

另一方面，通過統計視圖，可監視一/多個項目進度燃盡情況。下圖為按照項目分解后的任務事項，監視兩個項目的燃盡圖，時間刻度可以指定按天/周/月等。

類似進度燃盡功能，不止是項目管理，同樣適用于版本、迭代、缺陷修復等場景。

8

Adapt 的應用

Q1：在 Adapt 框架運行中，如何自組織管理？

A1：先進行「5+3」角色與迭代節奏&版本設定。（By 都云霞）

在進行了部落長、小隊長、小隊人員開發、測試等角色配置之后，對迭代節奏、版本也有了設定，則可以讓團隊基于迭代節奏、版本進行自組織管理，去進行 Adapt 里面定義的活動。

或者說，如何開展、什么角色都在 Adapt 里面進行詳細說明后，團隊可以在小隊長主持下召開站會、也可以根據團隊情況安排版本排期、需求澄清等，這些都是自組織管理的。

Q2：Adapt 框架目前主要針對的企業開通服務及其應用，有沒有考慮針對某企業下小 team，比如一個項目組使用這種模式來管理，其他 team 仍遵循原有的管理模式。

A2：Adapt是規模化敏捷框架，其中也包含部落內單小隊的運作規范。（By 郭陽）

如果目前企業內無法支持部落化，那么單個小 team 是可以參照 Adapt 中小隊運行方式及產品經理和小隊長的職責來進行改進的。

補充說明1：在 Agilean 公眾號內回復「直播」，可查看Adapt 本系列直播全部回放，以及直播 PPT 下載；

補充說明2：點擊「閱讀原文」，查看第七期直播回放。

總結

以上是生活随笔為你收集整理的规模化敏捷转型中，哪些问题会被经常问到？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。