小組的發行流程
建立 DevOps 做法的第一步，就是評定您目前的流程。 這表示您需要分析：
- 您現有的成品，例如部署套件和 NuGet，以及您的容器存放庫。
- 您現有的測試管理工具。
- 您現有的工作管理工具。
- 建議的移轉與整合策略。
讓我們與 Tailspin 小組一起完成上述分析，看看 DevOps 如何提供協助。
產品經理 Irwin 離開之後，Amita 說道：「我們需要幫忙。 我不知道我們甚麼時候得交出這些修正，但八成沒剩多少時間。 我們還沒有準備好在短時間內做出大幅改善。 另外，新的 Space Game 網站得等到我們解決這團混亂才能上線，而遊戲就快上市了。」
Andy 看著 Mara。 「看來妳才沒來幾週就有得忙了。」
「沒關係，」Mara 回答。 「也許你可以向我說明一下該怎麼做。 要如何讓遊戲從開發環境進入實際執行環境？」
「好問題。」Andy 說道。 「我不確定我可以給妳簡明扼要的答案，但我們可以試試看。」
小組決定到咖啡廳放鬆心情，來場沒那麼嚴肅的討論。 他們要試著一起找出為什麼會有這麼多問題。
Mara 邊喝著咖啡邊聆聽著，並嘗試做些筆記。 資訊堆山積海，而且雜亂無序。 Mara 對於小組的整體理解如下：
- 小組使用瀑布式方法。 管理階層設定優先順序。 開發人員撰寫程式碼，並將組建交給品管部門。 經過品管部門測試後，交由營運部門部署。
- 儘管小型團隊適用瀑布法，但在此案例中，目標不一定都很清楚，而且似乎經常變更。
- 測試會推遲到整個流程的後期。 這表示，修正錯誤並加以變更會變得更困難而且成本更高。
- 「完成」的定義並不明確。 每位小組成員都有自己的想法， 卻苦無所有人都同意的整體商務目標。
- 某些程式碼位於集中式版本控制系統中。 許多工具和指令碼只存在於網路檔案共用上。
- 有很多流程都必須手動作業。
- 溝通方式紊亂，全依賴電子郵件、Word 文件以及試算表。
- 意見反應也不頻繁且不一致。
- 往好處想，小組似乎相處融洽，而且想讓事情更順利地執行。
當 Mara 看著筆記本中那長篇累牘時，她明白這些資訊必須加以統整。 經過整理的資訊，能夠更容易地用於評估流程。 Mara 相信 DevOps 方法可以解決小組中許多的問題，但她需要想辦法讓小組理解這點。
要實現 DevOps 做法，通常得先從了解目前的流程開始。 了解流程之後，就能評估行得通與行不通的部分，並將重點放在要優先修正的項目。
Mara 問道：「你們曾經做過『價值流程圖』練習嗎？」
Andy 翻了個白眼，Amita 嘆了口氣，Tim 說：「我們不需要更多文書工作。」
Mara 說：「我知道了。 交給我吧。」
大家都很高興能夠讓新手處理這件事，然後各自回去工作了。