---
# System prepended metadata

title: '軟工W14 — 課堂報告: 老師及學長的建議'
tags: [敏捷軟體開發, 軟體工程]

---

# 軟工W14 — 課堂報告: 老師及學長的建議

###### tags: `軟體工程`, `敏捷軟體開發`

## [1] 
(目前 / 還沒進入第一個 sprint 之前)
sprint planning 只需要做第一格，後續三個(或更多)格子，等 sprint-1 結束再做就好。
因為初期需求可能會改動，以致後續 blocks 太早規劃沒有太大的意義。

## [2] 
product backlog 需求太多非功能性需求，應對【功能性需求】做更進一步的細化。

舉例: 
      
      檢索 => 標籤式檢索
              (~> 【UI-1: 圖片上傳按鈕】)

      搜尋 => 文字/影像
              (~> 【UI-2: 圖片上傳按鈕】
                   (按下按鈕，送出查詢 request)
                  【UI-3: 搜尋結果頁 / 顯示多個〈影像相似〉的商品】)

      推薦 => Item-based (=> Label-based (若有充足時間))
              (~> 【UI-4: 商品詳情頁 / 為您推薦 】)
              (根據〈推薦規則+用戶相關資訊(U/I/C)〉推薦關聯商品)

## [3] Release Planning & Sprint Planning

### (3-1) Release Planning
#### 會議目的：主要在定義某次 relase 的內容, 包含大改版和小改版. 
```
它主要在找出以及承諾以下項目
- 這次relase的goal
- 選出排好優先順序, 並且要在這次relase交貨的user stories
- 每個user story的粗略估計
- relase的日期
```
Release Planning 設計工具(延伸):
https://www.visual-paradigm.com/tw/scrum/what-is-scrum-release-planning/


### (3-2) Sprint Planning
#### 會議目的：會議目的是產生一份 sprint backlog（包含每個 story 細分之後的施工項目）讓 Developers 可以開工。
```
開始時間：每個 sprint 開始的第一天舉辦此會議。Teddy 的經驗是每雙週的週一（Teddy 採用長度為兩週的 sprint）早上 10:00 開始 sprint planning meeting。
參加人員：Product Owner、Scrum Master、Developers。

進行方式（1）：由 Product Owner 逐一詳細介紹這個 sprint 要施工的每一個 stories，並且與 Developers 互動，如果 Developers 對於 stories 內容不了解一定要發問。 介紹完之後 Developers 開始估計每一個 story 的 story point（story point 也可能在之前的 product backlog refinement meeting 就已經先估好了，但此時還是可以重估）。此階段通常需要 2-4 小時。
進行方式（2）：估算好 story point 之後，接著寫出每一個 story 的施工項目（task）。例如鄉民們要開發一個網路銀行的系統，有一個 story 是 As a user, I can view today's transaction records，那麼要完成這個 story 可能的 tasks 就有設計 UI、實做 UI 程式、寫 DAO（data access object，假設資料庫 schema 已經設計好了）、寫自動化功能測試等等。所有的 tasks 都寫好之後要開始估算完成每一個 task 所需的時間（以小時為單位）。此階段通常需要 2-4 小時。
```

## [4] Feasibility study 可行性測試
#### 學長分享，在 Scurm 的一個 Sprint 裡面，可以做 Feasibility study 評估這些規劃的 tasks 是否可行，學長在自身(SM => PO) 工作實務上也很常用。

#### 在另一堂課〈使用者研究〉的老師(曾任職 UX 研究員) 也分享到【可行性測試】這個方法。

Moreover, 有個方法叫【最小可行性測試】，旨在規劃 可負荷(affordable) 且 【最小可行】的初期 release，期望更早交出可用釋出版本、做後續需求討論及改正。