我們學習的 HTML、Jav
aScript 主要用來製作 Web App「網路軟體 (web application)」，也就是在 web 環境中運行的軟體。
就像要完成一部電影需要編劇、演員、導演、攝影、美編、監製各種工作，歷經寫劇本、找場景、選角、拍攝、剪接，才能完成一部精彩的作品，「軟體開發」也是一個複雜且多人合作的過程。
現在，我們要來認識「軟體開發 (software development)」是怎麼一回事。
什麼是軟體 APP 開發
從 idea 到 software 是一個從無到有的過程，需要兼顧到很多因素，例如：
- 產品需要反映客戶腦海中的 idea
- 開發軟體需要能分工合作完成任務
- 軟體要能正常運作
- 要在期限內開發完成
- ⋯⋯
需要有一套軟體開發流程 (software development process)，來將這個複雜工作切成一個個可被解決的小任務。
點我免費領取非本科轉職工程師指南！
軟體 APP 開發的各個階段
軟體開發概略會分為以下幾個階段：
1. 需求分析
軟體開發的起點是來自某個人腦海中的抽象點子，這個人可能是你公司裡的某人，或者你的客戶，甚至是你自己。大多情況下，擁有 idea 的人不是你自己，如何傾聽使用者的「需求」並且轉換成軟體的規格，是整個流程最重要的起手式。
使用者需求是資訊系統開發過程中最關鍵、最重要且最容易發生錯誤的部分。客戶腦海中有一個 idea，但他們很可能無法清晰地表達需求，更不要說開出明確的「軟體規格」了。
因此，負責瞭解需求的人必須透過各種方式來「聆聽」客戶的需求，例如客戶訪談、問卷、案例研究等等，最後將客戶的想法轉換可被開發團隊執行的明確需求。
2. 設計
有了明確的需求之後，還無法開發寫程式碼，需要先規劃系統的架構，決定要用什麼工具來開發，在這個階段會定義：
- 資料庫的規劃
- 部署的硬體
- 作業系統
- 開發工具與相關技術
- 使用者介面設計
- 程式模組化的設計與 API
整個專案的執行項目會切得更詳細。
3. 程式碼實作
根據上個階段的設計去實際撰寫程式碼，嚴格來說只有這個階段與程式設計有關。
4. 測試驗證
測試有兩個目的：
- 功能運作是否正常
- 功能是否符合使用者的需求
5. 維護
軟體交件之後，通常不會這麼結束。客戶發佈產品之後，因應巿場的需求，通常會想要追加新功能，或者有一些漏洞在產品發佈後才發現。
這個時期需要考慮到產品已經運行，需要在不破壞既有使用者體驗的前提下來更新軟體。
開發模型
60 年代電腦發展以來，隨著人們的開發軟體的經驗累積，慢慢發展出一些「模型」，以下介紹Waterfall與敏捷開發兩種不同的模式。
經典的軟體開發模型： Waterfall
Waterfall 是最早出現的軟體開發模型，這個模型借鏡於製造業，特色是一路往前不回頭，每個階段產出交付給下一個階段，過程是不可逆的。
在 Waterfall 模型裡，每個階段的目的明確，有明確的職責分工，較適合一些需求明確或技術成熟的專案。
Waterfall 的特色是每個階段過了就是過了，不應該再回到上一個階段。所以當一個階段 close 的時候，負責人必須確定自己盡責的將階段產出交付給下一個階段的團隊。在這樣的精神下，Waterfall 的時程與成本預估比較精準。
然而，如果遇到了不確性很高的狀況時，不適合採用 Waterfall 模型。Waterfall 的風險在於要到 Verification 階段才會有可用的產品，也就是說，到這個階段才能了解客戶喜不喜歡你的產品。萬一在 Requirement 階段沒有正確地捕捉到客戶的想法，這樣的事情就會發生。
如果整體狀況的不確定性很高，團隊需要「邊做邊學習」，或者需要和客戶多次來回溝通時，有違 Waterfall 模型「一路闖關」的精神。因此，人們涉法在 Waterfall 模式加入更多的彈性，例如導入風險管理的 Spiral 模型，或是可以在同一個軟體追加功能的 Incremental 模型，以及我們後面會介紹的 Agile 模型。
希望沒有造成誤導，並不是說比較新潮的模型就比較好。如果是規模中等的外包案，例如專門承接網頁製作的公司或個人工作室，就比較適合時程明確、溝通單純的 Waterfall。
在模擬專案中跑 scrum，AC Twitter 專案幫你累積多人協作經驗
敏捷開發
與傳統的瀑布模型相比，敏捷開發重視開發過程與使用者的互動。敏捷模型 (Agile Model) 之所以叫「敏捷」，在於它強調快速拿出「最小可用的產品」 (minimum viable product, MVP) 來取得真實的使用者回饋。
敏捷的主要策略是縮短系統開發生命週期和縮小開發內容，從流程來看，敏捷開發與 Waterfall 的測試方法有很大的差別：
在敏捷開發中，每一次迭代都會經歷一個完整的軟體開發週期，因此在迭代結束後，會有實際可用的產品能發佈給使用者，蒐集真實的使用者回饋。例如下圖的對照：
若是在穩定、明確的環境中，分頭開發部件，再一次組製最後產品，也許能更有效率地管理成本與速度；然而若是面臨不確定的狀況，尤其是資源有限的新創公司 (startup) 往往一戰定生死，因此較常採用敏捷開發來進行 MVP 測試，一旦發現使用者不需要自己的產品，就需要立刻進行策略的大翻轉 (pivot)。
倡導敏捷開發的的軟體開發者甚至發佈「敏捷軟體開發宣言」（Manifesto for Agile Software Development）來強調敏捷精神：
- 個人與互動 重於 流程與工具
- 可用的軟體 重於 詳盡的文件
- 與客戶合作 重於 合約協商
- 回應變化 重於 遵循計劃
敏捷開發是一種精神、一種理念，落實在實務上會衍生出溝通與管理的工具，例如 Kanban、Scrum 等都是採用敏捷精神的實務架構名稱。
