我曾在一個使用了Nexus框架和規模化Scrum的項目上工作。一個Nexus被視為規模化Scrum中的開發單位，形成人與人之間的關聯或聯繫。軟件開發本身就是一個困難的任務，當多個團隊正在開發同一產品，並且有許多相依性時，這項任務變得更加困難。除了要面對各種角色，文物和事件，我在日常工作中遇到了三大挑戰：

1. 唯一產品擁有者和Nexus衝刺規劃 - 根據Scrum指南，最終的決策權屬於一個單一的產品擁有者。多個團隊在Nexus衝刺規劃後進行自己的衝刺規劃。這使得產品擁有者在每個團隊的規劃中參與，如果他們同時進行，會面臨挑戰。產品擁有者不能在同一時間回答關於領域知識的問題，或為多個團隊做優先決定。如果會議時間不同步，產品擁有者就會浪費很多時間。此外，像Scrum Master，資深架構師或設計師等資源可能需要在不同的團隊之間共享。有些組織甚至設計一組產品擁有者，使決策變得複雜，因為沒有人對規模化產品具有絕對權威。

2. 將產品待辦事項清單精煉可視化的挑戰 - 可能出現新的依賴性，需要識別並盡量減少。不幸的是，像JIRA和Trello這樣的工具並未提供簡單的方式以視覺化這些依賴性的進度或解決方法。Scrum Master可能無法充分理解複雜的技術含義，因此難以有效管理依賴性。

3. 通過速度的角度審核Nexus Sprint - 整合工作是不可避免的，可能會影響團隊的速度。由於每個團隊都有自己的估計基準和議程，因此不清楚誰應該對重疊的工作負責。像設定伺服器、自動化測試和解決git代碼合併問題等耗時的整合任務都至關重要，但可能會拖慢團隊的進展。這些任務可能不在故事點數中完全列入，並可能在高級管理層看到速度下降時產生誤解。此外，即使每個團隊根據完成定義完成他們的故事，但在實證世界中的後期整合可能會引入新的問題，需要進行額外的跨團隊討論。

Nexus整合團隊的思維模式是答案 - 管理軟體開發的複雜性和不可預測性的最重要因素是具有正確的思維模式。會議、工具和共享工作只是更基本挑戰的症狀：讓團隊中的每一個人，包括組織領導者，理解並擁抱敏捷性。

你以前是否在規模化Scrum環境中工作過，比如SAFe或LeSS？歡迎你的評論，並期待從你的經驗中學習。