工程師怎麼知道要做甚麼事？ PM 會告訴你

1. stackholder 提出需求
2. PM 撰寫 spec
3. 畫 wireframe
4. 交給 designer 產生 mockup
5. 交給工程師開工

• 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 裡面三角色

1. product owner
2. scrum master -> 幫助大家跑 scrum 的人
3. team -> 工程師
   sprint 表開發週期，通常兩個禮拜且不給插單，不像看板，看板沒有固定時間隨時都可以做任何事情。sprint 結束會統一將東西部署到測試環境。
   一個 scrum 也可能各自表述

deployment

1. local 環境(本機)，通常接的會是 dev 的資料，在自己電腦做測試
2. development 環境(dev)，想在真實 server 上測試東西就會部署到這裡
3. staging 環境 / qa 環境，像 production 環境的地方讓 qa 可以測試。不對外公開的最新版本。
4. production 環境，外面看到的

不同環境就是不同 domain 不同 server。

測試

1. SIT (System Integration Testing)：系統整合測試 -> 確定功能是否有錯
2. UAT (User Acceptance Testing)：實際使用是否符合預期