自學滿三個月了，最近看到一個單詞 Scrum ，好奇心使然，想要一探究竟後，發現一環勾一環，從 Scrum 連到 Agile ，再從 Agile 連到 SDLC ，才發現原來一切都是有故事的！ 這次會先從 SDLC 去說明，發現 Medium 對於這個知識點的中文內容也較少，自己也想對這個知識有所了解，於是就產生這篇文章，此篇文章的內容與知識皆為閱讀 Software Testing Help 網站的 SDLC (Software Development Life Cycle) Phases, Methodologies, Process, And Models 整理，文章連結在此。
SDLC 中的傳統瀑布式開發
SDLC 包含兩種一種為 Waterfall Model，一種為 Agile Model。
SDLC 內容包含以下六階段，而 SDLC 中 Waterfall Model的 也是所謂的瀑布式開發，也就是說每一階段的 Ouptut 為下一階段的 Input ，階段性開發的意思，這一階段沒完成，下一階段無法開始。
- Requirement gathering and analysis：PM 必須出來引導說明客戶需求，以及 end-user 是誰，產品的目標與產品應具備哪些功能。此階段要產出 SRS (Software Requirement Specification)文件，顧客應 Review 後，才可進行到下一階段。
- Design： 依照 SRS 設計 architecture，應該就是系統設計層面，說明前端、後端要使用什麼技術，資料庫設計等等。
- Implementation or coding ：依照 SRS 與 Design document 進行開發。
- Testing：在 SRS 下對於開發的程式進行測試，改善 Bug 達到客戶要求。
- Deployment ：在 UAT (User Acceptance Testing) 環境下部署，並持續測試，直到拿到客戶的 Sign off。
- Maintenance：針對 SRS 文件下功能進行維護。
優點：每一階段任務定義明確，易進行專案管理
缺點：耗時，且當客戶需求不明確時，或是客戶需求有變動時，改善成本很高，且瀑布式不適合大型專案開發
SDLC 中的敏捷式開發 (Agile Model)
Agile 不是快速的意思，因為敏捷開發是結合 Iterative and incremental model，因此 Agile 具有快速迭代與快速衝刺( Sprint ) 的意思，敏捷開發也將產品切分為不同區塊，每一個區塊代表產品的特色功能，也就是 切分為不同 Features。
Sprint 短衝刺，通常週期為 1~4 weeks，每一個週期包含需求蒐集、設計、開發 Coding 與 測試 ( Testing )，也就是把瀑布式流程簡化，因應客戶突如其來的需求變化或是市場變更。
每一次 Sprint 後，Deliver 的產品功能，是要可以讓使用者操作的，也可以聆聽使用者反饋，快速 Applied 到下次的 Sprint 當中。
優點：可以快速適應顧客需求變更、增加新功能快速、顧客反饋馬上執行於下次的 Sprint 中
缺點：文件不嚴謹、團隊對於 Agile 熟練度與執行度要很高
職涯觀點與想法
對於 Agile 我有一些自己不同的看法，在科技業的產品開發流程的確還停留在瀑布式開發，一站接著一站，客戶需求確認後，才能進行產品設計，寄送 Sample ，產品規格文件初版產出後，才能進行試產，待產品規格書經由客戶簽回後，經由內部人員轉換成工廠語言，才產出生產線上的產品規格書，生產線上才能量產，中間其實我已經省略了許多科技業的文件、繁複的步驟與文書時程。
必須承認的確這樣設計比較嚴謹，可能也比較適合科技業；但事實上在量產上仍然發生許多問題，等到發生問題後，再去爭吵是哪一些階段出錯，這個產品量產出現了 A 狀況，但往前詢問得到的答案幾乎都是這個產品設計階段、試產階段都沒 A 情況，踢皮球的狀況到處可見。
我對於敏捷開發也有不同的期許，雖然我還未在軟體業工作過，但這個觀念我非常喜歡，站在工業工程的立場，瀑布式像是推式開發，這個產品有哪些功能、外觀怎樣、電路或是機構設計要如何，所以應該要有 A 時程 B 預算 C 機台 D 人力才有辦法達成。
軟體業的敏捷開發則是把一個產品拆成不同功能或是模組進行短週期的 Sprint 開發，也可以快速得到反饋，以工業工程來說，是一種推與拉的綜合式開發，例如：公司這個專案現在只有三個月的時程且只有三十萬預算，與顧客說明只能達到基本功能，但有反饋或是剩餘時間再進行額外設計與開發。
我也會在自我學習上利用 Sprint 與 Scrum 的概念，幫助自我成長。
─ 2019 年 10 月 4 日有感而發
