Waterfall
一般瀑布式(Waterfall) 是最常見的開發模式，開發流程是由 PM 先規劃完整的功能與細節，然後再交由 Designer 來做畫面的設計，接著交給 Frontend Engineer 開發出前端的 Templates ，也就是 HTML, CSS, JavaScript .. 等，最後由 Backend Engineer 來開發後端功能，並整合前端的 Templates。
這個開發過程可以用下面簡單的甘特圖來表示：
Scrum
另一個最近很流行的開發模式為敏捷式 Scrum， 首先我們會把專案相關的人員集合在一起，大約 5 ~ 8 個人左右，這一群成員中包含了 PM , 前後端工程師，設計師，測試人員等，並且把開發時間切分成兩週一個單位，每個單位稱之為一個 Sprint ，而每個 Sprint 都算是一個小小的 Waterfall ，其中包含了需求定義，設計，開發，測試等工作，在每個 Sprint 一開始時，要先規劃本次 Sprint 的工作內容，結束的時候要 Demo 成果，以及每個成員要分享這次 Sprint 的心得，改善方式等。
左圖則是每個 Sprint 要做的事。
- Planning ： Sprint 一開始 PM 會跟所有成員討論這次 Sprint 的工作項目與範圍。
- StandUp ： Sprint 當中，每天要花十分鐘讓所有成員說明重要的事。
- Demo： 跟 PM 展現這次 Sprint 的成果。
- Review：討論這次 Sprint 的優點與缺點，是否有哪些地方可以改善。
兩種開發模式都各有優缺點， Waterfall 的最主要缺點是開發時間長，一個大型專案從需求定義完成到測試結束上線，有時候甚至會超過兩年，另外 FrontEnd Engineer 開發完第一個專案後，馬上就得進入下一個專案，但這時，第一個專案還尚未結束，Backend Engineer 也還在開發與整合中，一旦有測到 Bug， FrontEnd Engineer 又得立刻下海來幫忙，變成同時處理兩個專案。；不過 Waterfall 有個最大的優點，就是分工清楚，乾淨，開發模式簡單，不用學習也知道這個開發流程。
Waterfall 優點
- 專案的架構、需求，在開工前就製定完成，細節清楚明白，工程師在開發的過程會很順暢。
- 不用花太多時間來溝通，只要需求寫得夠清楚，工程師就能很快的完成工作。
- 不用學就會的開發方式。
- 分工清楚，工作起來也比 Scrum 單純。
Waterfall 缺點
- 開發時間很長，中間沒有任何斷點，只能一直死命的做到專案結束。
- PM 能力不能太差，因為專案規劃是越完整越好，時程安排也要流暢，如果 PM 做得不好，在開發的過程中不斷修改需求，釐不清楚需求，這會卡死專案時程，工程師則是做完了又改，改了再重做，工作效率會變得很差。
- 同 Team 的成員沒辦法同時開發，同時結束，有些成員會同時處理多個專案，例如設計師完成第一個專案的設計後，會馬上接著做第二個專案，若這時第一個專案要補頁面，Icon 等等需求，會造成設計師得分心來同時兼顧兩個專案。
- 越底層的人員，越沒有發言權，因為你接到的工作，都是高層討論完的結果，你唯一要做的就是盡快完成它。
Scrum 優點
- 專案分階段完成，完成一小部分就立刻推出產品，產品可以快速上線。
- Scrum 可以解決這種需求不明確，或是功能變動幅度大的專案， Scrum 本來就是訴求邊做邊設計，一步一步完成，完成的部分就可以先上線。
- PM 不用很專業，需求不用說得很清楚，因為每個 Sprint 都會大家一起討論功能，Scrum 這個開發模式，很適合用在團隊中的 PM 沒什麼經驗 ，因為沒有經驗的 PM 無法製定出完整清楚的需求，這時就可以透過 Scrum 的精神，在 Sprint 當中，每個成員都能夠對該專案提出建議並確定功能。
- 團隊內的成員都有機會發表意見，工程師可以提出對 UI 的看法，設計師也可以提出需求的意見。
- Scrum 可以解決這種需求不明確，或是功能變動幅度大的專案， Scrum 本來就是訴求邊做邊想，一步一步完成，完成的部分就可以先上線，所以很適合還沒有完整規劃的專案，或是不懂得規劃的團隊。
- 團隊內同時存在不同領域的人才，很方便討論各種跨領域的需求，例如前後端工程師，可以一起討論如何開發一個新 Feature ， QA 與 RD 也能一起討論測試的方式與工具，有些大公司分工太細，各領域人才沒有良好的溝通管道，這時一個聚集各方面人才的 Scrum Team ，可以加快溝通的時效性。
Scrum 缺點
- Scrum 精神不容易在傳統公司中實作出來，每一個階段完成的工作，根本就上不了線，因為大部分的老闆都希望專案做得很完整，一推出就大受好評，不願意做一半的產品就推出去。
- 需求變動大，程式改動的幅度也很大，所以不適合一開始就寫太完整的 Unit Test，而在未來也很難找到機會回來補 Unit Test 。
- 花太多時間在開會， Review，影響工作情緒，每天早上都會花十分鐘快速說明有什麼狀況，根據經驗常常都會超過十分鐘(個人建議可以直接取消每天的 Stand Up)。
- Scrum 模式有點夢想化，實際上根本就做不太到。
我覺得 Scrum 開發模式可以讓團隊中的每一個成員，「一起開始，一起結束」，這是非常好的想法，每個人的工作目標是一致的，進度也是一致的，成員的向心力遠大於 Waterfall 開發方式，但是成員的能力跟 scrum 的運作有很大的關系，例如 PM 只能參與規劃，設計，測試，當專案進度已經到的程式撰寫，那麼 PM 會沒有事情做，同樣的狀況也會發生在設計師，所以 Scrum 開發比較適合團隊內每一個成員能力相似，例如 Backend Engineer 都是 Full Stack Engineer ， PM 本身也懂得寫技術文件，能夠幫忙寫 Library or API Document ，設計師也要懂得 Front-End 的開發或是自動化測試工具，而且每個人要願意去學一點不同領域的知識，如果團隊的成員編制沒辦法達成能力一致，那 Scrum 的開發最後還是會變成 Waterfall，這就一點意義也沒有了。