# 軟體產品開發與工作流程

本篇為 [Lidemy [PD101]淺談產品開發與工作流程](https://lidemy.com/p/pd101) 課程筆記

**Progress**
<div class="progress" style="margin-top: 16px;">
<div class="progress-bar" role="progressbar" style="width: 100%" aria-valuenow="100"
aria-valuemin="0" aria-valuemax="100">
100%
</div>
</div>

----
### 學習目的
進入職場前，先大致了解：
1. 工作方法及流程
2. 一個軟體是如何被開發出來的
3. 因每間公司的流程可能不大相同，但可先有個初步概念
### 課程內容

1. 工程師的一天
2. 工程師怎麼知道要做什麼
3. 做完會部署到哪裡
4. QA 會怎麼測試
5. 怎樣算是完成

---
## 工程師怎麼知道要做什麼事情
PM 會根據以下工作流程產出需求，並告訴工程師
1. Stakeholder 提出需求
Stakeholder(利益相關者)，也就是客戶
2. PM 撰寫 spec (這功能長什麼樣子)
- Product Requirement Document(PRD) 產品需求文件
- Product Specifications 產品規格書

3. PM 畫 Wireframe
4. PM 將需求和 wireframe 整理出來，交給 Designer 產生 mockup（畫面長什麼樣子）
5. 交給工程師開發
根據第 2 和 4 點，開始寫 code

## Product Requirement Document(PRD) 產品需求文件
1. PM 須將每一個介面上的規格需求寫清楚，工程師會依照 PM 所寫的需求與規格進行開發。
2. 實際開發產品時，寫得越詳細的產品規格書，能夠幫助實際開發的內容與規格書達成一致。

### 範例 1[【SOP不藏私】系列＃EP1「連猴子也會的PRD指南」](https://medium.com/as-a-product-designer/sop-ep01-prd-3c6d33880c34)
- 文件概況
- 文件修訂紀錄
- 產品簡介與功能對照
- 產品簡介
- 產品目標說明
- 「工作排程、使用者故事、對應功能、進版時間」對照表
- 產品架構與流程
- 產品功能架構圖（Function Map）
- 產品信息架構圖（Information Architecture）
- 功能邏輯圖（Flow Chart）
- 產品設計原型
- 產品全局簡介
- 局部功能 Prototype，有互動的部分
- 產品指標
- 字串表
- 用來顯示多國語言

<div>{t('btn_register')}</div>

字典

const string = {
  en: {
    btn_register: 'Register'
  },
  
  zh: {
    btn_register: '註冊'
  }
}

### 範例 2 [PRD到底该怎么写？更全面的文档范例来了](https://www.woshipm.com/pmd/3327770.html)
1. 大綱：
- 修訂紀錄
- 全局說明
- 項目背景
- 透過現狀、方案、目標來描述
- 項目範圍
- 項目對應搭框架
- 產品結構圖
- 開發流程
- 功能需求
- 對功能逐一描述
- 透過使用者 + 功能方式來描述
- 配置條件、介面元素、產品邏輯、異常與分支流程
- 數據字典
- 非功能需求
- 數據、監控、性能需求

2. 功能需求/介面元素 範例：
當使用者在一個登入畫面，須在手機號碼欄位輸入內容(以台灣來說)
- 手機號碼需為0開頭，若不是填0，會顯示什麼訊息？如何顯示
- 最多會有幾碼，數字超過的話會畫面顯示出什麼訊息，會顯示在哪裡？會如何顯示？
- 按下發送驗證碼，若手機號碼輸入有誤，會顯示什麼訊息？會如何顯示？
- 按下登入後，手機號碼填錯或為空，會顯示錯誤訊息嗎？怎麼顯示？顯示在哪裡
- 按下登入後，若驗證碼錯物，會顯示什麼訊息？...
- 按下聯繫客服，會連到哪裡？要怎麼回來原本的畫面？...

- **介面元素**

| 元素 | 規則 |
| ------------ | ------------ |
| 手機號 | 1.文本框，必填，最多可輸入 10 位數字 2.必須為0開頭 3.錯誤提示：“手機號碼格式有誤，請重新數入” |
| 獲取驗證碼 | 1. 按鈕，點擊後開始倒數計時 2. 同一IP或同一手機好，五分鐘內最多可獲取5次，1天最多能發20次 3. 超限提示：“獲取次數超限，請稍後再試”|
| 驗證碼輸入框 | 1. 文本框，必填，只能輸入4位數字 2. 正確的驗證 3. 五分鐘內有效 4. 驗證碼錯誤提示：“驗證碼有互請重新輸入” 5. 驗證碼過期提示：“驗證碼已失效，請重新獲取驗證碼”|

- **介面流程**

| 步驟 | 用戶 | 系統 | 規則 |
| ---- | ------------ | ---- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | 輸入手機號 | | 1.文本框，必填，最多可輸入10位數字。 2.必須為0開頭。 3.錯誤提示：“手機號碼格式有誤，請重新數入”。 |
| 2 | 獲取驗證碼 | | |
| 3 | | 判斷是否觸發限制 | 1. 按鈕，點擊後開始倒數計時。 2. 同一IP或同一手機好，五分鐘內最多可獲取5次，1天最多能發20次。 3. 超限提示：“獲取次數超限，請稍後再試”。 |
| 4 | 輸入驗證碼 | | 1. 文本框，必填，只能輸入4位數字。 2. 正確的驗證。 3. 五分鐘內有效 4. 驗證碼錯誤提示：“驗證碼有互請重新輸入”。 5. 驗證碼過期提示：“驗證碼已失效，請重新獲取驗證碼”。 |
| 5 | 點擊登入 | | |
| | |是否已註冊？ |1. 根據手機號判斷是否有註冊。2.如果已註冊，直接登陸。3.如果未註冊，則自動註冊。|

#### 延伸閱讀[【產品經理 PM｜需求文檔 PRD】優惠券發放的產品設計，需求文檔怎麼寫？](https://medium.com/y-pointer/product-prd-ca0ea9b75b85)
## User story
#### [My Case study: User story-IA-Logic flow-Wireframe](https://hackmd.io/@ellielee/BJNMJ5een)

#### 以下非本課程內容，是自己的補充:
1. User story 的重點：
- 列出所有的功能
- 要寫到不可拆分為止
- 前面的目標，該如何轉化成一個個的功能
- 替所有使用產品的人設想好所有需求和情境

2. 公式：
作為一個　A　，我能 　B　，這樣就能 　C　。

- A：使用者在產品裡的角色(而不是他在現實生活是什麼人)
- 蝦皮（買家賣家）
- Facebook（一般使用者/版主/粉絲頁管理員/廣告主）
- 一般使用者
- 錯誤：~~我是一個穿搭愛好者~~
- B：(動態) 描述操作、行為，避免提及外觀
- 錯誤：~~我想要整理我的衣櫃~~
- 我想要展示所有衣物的清單，清單可以依照風格季節來分類
- C：(狀態) 描述行為的目標、所帶來的體驗

3. User Story 應為一個功能的基本構成，要寫到不可再被拆分才算夠細，但有時候寫多了會不好整理，因此可以依照以下例子的「兩階式寫法」來統合：

- Epic 1 (大條的稱之為 Epic，可做為一個標題)：
作為一個一般使用者，我能在動態牆 Po 動態，這樣朋友就能知道我的近況。
- Story 1-1 (小條的稱之為 Story，詳細說明 Epic)：
作為一個一般使用者，我能在動態牆 Po 文字動態，這樣朋友就能知道我的近況。
- Story 1-2：
作為一個一般使用者，我能在動態中標記朋友，這樣大家就知道我跟誰在一起。
- Story 1-3：
作為一個一般使用者，我能在動態中標記地點，這樣大家就知道我去了哪裡。
- Story 1-4：
作為一個一般使用者，我能在動態中表達心情，這樣大家就知道我的感覺。
## Card, Ticket, Task, Issue

1. 專案開發過程中，通常會把每個功能切割成一個任務，以下這些名詞均可代表工作的最小單位：

- Task：任務
- Issue：GitHub 上的一個問題或 Bug
Bug 可附上 reproduce step 說明或 Bug 截圖
- Card：卡片
- Ticket：票(通常一個 User Story 就會切割成一張票)

2. 用 Jira/Trello/其他類似的平台來管理任務，以下一項即是一個ticket

問題：
1. 工程師收到這張票，具體要做什麼事情？
2. 如果我是一個PM，我要如何 assign ticket?

## 軟體開發方法論 Methodology

### Waterfall
- Stage of waterfall
- 特性：
- 從上往下，不能往回，一次性
- 呈現完整性較高，完成時間較長
- 事前規劃需做完善，若過程中需要增加新功能獲改善，就需要再等下一輪流程，較無彈性
- 較不適合大型專案

### Agile


特性：
- 利用 MVP 快速迭代
- 快速且彈性高，可隨時調整需求，以適應快速變化的環境及市場需求
(我：改變應該要是容易的，且改變不能付出太高成本，不然會無法在快速變化的時代生存)
- 類似於把 Waterfall 的任務切小細分

參考資料：
- 可參考敏捷開發的 12 Principles: [敏捷宣言 12 原則](https://medium.com/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81-%E6%95%8F%E6%8D%B7%E5%AE%A3%E8%A8%80-12-%E5%8E%9F%E5%89%87-64ad7d592087)
- [Smartsheet](https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban)

## 實現 Agile 概念的方法
### Kanban Board
案例：Trello/Jira-Kanban board

### Scrum

#### Role
- Product Owner：決定產品走向
- Scrum Master：幫助團隊跑 Scrum 流程
- Team：實際開發的工程師

#### Steps in the Scrum Process

1. Product Backlog：列出產品所有功能
2. Sprint Planning：預估所需時間，分配任務
3. Sprint Backlog：這個週期要開發的功能
4. Sprint：開發週期（2-4 weeks 循環）
5. Daily Scrum meeting：Standup meeting 例行溝通進度
6. Review、Retrospective：檢視進度與Bug

案例：Jira

問題：
- PM 要如何決定這個 sprint 要做哪些 backlog?
-

## Scrum 在實際工作中的運作流程 aka 工程師的兩週生活 (2 weeks of Sprint Process)

1. 這裡以實際工作中為案例，通常以兩週為一個 sprint 開發週期，流程大致如下：

- Sprint planning meeting (W1-Mon)
- 預估任務時間 Story Point：
在正規 Scrum 中有強調要用“難度”估算，會用費氏數列作為計算單位；雖然有些公司會用小時去估算）
- Assign task

- 開發＋ Daily standup（W1-Mon to W2-Wed）
- Daily Standup：報告昨天進度、今天預計進度、Blocker(提出遇到的障礙)，藉此同步團隊進度

- Deploy 部署 (W2-Thu)
- 部署程式到測試環境
- Sprint demo (W2-Fri)
- PM 藉由 Demo 讓客戶瞭解目前進度
- Sprint retrospective 檢討會議
- Went well
- To improve
- Action items

2. 參考資料：[Retro tool](https://reetro.io/)

## Deploy 部署
`白話：把寫好的 code 放到某個環境，讓團隊人員可以看`

#### 部署環境
實際部署程式可分成幾種環境，藉由不同環境，能夠在過程中進行測試，確認功能都沒問題後再進行公開：

1. Local 環境：在本機端(Local)開發，放到本機環境，通常會接 Dev 的資料
2. Development 環境（Dev）
- 如果想要在真實的 sever 上測試的時候，就可以部到 Dev 環境，看看在正式的 sever上會是什麼樣子
- 和 Local 的差別：Loacl 是在自己電腦測試，Dev 是部署到 Server 環境
例如：Netlify
3. Staging 環境 / QA 環境
- 類似 Production 環境，可能會用 Production 的資料
- 僅用來測試，不對外公開的最新的版本
- 僅開發端看得到，使用者看不到
4. Production 環境：使用者可以看得到的環境，例如：Facebook.com

> 不同的環境就是不同的 Domain 或不同的 Server，舉例：
> - dev.lidemy.com
> - staging.lidemy.com
> - lidemy.com

## 測試
`題外話 Unit Test：指工程師針對程式碼進行的測試，與 QA 測試不同`

**QA 測試的目的**：測試功能呈現是否正常，共有下列兩種測試方式

- SIT（System Integration Testing
系統整合測試，確認功能是否正常，可能透過手動或寫自動化程式來測試

- UAT（User Acceptance Testing）
使用者可用性測試，通常是 PM 會進行測試，確認功能是否符合預期

- 補充： Smoke test, Regression test

## 總結

## 其他補充資料
[產品上線管理：寫給 PM 的基本名詞解釋與工作流程
](https://medium.com/3pm-lab/software-product-release-management-definition-and-workflow-e93075bd8ae)