Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
企業組織基於許多原因採用敏捷式做法。 這些原因的主要原因包括：
- 縮短上市時間，加速產品交付
- 改善組織效率以管理變更的優先順序
- 增強軟體品質和傳遞可預測性
- 改善項目可見性並降低項目風險
隨著組織成長，您會想要調整做法，以保持敏捷並符合不斷變化的目標。 若要這樣做，請考慮這兩個指導原則：
- 成功對您、您的小組和組織有何外觀 ？ 最感興趣的是：準時交貨？ 產品品質？ 可預見性？ 客戶滿意度？
-
返回第一個原則，回到敏捷式宣言中所列舉的原則和共用值，如 Scrum 的創始人之一 Ken Schwaber 所指出：
- 「價值和原則能夠擴展，但做法會因應不同情境。」
- “保持價值觀，保持原則，為自己思考。 敏捷式的核心前提是，執行工作的人員是最能弄清楚該怎麼做的人。
創造節奏感和流暢感
藉由採用共享頻率和一組定期通訊，您會在整個組織中建立持續的活動流程。 有助於在大型組織內建立節奏和流程的作法包括：
- 統一節奏：定期的開發衝刺和發佈建立業務的節奏。 讓所有小組都能以共用的步調來協助進行所有協調和共同作業活動。
- 短期衝刺電子郵件：為了讓組織和所有小組知道功能小組的進度和計劃，每個功能小組都可以傳送其先前短期衝刺結果和目前短期衝刺計劃的摘要電子郵件。
- Sprint 迭代示範：一段快速而精緻，長度為 2 到 3 分鐘的影片，說明團隊所產生的新功能。 這類影片的連結可以包含在短期衝刺電子郵件中。
- 展示會議：若要通知其他小組並詢問有關軟體開發的意見反應，小組會展示他們所做的工作。 在整個專案生命週期中定期進行這些會議，並將其開放給所有感興趣的各方。
- Bug摘要電子郵件：為了支援對產品品質的深入了解並鼓勵維持Bug紀律，請定期與組織分享品質指標。 這些計量可能包括每個功能小組的未解決錯誤、錯誤趨勢，以及每個工程師的錯誤。
- 協調會議：定期或視需要舉辦協調小組的會議，以解決重疊的目標、相依性和風險。
與客戶互動
在整個產品生命週期中吸引客戶的是主要敏捷性原則。 讓每個小組都能在他們所擁有的功能集上直接與客戶互動。
-
持續反饋：建立客戶反饋迴路。 這些循環可以採用許多形式：
- 客戶意見：讓客戶輕鬆提供回饋、新增想法，以及投票選擇下一代功能。 提供意見反應通常是透過專用網站來完成。
- 產品意見反應：產品內意見反應按鈕是詢問產品體驗或特定功能意見反應的另一種方式。
- 客戶示範：定期排程的示範，詢問客戶的意見反應，可協助塑造下一代產品，並持續追蹤建置客戶想要取用的應用程式。
- 早期採用者計劃：這類計劃應該以所有小組可能想要參與為某個點的想法來開發。 早期採用者可以存取早期版本的工作軟體，並提供反饋。 通常，這些程序的運作方式是為早期採用者清單選擇性地開啟功能旗標。
- 數據驅動決策：尋找檢測產品以取得實用數據的方法，並測試各種假設。 協助推動一種慶祝學習的實驗友好文化。
改善項目可見性
您和小組對於完成工作的目標、願景和進度有了更深入的見解，您就越能夠降低風險及管理相依性。
- 小組結構：無論您的組織有多大，都以 6 到 9 個規模的小小組來建構您的組織。 建立 以組合管理區域分組的垂直自主功能小組 。
- 工作分解結構：將大型目標、功能或需求細分為較小的目標，仍然是專案管理的穩定。 藉由將工作細分為類似大小的工作，小組可以做出更佳的估計，並識別風險和相依性。
- 合併檢視：使用您的在線追蹤工具來匯總工作，以取得跨小組的知識。 建置儀錶板以顯示進度和趨勢。
- 體驗檢閱：這些會議在功能開發開始之前舉行，用於向領導介紹情境和優先事項、蒐集意見回饋、設定期望，以及揭示功能的跨團隊問題。
提高生產力員工的能力
一些可妥善調整並導致更快樂、參與且具生產力的員工的特定敏捷式做法包括：
- 內嵌領導：讓組織內的小組和領導者盡可能自我組織及自我管理。 小組自主性會提高組織的敏捷性和小組的有效性。 確保小組擁有成功所需的公司贊助。
- 每日站立會議：或者， Scrum 會議 有助於讓小組專注於每日需要完成的任務，以提升他們履行衝刺承諾的能力。 隨著組織成長，他們應該考慮交錯這些會議，以便視需要進行跨小組參與。
- Scrum 團隊的 Scrum：來自不同敏捷小組的成員每日會晤，回報已完成工作、接下來的步驟，以及代表小組內發生的問題或阻礙。
- 小組通訊：提供並鼓勵小組分享其做法和指引，他們和其他小組可以透過公司網路存取。 用於此用途的常見工具包括小組Wiki、OneNotes或 Markdown 網站。
- 共同合作：鼓勵團隊內以及團隊之間的非正式溝通與合作。 將程式代碼檢閱、設計檢閱、規格檢閱等做法制度化，不僅會增加小組共同作業，還能協助開發個人和整體公司能力。
改善組織文化
您可以藉由參與您想要建立的文化來提升組織效率。 當個人、小組和組織採用一或多個持續改進做法時，就會發生文化變更。 數個可調整的敏捷式做法包括：
回顧：通過問：「什麼進展順利？」、「我們應該以什麼不同方式做什麼？」和「我們應該停止做什麼？」等問題，協助小組反思他們如何改善其流程和做法。 回顧可協助小組瞭解哪些工作良好，以及需要改進的內容。 回顧可以隨時隨地進行。 然而，定期將某些回顧制度化有助於使持續改進做法制度化。 例如：
短期衝刺回顧 可協助小組找出定期改善的區域。
發行回顧 可協助組織找出改善通訊和內部做法的領域，並推動下一版的改進。
作業檢閱：通常每月舉行，並包含來自整個價值數據流的代表。 跨越項目組合和其他計劃，並使用客觀的量化數據，設計這些回顧，以引發有關影響團隊之間效能動態的討論。
改善追蹤板：改進流程的好點子隨時可能來自任何人。 擷取這些想法來討論並決定如何快速處理這些想法，是支援程序改進工作的關鍵。
白板提供任何簡單和視覺的方式，以擷取想法。 此外，您可以建立改進追蹤小組，並擷取您在電子 面板上追蹤的想法。
制度化共享：共用最佳做法和溝通想法可協助組織內的所有小組成長和改善。 開發學習文化是支援這項和其他持續改進活動的關鍵。 要考慮的一些想法：
內部維基
內部通訊組清單
Hackathon 週或 10% 自由開發時間
內部敏捷式支援小組，以支持採用敏捷式作法的小組
文化遊戲 為敏捷式管理員提供良好的資源，可協助小組採用敏捷式並分享最佳做法。
實務社群：支持內部通用專業領域（例如 DBA、SW 架構師、UX 設計）
工作軟體
「經常交付可運作的軟體，從幾周到幾個月，以較短的時幅為優先。」
「工作軟體是進度的主要量值。」
- 敏捷宣言
隨著軟體、功能和複雜性的增加，您必須採用可協助您產生消費性解決方案的做法。
- 功能旗標：使用功能旗標來啟用或停用對不同功能的存取。 為早期使用者啟用功能提供支援，以獲得使用者回饋。
- 發行列車：提供另一種類型的步調用以交付一個或多個功能。 功能小組瞭解預先規劃的推播新功能排程，並正確規劃。 發行列車可以對應到為組織建立的相同衝刺頻率，或以不同的步調發生。 如要了解如何設定短衝和發佈列車，請參閱調整敏捷式架構。
- 持續整合：採用可消除手動工作的程式，並改為透過測試、建置和部署週期自動執行軟體流程。
- 內部開放原始碼：將開放原始碼軟體社群中開發的價值和精神帶到您的內部開發小組。
相關文章
除了上述做法之外，您可以在下列文章中找到更多有關調整敏捷式工具的指引：
產業資源
不具擴展性的做法
- 估算大型計劃：瀑布專案方法的一部分涉及估算資源和排程。 舉措越大，這些估計的價值就越低。 隨著項目的增長，可能會引發風險和未預見的問題和障礙，使許多估計值失效。
- 速度：雖然小組速度可以提供有用的計量，讓您深入瞭解每個小組在短期衝刺週期內完成的工作量，但您無法新增小組速度來取得有意義的或有用的計量。 此外，依靠多個小組共同的工作節奏來可靠地完成長期預測是有問題的。 Teams 在預估工作的方式上各有不同，隨著時間推移，這些差異會更顯著。
- 由上而下的規範性解決方案：一種尺寸並不適合所有人，一個解決方案通常也不適合所有團隊。 支援小組自主性表示讓小組找到自己的解決方案。