改善軟體發行管理的七點建議

軟體專案若要取得成果，好的發行管理必不可少，它可以確保當軟體開發完成時，能成功地提供給希望使用它的人，能夠讓已有客戶感到滿意並有希望贏得新客戶。

英國一家電信提供商曾遇到了一個問題。它需要部署一臺關鍵業務供應商交換機，這要求它重新設計其計費和賬戶管理系統。這些系統必須在3個月內部署到位，否則該公司面臨損失數億英鎊和股價下跌的風險。但是，這家電信提供商的開發過程不佳，其發行管理存在很多問題而且不一致。

該公司請我們幫助在規定的期限內提交該軟體，扭轉失敗的發行管理過程。在3個月內，我們要發行重新改造過的應用的待發行的版本和兩個計 劃發行的版本。最重要的是，我們建立了一個通暢的、輕型的發行管理過程來確保未來的發行按時和符合所要求的質量。下面我們將告訴您我們是如何做的――包括 我們犯的錯誤。

1.瞭解發行管理的當前狀況

在不瞭解糾正問題的物件是什麼、它如何以及在何處出現了問題時，你不可能開始糾正問題。我們改進客戶的發行管理系統的第一步是通盤掌握當前發行過程。我們從與涉及軟體過程的關鍵人員的多次討論入手。

通過這些討論，我們確定我們的起點相當糟。當我們加入這個專案時，專案中有在完成兩個月後仍在等待發行的軟體。

測試環境受到限制並且缺少管理，因此它們一般都過時了，不能使用。更糟的是，啟用新環境和更新已有環境需要相當長的時間。

當我們到達現場時，手工執行迴歸測試需要長達3個月的時間。它通常被放棄，從而大大降低要發行的軟體的質量。

總體上講，士氣非常低。這些人在定期提供重要的軟體上從未得到過幫助，而這消磨掉了他們的銳氣。

2.建立定期的發行週期

一旦我們掌握了發行流程當前的狀況，我們著手建立定期的發行週期。

如果工程團隊是專案的心臟，那麼發行週期則是它的心跳。在決定發行軟體投入生產應用的頻率時，我們必須瞭解我們需要做多少非功能測試以及它需要多長時間。這個專案需要回歸、效能和整合測試。

建立發行週期至關重要，因為：

◆它提供討論軟體可能需要的非功能測試的機會。

◆它宣佈有關人員何時可得到某個功能的時間表。如果知道這個功能將定期釋出，他們可以在同意這將是什麼功能上取得一致。

◆它建立一種各團隊(包括營銷和工程)可以遵守的程式。

◆它給予客戶他們可以訂購併得到某種東西的信心。

你的發行週期必須儘可能地準確，而不是你在午餐時臆想出來的虛幻的數字。在宣佈發行週期之前，先檢驗它。對於失敗的發行過程來說，沒有什麼比不現實的日期更糟的了!

我們從建議一個星期的週期開始。這個計劃證明是不可行的;客戶的資料庫環境不能很快重新整理。然後我們嘗試兩個星期的週期。這種作法沒有受到參與者的直接反對，但前二次它沒有取得成功!最後，當我們克服了環境週轉瓶頸和自動完成一些測試之後，兩星期成為可取得的週期。

最終，我們建立了一個每兩個星期將來自工程團隊的可投入生產應用的程式碼投入系統測試的週期。然後兩週後，我們發行這段程式碼投入生產應用。

記住：你的發行週期與你的客戶希望得到軟體的時間無關。它是你何時可以在所需的質量水平上提供它的時間。我們的客戶之所以支援我們的發行週期，是因為我們讓他們參與決定這個週期。他們的意見只是決定發行週期的一個考慮因素。

3.採用輕量流程,及早測試和定期審查

如果有一種設計(或重新設計)過程的指導原則的話，這就是完成一點工作後，審查你的結果，然後再完成更多的工作。重複這種循序漸進的方式，直到得到你想要的結果。

輕型過程是那種不需要冗長的官僚主義審批或無休止的會議就能達成一致的過程。它們通常只需要最小的輸入和輸出的可接受水平。它們失去的是臃腫和官僚主義，得到的是對變化的反應和廣泛的採用!

這種作法的基礎是棘手的文件資料問題。你必須記錄你做了什麼、如何做的。否則，你去審查什麼以及如何改進?

我們並不是說那種危害熱帶雨林和讓讀者昏昏欲睡的文件資料。我們是指人們(技術人員和其他人員)可以閱讀並按照它採取行動的文件資料。

我們的工程團隊選擇了Confluence――一種商用工具――來協作記錄他們的工作。他們利用這種軟體建立記錄他們每個工作週期同意 開發什麼的最小但有效的文件資料。他們記錄他們開發什麼，他們如何開發以及讓其執行需要什麼。我們看到了這種方法的價值並把它(方法和工具)推廣給參與軟 件開發過程的每一個人。

最初，我們建議了發行我們從工程團隊得到的軟體的任務順序。它覆蓋我們如何從原始碼控制管理系統拿到軟體;軟體包叫什麼以及每個元素 (可執行程式碼、資料庫指令碼等等)將如何執行、執行在什麼平臺上。那麼，我們利用每個元素的啞程式碼進行模擬使用。我們測試了我們的順序，記錄了我們模擬使用 時做了些什麼。這些工作成為安裝說明的基礎。

下一步是讓要部署真正版本的人只使用我們的文件資料進行另一次模擬使用。在他們模擬使用過程中，擴充套件、補充和改進我們的安裝說明。由於每個人都為文件資料做出了貢獻，因此這個過程變成人人蔘與的過程;由於他們成為其中的一分子，這個過程得到更廣泛的採用並帶來更好的質量。

在每一次發行後，我們都審查這個過程。我們研究文件資料，確定在發行過程中進行的修改。每一次我們都分析文件資料如何能夠得到改進，並根據分析結果對發行過程進行改進。

4.及早建立發行基礎設施

發行基礎設施是部署軟體和讓使用者能夠使用它所需要的任何東西。你對客戶的責任不只是你開發了偉大的軟體，它還包括軟體可供客戶訪問和使用。

建立好的發行過程的關鍵在於在工程團隊完成軟體開發前，確定你需要什麼發行基礎設施才能將軟體提供給客戶。

發行基礎設施涉及硬體、儲存、網路連線、頻寬、軟體許可證、使用者配置檔案和訪問許可權。人員服務和技能也是發行基礎設施的組成部分。例如，如果你需要安裝和配置專家軟體，將這種技能可用性或獲得它的成本排除在你的基礎設施計劃之外是不明智的。

儘早發現獲得所需硬體中隱藏的瓶頸或缺少的技能(比如，配置安全的網路)至關重要。你必須在它們阻礙你提交軟體之前解決它們。

這項工作份量並不輕。我們的專案剛一啟動，我們就努力讓我們的發行基礎設施部署到位。甚至在6周的研製期後，我們仍在等待測試伺服器所需的專用記憶體和硬碟。

5.儘可能自動化和標準化

自動化使你能夠在不佔用寶貴的人力資源的條件下，完成重複的任務。標準化確保你的自動化的輸入和輸出每一次都是一致的。

在我們參與專案前，工程團隊手工製作可部署的軟體包。新軟體包當時不能保證與上一個軟體包相同;事實上，甚至不能保證它是他們開發的軟體，更不能保證它是否能執行!建立具有他們在一個可能部署的結果中提供的特性的軟體包常常需要技術人員花很多天時間。

我們立即設計了一個部署工程團隊將提交給我們的軟體包的結果和接受標準，並幫助他們實現製作軟體包的標準化。這觸發了部署在每一次發行時的一致的結構中構建軟體的自動化的過程。

發行軟體打包突然不再是個問題。因為我們自動完成接受標準的檢驗――例如，這段程式碼必須在提交和測試之前進行單元測試，以確保它可以得到部署――因此我們保證了它的可執行性。因此，我們能夠在非常短的時間內利用一條命令進行完成的程式碼的打包、確定版本以及測試和部署。

但是，自動化並不僅限於此。在每一個開發週期中，我們有更多的迴歸測試要做。已有的迴歸測試手工執行需要3個月時間;因此，發行的軟體從沒有得到完全的測試。

我們新建立的發行週期意味著在我們能夠發行軟體投入生產應用的兩週內，軟體必須完成迴歸、效能和整合測試。我們可以通過為每一類測試建立不同的環境來克服不同的測試型別(整合和效能)的問題。但我們怎樣才能將3個月的迴歸測試壓縮到兩週的時間窗裡呢?

首先，我們發起了一次確定優先重點的運動。客戶確定了最高優先順序的迴歸測試：他們接受的作為老功能仍在工作的證明的最小值。然後，我們著手自動化完成這些工作。隨後的接受測試還實現了自動化，從而確保我們可以在幾個小時而不是幾天迴歸測試每一發行版本。

6.建立正面的預期

如果發行軟體對於你十分重要的話，不要對它祕而不宣。當我們的團隊知道這十分重要時，他們改進了提交軟體版本的承諾。

我們通過確定指定的發行經理在團隊同意軟體準備就緒時預測軟體準備就緒來支援這種重要性。我們讓程式經理(實際上是我們的客戶)向團隊解釋這個軟體版本為什麼重要的原因。(最終，這歸結於損失數百萬英鎊!)

我們要求工程團隊提交的軟體符合標準(確定了版本、經過測試、提供文件資料和打包);我們確定我們將在每一個發行週期需要這種標準包。我們必須解釋我們為什麼以這種方式需要軟體(它使我們的自動化過程變得更容易、更一致)，並且我們將工程團隊的反饋融入到發行工程中。

建立正面的預期是增加每個參與這個過程的人的動力的非常好的辦法。我們沒有被賦予任何行政權力，因此不害怕制裁或開除。相反，我們利用 正面預期的力量，讓人們參與進來幫助我們改進發行過程。我們讓個人做出關鍵決定(他們以前從未感到能這樣做)，因為“"Mike 和Tym週四前需要這個軟體，我們說我們將提交它。”

7.向人員投資

不管我們在硬體、軟體和神奇的過程上花了多少錢，沒有團隊成員的積極參與，你在發行軟體上享受不到可持續的成功。更糟的是，你甚至最後不能發行任何軟體!

你可能認為我們要談的是找到合適的人員並重獎他們，或者認為我們要談的是工程團隊完成工作所需要的工具和技能。事實是，你知道你應當為 你的團隊找到合適的人員(“合適”的定義對於不同行業是不同的)，你應當恰如其分地根據他們提供的價值獎勵他們，是的，你應當確保他們擁有他們所需的工具 和技能。

一個基本的前提是，人們本質上對做好的工作感興趣。如果你想讓團隊成員關心你的產品，關心做好工作，你首先必須證明你關心什麼對於他們 重要。從專案一開始，我們就在相互尊重和理解的基礎上，與團隊中的每個人建立了非常好的和諧關係。我們證明我們靈活處理個人面對的挑戰，我們盡我們的可能 提供幫助。不管這是購買午餐、提供飲料、組織培訓與整理建議、傾聽問題或扮演辯論時的對立面，我們都去做各種讓每個人都感到作為發行過程的關鍵部分的價值 所需要的事情。

當談到專案時，我們發現一種普遍的冷漠感。一些長期的永久僱員只簡單地等待冗餘包;另一些人由於從來沒有把事情做好而從不被要求做任何事情。讓許多人回到關心向發行過程貢獻他們的個人價值的狀態，需要大量的人際關係建設和時間投入以及正面的肯定。

發行管理是任何軟體專案非常重要的部分，但常常沒有給與應得的重視。在我們理順這個中型電信企業的軟體發行過程的經驗方面，我們還有很多很好的提示、建議和結論。但上面的7條是這個案例中對於我們最重要的7條經驗，儘管我們期望它們成為應用於任何案例的好想法。

好的發行管理需要艱苦的工作、堅定的決心和通暢的交流勾通;但是，最偉大的技能是審查、學習和適應改進的能力。