共用方式為


實施具擴展性的敏捷實踐

Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

企業組織基於許多原因採用敏捷式做法。 這些原因的主要原因包括:

  • 縮短上市時間並加速產品交付
  • 改善組織效率以管理變更的優先順序
  • 增強軟體品質和傳遞可預測性
  • 改善項目可見性並降低項目風險

隨著組織的發展,您想要擴展您的實踐以保持敏捷並滿足不斷變化的目標。 若要這樣做,請考慮這兩個指導原則:

  • 成功對您、您的小組和組織有何外觀 ? 您最感興趣的是什麼:準時交貨? 產品品質? 可預見性? 客戶滿意度?
  • 回歸第一原則 ,回歸敏捷 宣言 中列舉的原則和共同價值觀正如 Scrum 創始人之一 Ken Schwaber 所指出的:
    • 「價值和原則能夠擴展,但做法會因應不同情境。」
    • “保持價值觀,堅持原則,自己思考。 敏捷式的核心前提是,執行工作的人員是最能弄清楚該怎麼做的人。

創造節奏感和流暢感

藉由採用共享頻率和一組定期通訊,您會在整個組織中建立持續的活動流程。 有助於在大型組織內建立節奏和流程的作法包括:

  • 統一節奏定期的開發衝刺和發佈建立業務的節奏。 讓所有小組都能以共用的步調來協助進行所有協調和共同作業活動。
  • 衝刺通訊:為了讓組織和所有團隊了解功能團隊的進度和計劃,每個功能團隊都可以透過 Microsoft Teams、Slack 或電子郵件等數位管道分享其先前的衝刺結果和當前衝刺計劃的摘要。
  • 衝刺演示和視頻: 創建快速的 2 到 3 分鐘視頻,展示團隊製作的新功能。 在衝刺通訊或團隊頻道中分享此類影片的連結。
  • 展示會議: 為了通知其他團隊並詢問有關正在開發的軟件的反饋,團隊展示了他們完成的工作。 在整個專案生命週期中定期進行這些會議,並將其開放給所有感興趣的各方。
  • 品質指標儀表板:為了深入了解產品品質並鼓勵維持錯誤管理,請定期與組織分享品質指標。 這些指標可能包括每個功能團隊的作用中錯誤、錯誤趨勢、測試涵蓋範圍和缺陷逸出率。
  • 協調會議和儀式:定期舉行會議,或根據需要經常召開協調團隊的會議,以解決重疊的目標、依賴關係和風險。 考慮實施 Scrum of Scrum 或計劃增量 (PI) 規劃會議。

與客戶互動

在整個產品生命週期中吸引客戶的是主要敏捷性原則。 讓每個小組都能在他們所擁有的功能集上直接與客戶互動。

  • 持續的回饋循環:建立客戶回饋機制。 這些循環可以採用許多形式:
    • 客戶語音平台: 通過專用門戶、社區論壇或集成反饋系統,讓客戶輕鬆提供反饋、添加想法並對下一代功能進行投票。
    • 產品內反饋: 實施產品內反饋按鈕和遙測,以收集有關產品體驗和特定功能的見解。
    • 客戶演示和用戶測試: 安排定期演示,要求客戶反饋並進行可用性測試會議,以幫助塑造下一代產品,並讓您按計劃構建客戶想要使用的應用程序。
  • 早期採用者和測試版計劃:開發計劃的想法是所有團隊都可能希望在某個時候參與。 早期採用者可以存取工作軟體的早期版本並提供有價值的回饋。 通常,這些程式的工作原理是為早期使用者清單啟用選擇的功能旗幟。
  • 數據驅動的決策: 尋找檢測產品的方法,以獲取有用的數據並測試各種假設。 推動一種實驗友好的文化,慶祝學習和基於證據的決策。

改善項目可見性

您和您的團隊對正在完成的工作的目標、願景和進度的洞察越多,您就越能更好地降低風險並管理依賴關係。

  • 團隊結構:無論您的組織規模有多大,圍繞 6 到 9 人的小型團隊構建您的組織都可以有效地擴展。 建立 以組合管理區域分組的垂直自主功能小組
  • 工作分解結構:將大型目標、功能或需求分解為較小的目標、功能或需求仍然是專案管理的主要內容。 藉由將工作細分為類似大小的工作,小組可以做出更佳的估計,並識別風險和相依性。
  • 整合視圖和儀表板: 使用您的在線追蹤工具聚合工作並獲取跨團隊的知識。 建置即時儀錶板,以使用 Azure DevOps Analytics 服務顯示進度、趨勢和關鍵績效指標。
  • 體驗和設計檢閱:在功能開發開始之前召開這些會議,以教育領導層有關案例和優先順序、收集意見反應、設定期望,以及顯示有關該功能的任何跨團隊問題。

提高生產力員工的能力

可擴展良好並帶來更快樂、更敬業和更有生產力的員工的特定敏捷實踐包括:

  • 嵌入式領導力和心理安全感:授權組織內的團隊和領導者盡可能地自我組織和自我管理。 團隊自主性提高了組織敏捷性和團隊效率。 確保團隊獲得成功所需的企業贊助,並創造讓團隊成員可以安全地表達想法和擔憂的環境。
  • 每日站立會議:Scrum 會議有助於讓團隊專注於每天需要完成的任務,以最大化提升他們實現衝刺承諾的能力。 隨著組織成長,他們應該考慮交錯這些會議,以便視需要進行跨小組參與。
  • Scrum of Scrum:來自不同敏捷團隊的代表定期開會,報告已完成的工作、後續步驟以及團隊內發生的問題或障礙。
  • 團隊溝通和知識共享:提供並鼓勵團隊通過企業網絡分享他們的實踐和指導。 常見的工具包括小組 Wiki、Microsoft Teams、Confluence 或 Azure DevOps Wiki。
  • 協作和程式碼品質:鼓勵非正式的團隊對團隊溝通和協作。 將程式碼審查、設計審查、結對程式設計和團體程式設計等實踐制度化。 這些做法不僅增強了團隊協作,還有助於培養個人和整體企業能力。

改善組織文化

您可以藉由參與您想要建立的文化來提升組織效率。 當個人、小組和組織採用一或多個持續改進做法時,就會發生文化變更。 數個可調整的敏捷式做法包括:

  • 回顧:提出諸如「哪些方面進展順利」、「我們應該採取哪些不同做法?」和「我們應該停止哪些做法」等問題,以幫助團隊反思如何改進流程和實踐。 回顧可協助團隊找出哪些內容運作良好,哪些內容需要改進。 您可以隨時隨地進行回顧。 然而,定期將某些回顧制度化有助於建立持續改進實踐。 例如:

  • 改進跟踪板:任何人都可以隨時提出改進流程的好主意。 捕捉這些想法以討論並決定如何快速採取行動,有助於流程改進工作。

    白板提供了一種簡單且直觀的方式來捕捉想法。 此外,您可以建立改進追蹤小組,並擷取您在電子 面板上追蹤的想法。

  • 分享和學習制度化:分享最佳實踐和交流想法有助於組織內的所有團隊成長和改進。 發展學習文化支持這項活動和其他持續改進活動。 考慮以下想法:

    • 內部 wiki 和知識庫

    • 實踐社區和公會

    • 黑客馬拉松週或創新時間

    • 內部 DevOps 和敏捷輔導團隊,以支援採用這些做法的團隊

    • 定期午餐和學習課程

    • 內部會議和技術講座

      文化遊戲 為敏捷經理提供了很好的資源,幫助團隊採用敏捷實踐並分享最佳實踐。

  • 實務社群:支援內部通用學科 (例如,網站可靠性工程師、軟體架構師、UX 設計師、資料科學家和安全性專家)

工作軟體

「經常交付可運作的軟體,從幾周到幾個月,以較短的時幅為優先。」
「工作軟體是進度的主要量值。」
- 敏捷宣言

隨著軟體數量、功能和複雜性的增加,您需要採用可協助您產生消耗性解決方案的做法。

  • 功能標誌和漸進式交付: 使用功能標誌安全地啟用或禁用對不同功能的訪問。 支持為早期採用者開啟功能以獲得工作反饋。 實作漸進交付模式,例如金絲雀發布和藍綠部署。
  • 發行訓練和持續傳遞:提供另一種類型的步調來傳遞一或多個功能。 功能團隊了解推出新功能的預先計劃時間表並相應地進行計劃。 發佈列車可以對應至為組織建立的相同衝刺節奏,或以不同的節奏進行。 如需如何設定短期衝刺和發行訓練,請參閱 Scaled Agile Framework
  • 持續整合和持續部署 (CI/CD):採用自動化流程,消除手動工作,並在測試、建置和部署週期中自動化軟體流程。 實施全面的測試策略,包括單元測試、整合測試和自動驗收測試。
  • 內部原始碼和開放開發:將開源軟體社群中開發的價值和精神帶給您的內部開發團隊。 鼓勵跨團隊的程式碼共用、文件和協作開發實踐。
  • 雲端原生實踐:採用容器化、微服務架構和雲端原生部署模式,以提高可擴展性和可維護性。

現代實踐和考慮因素

隨著敏捷實踐的發展,請考慮以下其他現代方法:

  • DevSecOps 整合: 在整個開發生命週期中整合安全實踐,而不是將安全視為單獨的關注點。
  • 站點可靠性工程 (SRE):採用 SRE 實踐來提高系統可靠性並減少運營開銷。
  • 價值流映射:映射並優化從構想到客戶交付的價值流。
  • OKR(目標和關鍵結果):使用 OKR 圍繞可衡量的結果而不僅僅是輸出來調整團隊。
  • 設計思維:結合以人為本的設計方法,以更好地理解客戶需求。

除了上述做法之外,您還可以在下列文章中找到有關調整敏捷工具的更多指引:

產業資源

不具擴展性的做法

  • 估算大型計劃:瀑布專案方法的一部分涉及估算資源和排程。 舉措越大,這些估計提供任何價值的可能性就越小。 隨著項目的增長,可能會引發風險和未預見的問題和障礙,使許多估計值失效。
  • 速度作為跨團隊計量:雖然 團隊速度 可以提供有用的計量,以深入瞭解每個團隊在短期衝刺週期中可以完成多少工作,但您無法新增團隊速度來取得有意義或有用的計量。 此外,使用從許多團隊獲得的速度來可靠地完成長期預測也是有問題的。 團隊估計工作的方式可能會有所不同,而且這些差異會隨著時間的推移而增加。
  • 由上而下的規範性解決方案:一種尺寸並不適合所有人,一個解決方案通常也不適合所有團隊。 支持團隊自主意味著讓團隊找到自己的解決方案,同時提供必要的框架和支持。
  • 貨運崇拜敏捷:簡單地採用敏捷儀式而不了解其目的或使其適應您的環境通常會導致無效的實施。