# 軟工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，期望更早交出可用釋出版本、做後續需求討論及改正。