共用方式為

實作調整的敏捷式做法

  • 發行項

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

隨著組織成長，您會想要調整做法，以保持敏捷並符合不斷變化的目標。 若要這樣做，請考慮這兩個指導原則：

  • 成功對您、您的小組和組織有何外觀 ？ 最感興趣的是：準時傳遞？ 產品品質？ 可預見性？ 客戶滿意度？
  • 返回第一個原則，回到敏捷式宣言中所列舉的原則和共用值，如 Scrum 的創始人之一 Ken Schwaber 所指出：
    • 「值和原則規模調整，但做法會區分內容。
    • “保持價值觀，保持原則，為自己思考。 敏捷式的核心前提是，執行工作的人員是最能弄清楚該怎麼做的人。

建立節奏和流程

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

  • 共用節奏： 定期衝刺和發行 會建立業務的節奏。 讓所有小組都能以共用的步調來協助進行所有協調和共同作業活動。
  • 短期衝刺電子郵件：為了讓組織和所有小組知道功能小組的進度和計劃，每個功能小組都可以傳送其先前短期衝刺結果和目前短期衝刺計劃的摘要電子郵件。
  • 短期衝刺示範：快速-2 到 3 分鐘的影片，說明小組所產生的新功能。 這類影片的連結可以包含在短期衝刺電子郵件中。
  • 展示會議：若要通知其他小組並詢問有關軟體開發的意見反應，小組會展示他們所做的工作。 在整個專案生命週期中定期進行這些會議，並將其開放給所有感興趣的各方。
  • 錯誤摘要電子郵件：若要支援對產品品質的深入解析，並鼓勵維護 Bug 專業領域，請定期與組織共用品質計量。 這些計量可能包括每個功能小組的作用中 Bug、Bug 趨勢，以及每個工程師的錯誤。
  • 協調會議：定期或視需要舉辦協調小組的會議，以解決重疊的目標、相依性和風險。

與客戶互動

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

  • 持續意見反應：在客戶意見反應迴圈中建置。 這些循環可以採用許多形式：
    • 客戶語音：讓客戶輕鬆提供意見反應、新增想法，以及投票處理下一代功能。 提供意見反應通常是透過專用網站來完成。
    • 產品意見反應：產品內意見反應按鈕是詢問產品體驗或特定功能意見反應的另一種方式。
    • 客戶示範：定期排程的示範，詢問客戶的意見反應，可協助塑造下一代產品，並持續追蹤建置客戶想要取用的應用程式。
  • 早期採用者計劃：這類計劃應該以所有小組可能想要參與為某個點的想法來開發。 早期採用者可以存取舊版的工作軟體，然後他們可以提供意見反應。 通常，這些程序的運作方式是開啟早期採用者清單的選取 功能旗標 。
  • 數據驅動決策：尋找檢測產品以取得實用數據的方法，並測試各種假設。 協助推動一種慶祝學習的實驗友好文化。

改善項目可見性

您和小組對於完成工作的目標、願景和進度有了更深入的見解，您就越能夠降低風險及管理相依性。

  • 小組結構：無論您的組織有多大，都以 6 到 9 個規模的小小組來建構您的組織。 建立 以組合管理區域分組的垂直自主功能小組 。
  • 工作分解結構：將大型目標、功能或需求細分為較小的目標，仍然是專案管理的穩定。 藉由將工作細分為類似大小的工作，小組可以做出更佳的估計，並識別風險和相依性。
  • 合併檢視：使用您的在線追蹤工具來匯總工作，以取得跨小組的知識。 建置儀錶板以顯示進度和趨勢。
  • 體驗檢閱：這些會議會在開發開始之前就功能開始舉行，可用來教育領導人員案例和優先順序、收集意見反應、設定期望，以及顯示功能的任何跨小組問題。

提高生產力員工的能力

一些可妥善調整並導致更快樂、參與且具生產力的員工的特定敏捷式做法包括：

  • 內嵌領導：讓組織內的小組和領導者盡可能自我組織及自我管理。 小組自主性會增加組織靈活度小組的有效性。 確保小組擁有成功所需的公司贊助。
  • 每日對峙：或者， Scrum 會議 有助於讓小組專注於他們每天需要做什麼，以充分發揮他們滿足衝刺承諾的能力。 隨著組織成長，他們應該考慮交錯這些會議，以便視需要進行跨小組參與。
  • Scrum 的 Scrum：來自不同敏捷式小組的成員每日會晤，報告工作已完成、後續步驟，以及代表小組內發生的問題或區塊。
  • 小組通訊：提供並鼓勵小組分享其做法和指引，他們和其他小組可以透過公司網路存取。 用於此用途的常見工具包括小組Wiki、OneNotes或 Markdown 網站。
  • 共同作業：鼓勵小組內部的非正式小組對小組通訊和共同作業。 將程式代碼檢閱、設計檢閱、規格檢閱等做法制度化，不僅會增加小組共同作業，還能協助開發個人和整體公司能力。

改善組織文化

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

  • 回顧：通過問：「什麼進展順利？」、「我們應該以什麼不同方式做什麼？」和「我們應該停止做什麼？」等問題，協助小組反思他們如何改善其流程和做法。 回顧可協助小組瞭解哪些工作良好，以及需要改進的內容。 回顧可以隨時隨地進行。 然而，定期將某些回顧制度化有助於使持續改進做法制度化。 例如：

  • 改進追蹤面板：改善流程的好主意隨時都可能來自任何一個程式。 擷取這些想法來討論並決定如何快速處理這些想法，是支援程序改進工作的關鍵。

    白板提供任何簡單和視覺的方式，以擷取想法。 此外，您可以建立改進追蹤小組，並擷取您在電子 工作流程看板上追蹤的想法。

  • 制度化共享：共用最佳做法和溝通想法可協助組織內的所有小組成長和改善。 開發學習文化是支援這項和其他持續改進活動的關鍵。 要考慮的一些想法：

    • 內部Wikis

    • 內部通訊組清單

    • Hackathon 周或 10% 駭客時間

    • 內部敏捷式支援小組，以支持採用敏捷式作法的小組

      文化遊戲 為敏捷式管理員提供良好的資源，可協助小組採用敏捷式並分享最佳做法。

  • 實務社群：支持內部通用專業領域（例如 DBA、SW 架構師、UX 設計）

工作軟體

「經常提供工作軟體，從幾周到幾個月，更傾向於較短的時幅。
「工作軟體是進度的主要量值。」
- 敏捷式指令清單

隨著軟體、功能和複雜性的增加，您必須採用可協助您產生消費性解決方案的做法。

  • 功能旗標：使用功能旗標來啟用或停用對不同功能的存取。 提供對早期採用者開啟功能的支援，以取得工作意見反應。
  • 發行訓練：提供另一種類型的步調來提供一或多個功能。 功能小組瞭解預先規劃的推播新功能排程，並正確規劃。 發行列車可以對應到為組織建立的相同衝刺頻率，或以不同的步調發生。 如需如何設定短期衝刺和發行訓練，請參閱 調整敏捷式架構 。
  • 持續整合：採用可消除手動工作的程式，並改為透過測試、建置和部署週期自動執行軟體流程。
  • 內部開放原始碼：將開放原始碼軟體社群中開發的價值和精神帶到您的內部開發小組。

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

產業資源

不調整的做法

  • 估計大型計劃：參與估計資源和排程的瀑布專案方法的一部分。 舉措越大，這些估計值的可能性就越小。 隨著項目的增長，可能會引發風險和未預見的問題和障礙，使許多估計值失效。
  • 速度：雖然小組速度可以提供有用的計量，讓您深入瞭解每個小組在短期衝刺週期內完成的工作量，但您無法新增小組速度來取得有意義的或有用的計量。 此外，使用從許多小組獲得的速度可靠地完成遠程預測是有問題的。 Teams 會因預估工作的方式而有所不同，且這些變化會隨著時間而增加。
  • 由上而下的解決方案：一個大小不適合全部，而一個解決方案通常不適合所有小組。 支援小組自主性表示讓小組找到自己的解決方案。