[week 19] 淺談產品開發與工作流程

本篇為 [PD101] 淺談產品開發與工作流程這門課程的學習筆記。如有錯誤歡迎指正！

透過這堂課程，我們能夠在進入職場之前，先試著瞭解開發流程，雖然每間公司實際工作情形不一定相同，但也能先有個初步概念：

課程內容也會以之前 Huli 和助教共同實作的 Lidemy 學習系統作為範例。

在實際開發之前

工程師會根據 PM 提出的產品需求來進行開發，而一個產品需求產生的流程如下：

stakeholder 利益相關者，也就是客戶
Product Requirement Document 產品需求文件
Product Specifications 產品規格書
wireframe 設計線稿
mockup 模型

接著工程師會透過 spec 瞭解產品需求，根據 mockup 寫出相對應的產品介面與功能。

Product spec 裡面有哪些東西？

實際開發中，寫得越詳細的產品規格書，能夠幫助開發內容與規格達成一致；假如 PM 沒有將需求寫在規格書中，開發產品也需同步進行，避免程式行為與規格不一致，導致後續維護問題。

一般而言，產品規格書屬於公司機密不能對外公開，這裡舉一些網路上公開的範例。

範例一：PRD 到底该怎么写？更全面的文档范例来了

修訂紀錄
全局說明
項目背景
- 透過現狀、方案、目標來描述
項目範圍
- 項目對應搭框架
- 產品結構圖
開發流程
功能需求
- 對功能逐一描述
- 透過使用者 + 功能方式來描述
- 配置條件、介面元素、產品邏輯、異常與分支流程
- 數據字典
非功能需求
- 數據、監控、性能需求

範例二：【SOP 不藏私】系列＃EP1「連猴子也會的 PRD 指南」

這個例子會比較偏向於介紹產品如何開發以及開發時程，說明產品規格書的文件架構：

文件概況
- 文件修訂紀錄
產品簡介與功能對照
- 產品簡介
- 產品目標說明
- 「工作排程、使用者故事、對應功能、進版時間」對照表
產品架構與流程
- 產品功能架構圖（Function Map）
- 產品信息架構圖（Information Architecture）
- 功能邏輯圖（Flow Chart）
產品設計原型
- 產品全局簡介
- 局部功能 Prototype，有互動的部分
產品指標
字串表
- 用來顯示多國語言

User Story 使用者故事

User Story（使用者故事）是一段簡單的功能敘述，藉由客戶或使用者的觀點寫下有價值的功能（functionality）。除了能更明確化產品需求，工程師也能夠知道客戶會做哪些驗收測試、期望跟假設。

在 User Story 中，對於一個需求的寫法大致如下：

As a user… 身為一個使用者..
I want to… 我希望…
so that I can… 我就可以…

以開發 Lidemy 作業系統為例子，這是初步的產品需求：

若以 User Story 方式撰寫，就能夠使產品需求更加明確化，也能瞭解不同使用者身份的需求以及開發順序：

繪製 Flowchart & Wireframe

此外還有像是 User Flow 使用流程和 Wireframe 設計線稿，也能幫助理解產品邏輯：

User Flow

Wireframe

繪製 Flowchart 時，也找了一些參考資料，瞭解該如何繪製：

先別急著畫 UI，你聽過 Flow Chart 嗎
Flowchart Templates | Editable Online or Download for Free

像是流程圖其實能透過規範的符號來統一：

試做有關會員的 User Flow：

DEMO 連結

Card = Ticket = Task = Issue

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

Task：任務
Issue：GitHub 上的一個問題或 Bug
Card：卡片
Ticket：票

通常會利用現成的平台，像是 Jira 或 Trello 來管理任務，通常一個 User Story 就會切割成一張票：

透過這些平台，能夠用來切割工作區塊，也能讓整個團隊快速瀏覽整體工作進度。

參考資料：

什麼是 User Story？
Agile 使用者故事
拆解使用者故事

軟體開發方法論 Methodology

在實際軟體開發過程，並不是拿了一張卡就開始工作那麼簡單，而是必須考慮透過哪種模式或框架來進行開發，大致可分成幾種方法：

Waterfall 瀑布流
Agile 敏捷

Waterfall 瀑布流

從上往下，不能往回，一次性
呈現完整性較高
事前規劃需做完善，若過程中需要增加新功能獲改善，就需要再等下一輪流程
較不適合大型專案

參考資料：

What’s the Difference? Agile vs Scrum vs Waterfall vs Kanban
【Podcast EP03】敏捷或瀑布開發哪個好？流程用哪種重要嗎？

Agile 敏捷

及早並持續地交付，精簡化
彈性較高，能夠改變需求
類似於把 Waterfall 的任務切小細分
按照 12 項原則就能夠稱為敏捷，又可細分為不同框架來進行

參考資料：

【文思不藏私】@敏捷宣言 12 原則
什麼是敏捷?
【敏捷系列 - 1】什麼是敏捷？敏捷實例分享

實作 Agile 概念：Kanban 看板

這裡以 Trello 和 Jira 平台為例：

Trello

Jira 平台的 Kanban Board

實作 Agile 概念：Scrum

透過 Scrum 的開發流程：

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

在實際開發扮演的角色：

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

參考資料：

Introduction to Scrum - 7 Minutes
【敏捷系列 - 3】Scrum 中的短衝 (Sprint)

工程師的兩週生活 & Scrum

這裡以工程師的生活作為範例，通常以兩個禮拜為一個開發週期，流程大致如下：

Sprint Planning
- 預估任務時間 Story Point
- 分配任務
開發與 Daily Standup
- Daily Standup：報告昨天進度、今天預計進度、提出遇到的困難，藉此同步團隊資訊
Deploy 部署
- 例如隔週會部署程式到測試環境
Sprint Demo
- PM 藉由 Demo 讓客戶瞭解目前進度
Sprint retrospective 檢討會議
- Went well 做得不錯的點
- To improve 要加強的點
- Action items 如何改善

參考資料：

協助做 retro 的工具

關於部署

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

Local 環境
- 本機端開發，通常會接 Dev 的資料
Development 環境（Dev）
- 和 Local 的差別：一個在自己電腦測試，另一個則是部署到 Server 環境
- 例如：Netlify
Staging 環境 / QA 環境
- 和 Production 類似，只是用來測試，不對外公開的環境
Production 環境
- 所有使用者都看得到的環境

關於測試

這邊提到的測試，和我們之前學到的 Unit Test 不同，是工程師針對程式碼進行的測試；但 QA 要測的只是呈現功能是否正常，簡單介紹下列兩種測試方式：

SIT（System Integration Testing）：系統整合測試，確認功能是否正常，可能透過手動或寫自動化程式來測試
UAT（User Acceptance Testing）：使用者可用性測試，通常是 PM 會進行測試，確認功能是否符合預期

結語

最後整理產品開發流程的幾個重點：

由 PM 提出產品需求給工程師
- spec 產品規格書：需要哪些功能
- wireframe 設計草圖：用來確認網頁架構
- mockup：由設計師根據產品規格做出模型
- 透過 User Flow、User Story，更明確寫出針對不同使用者、需要哪些功能、以及優先順序（例如：身為一個使用者/管理員，我希望可以 XXX）
實作 Agile 開發
- 在實際開發之前，可先在 Kanban（看板）列出產品所有功能，並以功能切割任務、預估所需時間
- 例如：Trello、Jira 等平台
實際開發流程
- 以 Sprint 開發週期為例，通常以 2-4 weeks 為週期，根據分配的任務進行開發，最後檢視進度並檢討如何在下個週期改善
- 可將各個產品功能加上編號，在 commit 時也加上相對編號，之後就能快速找到當初討論的 requirement