給想成為SA或剛成為SA的你系列-軟體開發專案中WaterFall與敏捷開發的比較（一）
筆者原本在商用軟體產業待了約莫九年，在去年抱持著想見識一下自己這九年中習得的技能在外面可以做什麼樣的工作而做了離開的決定。
這次的工作轉換，不只從乙方到甲方，也大幅跨越了不同的產業任職，對於軟體開發模式的差異有體驗到許多深刻的感受，唯一不同的只有前後擔任的職務都是所謂的System Analyst(下簡稱SA)。
先來簡單的介紹前公司，是一個在業界市占率很高的本土ERP軟體公司，幾十年的經驗打造了相當成熟的WATERFALL開發流程，透過PM →SA →SD →PR的流程進行開發（對，沒有ＱＡ）。雖然因為公司文化以及不重視ＱＡ的關係，成熟的流程卻只能產出良率極低的程式相當可惜。
至於新公司，是一間主訴求軟體開發及相關部門文化都走敏捷-Scrum的方式進行的公司，進入新公司前對於敏捷的方式到底如何影響開發深感好奇，實際上體驗後發現確實有很重大的差異。最核心的差異大概是Scrum裡面其實沒有所謂SA的角色，所以作為一個SA被招募後，在這樣架構下工作能夠為團隊提供什麼功能，反而是最大的重點。
由於軟體專案其實會有眾多的處理階段，本篇會先介紹需求確認階段並以筆者的經驗列出兩者模式間的比較和差異。
需求確認階段
作為任何一個軟體專案的開端，必然有其需求以及待解決的問題在前。
以SA的角色來說，不論在乙方或是甲方公司，通常不會是第一個接觸的需求或是提出需求的人。所以當接收到需求時，至少已經過了一手，收集需求完成後往下交付團隊開發又過一手，怎麼樣彌平之中的資訊落差，可以認為是SA的第一項重要課題。
這個小標題也在後續碰到的一個專案中有著更深的感觸，下次再另外寫一篇。
需求確認若做得好，團隊重工的機會就少一些。
需求交付越完整，團隊面臨緊急調整程式的機率就越低。
乙方的情境大致上是這樣的
- 從PM/業務/顧問處接收到客戶需求的雛型，通常此刻還是籠統而模糊的需求。
- 先消化需求，套用到標準程式的流程上，大致標註可能需要調整的程式或是不得不注意的環節。
- 直接與客戶訪談需求，確認稍早的預想是否對應客戶的預想
- 如果客戶導入經驗豐富，可能會著重在能否更精簡、或是節省成本。
- 如果客戶經驗稍遜，則SA更要想辦法具象化需求以提供客戶對於還看不到的程式以想像進行溝通，以求能夠得到正確的需求。
- 將需求轉化為文件：以文字、TABLE、資料範例、wireframe（用小畫家）等方式具體化客戶的需求。
- 跟客戶來回確認需求，盡量達到雙方認知一致，然後請客戶畫押，代表客戶也認可對將開發需求的描述，並願意承擔開發費用。
- 同時，需要不斷地跟PR的主管去壓時程，務必要求將自已的專案時間插隊在其他專案的前面，開始滾動無限的惡性循環。
甲方的產品團隊情境則是
- BD或是業務團隊，向主管提案，提案通過以後向有影響的相關部門提出需求，由相關部門的PM將相關的加入產品的BackLog。
- PM針對預計可進開發時程的BackLog做進一步的工作分析，可能透過與技術Team的Leader進行討論了解架構，也可能跟SA討論現有系統架構並初步評估商業邏輯上可能需要注意的部分。
- 推進的流程中，至少會定義出幾項東西（DOD、時程、User Story、wireframe）後才進行下一步。
- 而我們公司的部分除了以上以外，還會產出USER FLOW。
- 將產品帶入Scrum 團隊的Refinement會議中進行討論，此時是其他的RD第一次看到此需求，在這個會議上會透過15分鐘由提出者介紹修改的內容，並提供大家詢問問題釐清細節。這次的討論也需要將RD認為不足夠的資訊逐一補齊，可能包括以下幾項：例外情況、報警機制（監控資料發現異常資料時主動通知維護團隊）、上線時間、需要驗證的範圍
- 討論完了之後，除了太過模糊不清或是範圍大到需要拆單的情況，原則上會對修改進行「估點」，依照複雜度由整個團隊估計1~∞，一般來說超過13就已經偏高了（視團隊而定）。還有一點就是估點時常常考慮了工作量而不是複雜度進去，這點筆者心中也抱有一些疑問，但原則上就以各個團隊的風格為主。
- Refinement的階段完成，可以算是需求階段的告一段落。
差異及影響部分
差異一：RD參與專案的時間、對於開發細節的話語權。
傳統Waterfall的公司中，基本上不是稱呼為RD（Research & Development），因為開發者可以做到的事情實際與所謂的RD確實有一段落差，只能被稱為PR（Programmer）。
PR對於程式並沒有任何說不或是調整需求的話語權，只能等到需求來，就想辦法照著時間交貨。
RD對於程式還未進開發前就已經可以針對需求提出質疑，對於需求有疑惑時，也可以有獨立Survey其他解法的空間，可以選擇或建議一個符合商業需求的更好作法。
影響
RD不能及早參與討論的影響通常會體現在結果上，結果的運行效能、品質、完整性、例外情境上。
乙方公司的開發架構好壞通常完全看PM/SA的經驗如何，如果是新手或是業務做初版的話，通常會很容易做出很劃地自限的功能，或是見樹不見林，事後需要花費更多的資源進行補救一開始沒有打好的體質。
甲方公司及早參與也未必就沒有任何的問題，在這段期間經常見識到的是可能會有RD直接將某些不喜歡的調整方式以提高複雜度的方式影響專案的開發以及進行，例如：因應新的需求，某段功能要重寫，但可能該人員前陣子才剛重構完？或是修改後開展的架構大很多，需要盤點跟調整的地方變得很多。而複雜度估點的上升，就會直接影響到這項修改要多久才能完成＋發版。
綜合來說，個人認為讓RD提早進入討論對於專案開發上的細節會有很多品質上的好處。
至於乙方公司有沒有機會也做到這一點，答案應該是完全有可能的，但勢必會影響原本產能的佈局，是一項幅度很大但值得一試的修改。
差異二：PM對於產品開發的時程掌握度。
乙方公司的時程通常取決於最早跟客戶接觸的人，業務要賣解決方案給客戶，勢必會談到成本（金錢、時間、人力、組織）。首次系統化或導入ERP的公司，都會對時程有很不切實際的幻象。也有聽說過客戶詢問業務說：「我們今天付錢，你們下個禮拜來裝一裝就可以用了吧？」。而使用系統多年尋求更換系統的公司，也會有不願意付出過多轉換成本的考量，希望在一開始談好時，就壓到一個很漂亮的時程。更何況從眾多客戶的角度來看，我們付了這麼多錢，你們當然應該要好好的(只)服務我們吧？
甲方的部分則是主要由PO進行產品BackLog的排序跟安排，原則上前後順序的調動上較為自由。雖然也很容易接到自己公司開出來的隕石或是跨部門的大專案，這兩種屬於上線日程比較固定的情況，但通常需求初步提交到PO/PM手上時，離實際要上線的日程都還有一定程度的時間可以做準備工作，如果此時SA的角色也加入討論做前期技術的可行性分析，有機會在較趕的時程中及早完成應對以及開發的預備工作。
影響
配合客戶時程是一個乙方公司常見的情形，這個問題直到客戶驗收都不見得代表結束，往往要等到客戶支付完尾款後才能認為交付階段已完成。而乙方公司的財源，除了不斷地簽新案以外，維護舊客戶的產品也是一條相對穩定收入的管道。因此在各個PM/顧問都有自己客戶的時程壓力下，只好回頭來壓縮內部PR的工期，然就只能透過加班來達成(是不是很有工廠的即視感？機器開8小時不夠可以開16小時啊！)。壓縮期限加上沒有QA的加成，產出的品質只能說慘。不良的品質往往帶來整體專案進行時間的延長以及壓縮了其他專案的資源，是非常不好的惡性循環。
SA對於專案開發的掌握程度以及貢獻程度。
其實在兩種形式的公司內，SA都是可有可無的角色，乙方公司沒有的話一般都由PM、顧問兼任就完成了。但如果有配置SA的團隊來說，影響的程度可能就天差地遠。
配有SA的乙方公司，必需要SA的產品確認書撰寫完成以及跟客戶比對完，才能往下進開發，所以SA這段的產出品質對於到底程式能否完成佔有相當大的影響。
而甲方公司呢？由於RD也會參與討論，也會直接了解需求跟要呈現的樣貌，所以並不需要SA也可以往下進行。那如果有配置SA的情況呢？通常是會做一些輔助的工作，例如前期的可行性分析、製作泳道圖表達程式開發流程、幫助審閱API SPEC或Table Schema、製作知識管理的SA文件以便新人可以快速了解該功能等等。整體來說不是必要的角色，而是一個發揮輔助並讓長久運作可以更佳流暢完善的功用。
對於軟體開發的需求階段初步整理如上，後續文章會再討論其他階段內的差異及影響，如果對於上述描述有不同看法，也歡迎留言可以一起討論。
補充
動手寫這系列的文章，除了是希望做經驗的分享以外，也希望提供同為SA的你，可以重新思考一下自已的Career Path希望成為什麼樣子？是希望專精在ERP領域做一個遊走於各大公司的顧問？還是最終會希望深耕一個行業的領域，擁有自己的產品？
