冗長且繁複的SDLC

山姆大叔任職於一間大型金融控股公司資訊單位，雖然國內近幾年Fintech 都非常的火紅，看起來十分的先進。但是其實在國內金融業其實是一個十分高度管制的行業，十分受到主管機關關愛的眼神。因此所有的行為，都會需要有軌跡或是要經過審核。

這讓本公司過去的二十年CMMI + 瀑布法的軟體開發交付方式大行其道，因為所有的軟體需求管理，都會要在最早期的時候將所有系統的細節都談定，產出大量的word文件，並走過冗長的流程進行簽核同意後，才開始進行軟體開發專案管理的流程。

其實瀑布法是一個一直以來都可行的做法，特別是在一個大型系統最早期的誕生的時候，在高度規劃階段時可以進行大量的討論來釐清真正的需求以及痛點是哪一些，如此可以對軟體開發的前期規劃將相關的需求討論完並產出相關文件。

但畢竟一個軟體開發過程，並不是只有專案管理的相關文件為主，最終還是涵蓋在開發者要能夠產出可以解決需求單位的痛點/需求的系統或功能才對。

另外就是，即使應用系統已經到了維護階段了，後續的所有功能小幅度變更、Bug的修正，都還是秉持著瀑布法的精神，前期大量的產生大量文件，並經過簽核後，再進行開發。然後開發驗證後，要上線的時間又要再產生大量的文件，經過簽核後，再請非開發人員進行應用程式過版上線到營運環境的動作，非常冗長的作業流程。

而且，雖說是在大型金融控股公司，應用程式開發相關人力大概在35人(不含Infra、網管、作業等單位），但因為過往的績效評核高度跟系統上線有關係，因此維運中的應用系統應該高達70~80個系統，又有陸續在新開發的系統在撰寫中，開發能量其實十分缺乏。

轉為外包的困境

由於開發能量的缺乏，所以就會著眼到既然無人，那就把開發外包吧！

這是一個正常的決定，但因為金融公司的高度管制，因此即使寄信有時候都會需要經過主管審核，以及外部大量網站的封鎖，所以大多數的軟體開發專案管理方式，都是使用Excel 檔案來作為議題追蹤，word檔案進行文件製作，然後使用 email來進行訊息傳遞。

所以當有議題出現的時候，就會用一封專門討論議題的email進行溝通，然後不斷的FW循環，CC越來越多的人，email越來越大封，有時候一個議題需要花上10次以上的FW才可以追蹤完成，時間可能都過去兩周了。

有經歷過Excel 以及email 來進行軟體開發專案管理的人應該遇過，那就是當專案人數越多時，待追蹤議題越多時，就越容易搞混到底Excel檔案中的議題到底追到哪了？而當時excel 的第25項議題email討論串在哪裡，需要去outlook去翻找到天荒地老。

對應到程式開發的部分就會遇到，現在測試環境運行的到底是哪一個版本？三個月前原本一個似乎已經完成的議題，應該已經交付了，怎麼又出現了？

外包每次開發後的版本交付也是一個議題，由於公司內把所有對外的雲端儲存空間都封鎖了，因此曾經有遇過外包商的交付，需要用email 將整包程式，分拆成10封信(因為公司outlook單封信上限10mb)，然後每次收到十封信後，再來一封封解壓縮。

版本控管與需求之間的問題

不論如何，所有程式的開發或異動，一定來自於需求。不論是需求單位需要新功能，或是開發人員被回報了臭蟲，都會需要進行需求分析與管理後再進行軟體開發，進而會有版本控管的問題。

首先先提及需求管理，我們公司使用的還是多份SOP中所規定的word檔案，進行需求確認與管理，然後將這些文件放入一個純客製化的簽核系統，經過層層簽核後，指派給開發人員進行開發的動作，或許可稱工單系統，但又卻把軟體開發的需求、測試、佈署文件全部都放到這上面來，並與軟體版本控管系統分開。

要進行軟體開發，就要進行版本控管。筆者來到這間公司的時候，其實十分訝異所使用的版本控管系統，竟然是我在電子廠作為研發工程師多年後，也沒有聽說過的工具，一定是我孤陋寡聞。

初次接觸這個軟體的時候，就發現這個軟體注重的是發佈時的發佈版本，是否有經歷過嚴謹的簽核許可流程，因此並不適合開發人員在做開發實驗的過程中使用。

況且，這個版本控管系統僅能進行簽入簽出的版本控管方式，但又與TFS不同，因為還綁定了簽核流程。

意思就是，需求的所有文件進入需求的客製化系統進行大量簽核行為後，開發人員對於程式碼的版本控管簽出也需要進行大量簽核行為。

因此，當同一個系統同時有多個需求進來的時候，就完全無法使用這個版本控管系統來進行有效的版本控管。

況且，這個版本控管工具如果要用在開發階段使用，要佈署到測試環境....只能手動。

整理一下重點

沒想到背景就寫了落落長，來總結一下內部遇到的問題，但因為故事實在太長了，所以先根據上面一些狀況把我所看到的現況問題做一些列點：

• 軟體開發生命週期SDLC
  • 計畫與分析階段：針對軟體需求討論與分析的溝通方式無效率，無統一平台進行知識留存與相關討論。
  • 設計與開發階段：公司未提供開發階段有效之版本控管工具，開發過程需仰賴開發人員自行將需驗證之版本憑本事發佈至測試環境。
  • 驗證與整合階段：需求單位透過email或電話等方式，通知後進行驗證作業，驗證清單仰賴郵件敘述，無法與需求直接進行比對。相關測試過程也無法被完整記錄，僅能透過個人認知進行測試截圖。
  • 過版與維護階段：軟體交付至生產環境所需要的確認清單，內部有多份未統一的SOP進行大量規範，如不可將帳號密碼明碼放置在設定檔中。或需作業人員過版的檔案清單，也仰賴word檔案進行人工確認作業。

我只是想寫程式而已，為何過個版或找個知識卻這麼痛苦？

有幸的，去年在授意的狀況下，有機會針對目前內部的一些痛點建立一套試行的流程。因此，這系列文就是要針對一些痛點為任務，透過研究Azure DevOps Service來進行痛點的解決，希望一切都會順利。