當你聽到“rollout”這個詞時，你最初的想法是什麼?
對一些人來說，它灌輸了一種恐懼感。
推出意味著即將發生變化。一個新的開發項目或軟件發布即將到來。我們許多人對改變有一種天生的厭惡。我們堅持己見，抓住任何能阻止它發生的反對意見。
但如果一家公司想要擴大規模和發展，變革是必須的。變革為組織帶來創新。它促使推出更現代化的產品，更好地符合客戶當前的需求。
那麼，企業如何讓團隊適應變化呢?這似乎有點違反直覺，但組織應該增加變化的頻率-直到它變得不引人注意。
就像成長的過程一樣，我們需要在軟件交付體驗中引入一種“時間都去哪兒了”的心態。這並不意味著每次都交付完美的版本，但它確實意味著對軟件交付的簡化更改方法，從而實現快速失敗和快速改進的文化。
平衡增量更改
父母往往不會注意到孩子每天的成長。但拜訪那些可能不經常見到孩子的親戚，往往會對孩子的快速成長表示懷疑。
當我們是一個定期的、積極的參與者時，我們可能會對變化視而不見。
考慮對那些可能抗拒改變的團隊采用同樣的思維。你自信地釋放得越快，到更大的主動性的過程就越不引人注意。
當然，對於最終用戶來說，更改會變得過於繁瑣，這是有一個閾值的。為了避免達到不可返回的變更容忍點，將交付分解為季度、每月、每周甚至每天的更小增量，以確保在任何一個版本中都不會引入太多內容。
該方法需要判斷每個版本中提議的更改量的度量，並度量對生產係統的影響。例如，需要進行更多更改的應用程序需要更快的發布時間。
您可以使用一種獨特的策略來找到增量更改與實現成本之間的正確平衡，以滿足適當的裏程碑。基本原則是，範圍越大，影響越廣，需要的規劃、溝通、啟用、測試等就越多。組織這些謹慎的活動可能會花費更多的時間。
最大的風險存在於測試工作和後續的開發活動中，以解決發現的問題。當返工擴展到目標交付物之後，它會將發布延遲到下一個部署窗口，這增加了後續生產變更的影響，並放大了用戶中斷。能否成功地達到目標發行日期取決於這些反饋循環的速度。
沒有按比例分布在軟件開發生命周期中的更改會在用戶的日常體驗中產生重大的變化。它增加了支持采用的超護理的成本，導致需要調查更多的生產支持案例，用變更管理票據淹沒支持資源，並拖長了技術問題的解決時間。
雖然仍然需要版本的支持，但是可以通過交付率大大減少更改的量，減少資源需求。相對數量的變化和持續的交付導致更少的幹擾，因此更少的詢問超護理。
當改變出錯時
當改變與負麵後果相關聯時，改變會變得更加困難。
讓我們以代碼中出現錯誤時會發生什麼為例。經驗法則是每1000行交付的代碼中大約有15到50個錯誤。代碼更改的數量與潛在缺陷的數量相關。
這些缺陷中的許多將在測試的不同階段被捕獲，並在發布之前處理。根據代碼的數量和質量，這項工作可能導致大量的返工和永無止境的缺陷管理衝洗和重複過程。這種破壞可能會阻止終端用戶認識到新功能的價值。
從瀑布式到敏捷的方法轉變本應減少這些中斷的影響。開發衝刺的短時間限製了交付的代碼行數。從理論上講,敏捷方法由於更改的減少，應該限製測試的範圍。然而，與敏捷衝刺的截止日期相比，執行測試的速度通常是不夠的。
最終，許多敏捷實踐將采用混合模型，在單個測試迭代之前進行多個開發衝刺。由於在測試之前交付的代碼行，這隻會將範例移回到更高級別的缺陷。
底線是，開發窗口越長，質量評審之間的變化量就越大，因此缺陷的可能性就越大——導致在軟件交付過程中最終用戶對變化的高度識別。
注意缺陷
雖然可能不可能減少所有的缺陷滲漏，但是測試的風險概要應該足以避免對業務操作的任何重大影響。但是即使是非關鍵的缺陷也會對用戶和發布的整體感知產生不利的影響。盡管這些缺陷可能有解決辦法，但它們往往會造成不舒服的用戶體驗，或者隻針對一小部分用戶。
當變更被簡化並快速連續地交付時，由於更高的發布節奏，缺陷會被快速地解決。當變化變慢時，預期的解決時間也會變慢。如果發布窗口間隔得太遠，與缺陷的解決時間相比，特性改進將是最小的。另外，發布的缺陷的數量可以直接影響發布的節奏。
一旦為適應缺陷滲透而進行的返工超過了衝刺階段的特性開發，發布計劃可能會被迫陷入停滯。為了重新建立應用程序的質量，所有的缺陷都需要被解決，這導致了更大的投資和最小的收益。這就是為什麼必須確保質量過程是發布節奏的核心。
讓敏捷領導人
變革從高層開始，慢慢滲透到團隊中。如何傳達這些對公司計劃的改變，將影響到他們如何接受這些改變。
確保集體與整體變化的目標保持一致是至關重要的。它有助於將大型軟件推出分解為一組可管理的具體可交付成果，而不是共享廣泛的計劃。這為管理人員和個人貢獻者提供了一個北極星來管理他們的可交付成果，並產生了一個小增量更改的過程。
管理人員需要能夠將漸進式變化與大局之間的點聯係起來。這類似於用拚圖盒上的圖片來確定特定拚圖塊的位置。畫麵的質量越高，對單個可交付成果的模糊假設就越少，固有風險就越低。
將簡化的變更與有效的技術目標結合起來，可以為組織帶來清晰。驅動競爭優勢、增加業務參與和重新想象操作的想法應該是所有IT結果的根源。然後執行計劃與結果相一致，主管將項目導向計劃，而經理創建行動項目。
要實現這種簡化更改的遠景，首先要授權資源在嚴格的指示之外進行冒險。讓他們發現並實施與他們負責交付的結果相一致的行動。
為了實現簡化的變更，開發您的技術交付的質量，同時保持與執行結果的核心集合的一致。應該快速進行這些更改，以最大限度地減少對最終用戶的破壞，並防止可能導致業務中斷的缺陷風險。
當解決時間可以在後續版本中實現時，非關鍵缺陷的接受將更容易接受。為了保護簡化更改的編排，必須確保工作負載不會因缺陷而過載。
通過將質量放在核心位置並快速、增量地交付更改，您的用戶可能對“推出”這個詞有更積極的看法。