工程師怎麼知道要做甚麼事？ PM 會告訴你
- stackholder 提出需求
- PM 撰寫 spec
- 畫 wireframe
- 交給 designer 產生 mockup
- 交給工程師開工
- product requirement document -> 產品需求文件
- product specifications -> 產品規格書
需求寫的才做，沒寫的請 PM 補，確保規格書與開發出來的東西是一樣的。程式行為與規格行為不一致會造成混淆，離職後讓後面接手的同事很難維護。
多國語言背後原理是透過字串表
user story
As a user, I want to ... so that I can ...
工作最小單位
- 卡片、票、任務，都是同一種東西
- jira software
軟體開發方法論
1. Waterfall 瀑布流
新的功能忘了做，必須等流程跑完再重來一次，沒辦法任意增加新功能。事前規劃做得好，很有效率。
2. Agile 敏捷
先做好一部分功能(經常交付可用軟體)，ok 再加新功能。小瀑快跑，快速迭代、快速找錯誤。
遵循 12 原則就可以是在跑敏捷
實現敏捷的實作 - Kanban（看板）
跟 trello 同一套概念。很多公司喜歡在牆上貼便條紙，基本上分三個：todo / doing / done
沒有嚴格限定部署的時間，有點像串流的概念。
優點：迭代速度很快、適應性高。
實現敏捷的實作 - scrum
scrum 裡面三角色
- product owner
- scrum master -> 幫助大家跑 scrum 的人
- team -> 工程師
sprint 表開發週期，通常兩個禮拜且不給插單，不像看板，看板沒有固定時間隨時都可以做任何事情。sprint 結束會統一將東西部署到測試環境。
一個 scrum 也可能各自表述
deployment
- local 環境(本機)，通常接的會是 dev 的資料，在自己電腦做測試
- development 環境(dev)，想在真實 server 上測試東西就會部署到這裡
- staging 環境 / qa 環境，像 production 環境的地方讓 qa 可以測試。不對外公開的最新版本。
- production 環境，外面看到的
不同環境就是不同 domain 不同 server。
測試
- SIT (System Integration Testing)：系統整合測試 -> 確定功能是否有錯
- UAT (User Acceptance Testing)：實際使用是否符合預期
