進到公司
第一課就是學軟體開發流程

Agile

基本上現在應該都是跑Agile(敏捷)開發吧？
但我覺得要談敏捷開發以前
要先來談談瀑布式開發(waterfall model)
我沒有在工作上真的經歷過waterfall
所以我只能講我的認知

根據維基百科
Waterfall 就是把軟體開發分成以下幾個步驟

1. 需求定義（Requirements）
2. 設計（Design）
3. 實作（Implementation）
4. 整合與測試（Verification）
5. 移交與維護（Maintenance）
   每個步驟都要好好的規劃且完成之後才能到下個階段
   所以最大的詬病就是當你一個產品完成之後
   早就不符合市場的需求了

於是乎
就誕生了 敏捷式開發
最常聽到的敏捷方法應該就是 Scrum
可能還有Extreme Programing (縮寫是ＸＰ）

什麼是敏捷

我想以我的個人經驗與理解來介紹敏捷 （或者說是 Scrum, 以下兩者會混用）
而不是從什麼高大上的角度來介紹有怎樣的會議 怎樣的角色
上了許多堂Scrum的課之後
我覺得如果太執著於到底什麼是Scrum的話
就會變成流於形式的四不像
以至於有scrum就是在開會的這種怨聲載道

如前所述
因為waterfall的流程太冗了
沒辦法即時反映市場需求
那還不簡單 就不要那麼長的開發時間啊
所以有這個詞 迭代開發（Iterative development）
不是像瀑布那樣一次流到終點不回頭
而是分很多次的小回圈來進行（稱作一個sprint）
所以每個回合可以動態的去調整這個sprint要做的task
其實我覺得這才是核心概念 其他都是因應這個出來的招數與概念（基本教義派不要打我）

Ｑ：那這樣是不用規劃的意思嗎？不用寫文件的意思嗎？
Ａ：都不對，
對backlog裡面的每個Task你還是要規劃怎麼實作 怎麼測試
不是說就不用規劃的去蠻幹
當然前置規劃與後續維護的文件也都要
測試要寫 要做
反正工程師的自尊是自己要維護的
迭代開發不是標準工程規範偷懶的藉口

對requirement的也是由PO去規劃以因應市場的變化
backlog也是會變動
而且理想上 客戶要進來參與就是

而且理論上每個sprint的產生必須都是deliverable的
不是給個半成品 為了達到這件事
為了幫助順利每個sprint的release
所以有了CI/CD, pari programming, TDD/BDD, Kanban, code review等等這些工程上的方法論來幫助順利開發

Ｑ：那跟隕石開發法有什麼不同？
Ａ：靠北工程師最愛抱怨的內容
原則上在sprint內決定好的task是不能變的
所以你隕石要砸下來 你也要給我等到這sprint結束
我下個sprint在排進去
當然一定有例外 比如說客戶的緊急issue, production server突然爆炸之類的 （這是很直得另外探討的議題）
不過 我是不覺得我有被隕石砸過就是（上述狀況例外）
不知道有沒有大大分享被隕石砸的經驗

Ｑ：ScrumMaster在幹嘛？
Ａ：ScrumMaster 就是要負責讓這個scrum順利進行而存在的角色 站在第三方的角度去看流程的問題在哪
我認為 ScrumMaster 的目標就是要讓自己消失
讓團隊自己即使沒有 ScrumMaster 也可以自己去發現問題之後在自己解決問題

Q：但我們團隊開發還是一團亂
Ａ：我覺得那不是什麼開發流程的問題了......
一個成功團隊的要點應該是要能檢討出問題並改進就是
所以要有retrospective meeting 但meeting不是重點
而是整個團隊願不願去面對問題並改善問題
這是文化問題 而文化有時候不是一蹴可幾的就是....

其實這牽涉的範圍太大我說不完
甚至包含團隊的組成（也就是招募）與管理了
但我始終相信
方法論是死的，團隊與人是活的
方法論是死的，團隊與人是活的
方法論是死的，團隊與人是活的
有時候不是方法論與技術的問題就是
有辦法能解決問題就是我們的價值
共勉之