採用敏捷式文化特性

如果從過去十年的「敏捷式轉型」中吸取了一個教訓，就是採用或實 作敏捷 式方法沒有任何一個適合的解決方案。 每個組織都有不同的需求、條件約束和需求。 盲目遵循處方不會導致成功。

敏捷式運動是持續尋找方法來改善建置軟體的做法。 這不是一個完美的每日站立或回顧。 相反地，它就是建立一種文化，讓正確的事情更經常發生。 站立和回顧等活動有自己的位置，但他們不會改變組織的文化。

本文詳述每個組織建立敏捷思維和文化所需的基本元素。 建議不應盲目地遵循。 每個組織都應該在指定的環境中套用有意義的內容。

排程和節奏

沒有完美的短期衝刺長度。 Teams 已成功使用短跑長度，範圍從一到四周。 最重要的是一致性。

選取適合您組織文化特性、產品和想要提供更新的短期衝刺長度。 例如，Microsoft 開發人員工具部門（大約 6,000 人）在三周的短期衝刺中工作。 領導小組沒有選擇這個短期衝刺長度：它來自工程小組的直接意見反應。 整個部門都按照這個為期三周的短期衝刺時程表運作。 自那以後，短期衝刺已成為 組織的活動訊號 。 現在，每個球隊都遊行到同一鼓的節拍。

請務必挑選短期衝刺長度並堅持下去。 如果有多個敏捷式小組，他們都應該使用相同的短期衝刺長度。 如果意見反應驅動變更，請接受。 當正確的詞彙到位時，就會變得很清楚。

航運文化特性

Microsoft 首席群組計劃經理彼得·普羅沃斯特說：“你不能欺騙運送。該語句的簡單性和真理是敏捷式文化的基石。 Peter 表示，寄送您的軟體會教導您無法理解且無法理解的專案，除非您實際寄送您的軟體。

人性是推遲或避免做事情，直到絕對必要。 在軟體開發方面，這無法更真實。 Teams 會在週期結束時插入錯誤，在強制安裝或升級之前不要考慮安裝或升級，而且通常會盡可能避免當地語系化和輔助功能之類的專案。 當這種模式出現時，小組會建立技術債務，稍後需要支付。 航運要求支付所有債務。 你不能欺騙運送。 若要建立敏捷式文化，請先嘗試在每個短期衝刺結束時寄送產品。 一開始並不容易，但當小組嘗試時，他們很快就發現應該發生的所有事情，但不是。

狀況良好的團隊

完美的敏捷式團隊沒有食譜。 不過，一些關鍵特性可讓成功更容易實現。

盡可能共置小組

小組能否找到跨不同地理位置的人員的成功？ 是的，但比較困難。 當人們共置並坐在同一個房間時，正確的談話往往會發生。 在全球各地和不同時區的小組仍然可以成功。 但是，沒有所有這些障礙，那同一支球隊沒有優勢嗎？

讓團隊維持不變，以合理的時間長度

允許小組共同掌握建置軟體的藝術。 當團隊爭吵時，他們發展的任何化學成分都會中斷。 有時適合重新組織，但當小組有時間學習如何共同作業時，通常更有生產力。 作為指導方針，請嘗試讓團隊保持至少12個月。

負載平衡工作，而不是人員

有時候團隊落後，需要協助。 解決這個問題的常見策略是借一個人從一個團隊到另一個團隊。 不過，這可以適得其反。 更好的解決方案是將工作負載平衡到另一個小組，而不是在他們之間負載平衡人員。 從一個團隊提取一個人來説明另一個團隊破壞這兩個團隊，它可以挫敗被移動的人，即使暫時。 這一切會影響小組生產力，而且更有可能對恢復排程的能力產生負面影響。

負載平衡工作，而不是人員可讓已建立的小組介入並協助。它成為關於 優先順序的談話，而不是關於 人的談話。

讓小組擁有功能區域，而不是架構層

努力建立擁有功能區域的垂直小組。 這些小組負責將功能新增至其區域所需的所有工作，從資料庫到使用者介面變更。 小組有權提供並擁有端對端體驗。

當水準小組擁有架構層級時，沒有任何單一小組負責端對端體驗。 新增功能需要多個小組協調，而且需要更高層級的相依性管理。 解決 Bug 需要多個小組調查他們是否擁有修正 Bug 所需的程式代碼。 當小組判斷它 不是他們的 Bug，並將它指派給另一個小組時，錯誤 就會四處擊球。

功能小組沒有這些問題。 擁有權和責任是明確的。 某些架構型小組可能有一個地方。 不過，垂直聚焦的團隊會更有效率。

下一步

當小組開始進行自己的敏捷式轉型時，請記住這些基本原則。 請記住，沒有單一配方適用於每個組織。 敏捷式轉換是一個旅程。 進行變更並從中學習。 隨著時間推移，組織將開發所需的敏捷式文化。

Microsoft 是世界上最大的敏捷式公司之一。 深入瞭解 Microsoft 如何採用敏捷式文化進行 DevOps 規劃。

瞭解 Azure DevOps 如何讓小組 採用及調整敏捷式文化特性。