Scrum – Backlog、User Story & Meeting

Scrum – Backlog、User Story & Meeting

此篇文章記錄於 Scrum 敏捷軟體開發方法工作坊 學習的心得記錄,內容囊括 Scrum Framework 之中 Backlog、User Story & Meeting 的介紹。

產品需求清單 Product Backlog

產品需求清單是一個根據 Business Value 來排序的清單,這個清單會由 Product Owner 去持續的更新排序、依據客戶需求持續新增清單列表。

而這個列表中的項目又可分為:需求(Use Case、User Story)、Error / Bug、技術債(Tech Debt)、Tech Evaluate(概念性證明 Proof Of Concept)。

使用者故事 User Story

以便利貼來寫上 User Story,通常由使用者描述(雖然使用者自己也不知道自己要什麼)。User Story 就是以 Story 來描述產品的需求,例如:

As a bookstore customer, I can search for book by the title, So that I can easily find all books with that title.
- User Story Example 出自工作坊教材

這種 User Story 又可以分為:功能性需求(Functional Requirement)、非功能性需求(Non-Functional Requirement)。

功能性需求

Functional requirement user story 代表使用者期望的需求,且這個需求比較偏向產品的功能性,像是:

我希望售票網站能夠擁有信用卡刷卡付費的功能。
- 工作坊實務操作當中,我與組員一起寫出的 User Story

以這種方式來表示出使用者的需求,而因為我們的 User Story 寫在便條紙上,以白板筆書寫方便觀看,所以能寫的字十分有限,最後只會寫上「信用卡付費」。

非功能性需求

Non-functional requirement user story 則代表需求較偏向使用者所期望的產品能有一定的品質,像是:

我希望售票網站能夠支援 IE Browser
- 我與組員一起寫出的 User Story

我希望售票網站能夠同時承受 25000 人一起上線使用
- 我與組員一起寫出的 User Story

我希望售票網站一整年當中的上線率是 99.999%
- 我與組員一起寫出的 User Story

相信一看就能夠知道功能性需求與非功能性需求的差異在哪裡了。

User Story 總結

User Story 只是幫助 User 與 Dev Team 溝通的工具而已,而 User Story 有大有小,拆解 User Story 也是一門學問,可以參考 How to Split User Story 一文所述。

User Story Mapping

在這個小節,只能以文字敘述過程,需要腦補想像應該要怎麼實作,但是並不會太困難。

首先,我們需要把所有貼在桌子上的 User Story 撕下,根據使用產品的流程來分類,例如在 售票系統 之中,我們的產品使用過程便會如下:

  • 訂票
  • 付款
  • 取票
  • 退票
  • 非功能性需求(並不在流程中,但是還是需列入)

以上就是我們產品使用步驟的 Title,接下來分門別類,把 User Story 規劃到這些項目之下:

這邊的例子將以臺灣高鐵(Taiwan High Speed Railway)的售票系統舉例

  • 訂票
    • 選擇日期、地點、時間
    • 選擇座位靠窗或靠走道
    • 訂購回程票功能
    • 優惠票種(敬老票、學生票、身心障礙票)
  • 付款
    • 信用卡付款
    • 超商付款
    • 臨櫃付款
  • 取票
    • 手機 APP 取票
    • 超商取票
    • 臨櫃取票
  • 退票
    • 臨櫃退票
    • 手機 APP 退票
  • 非功能性需求
    • 支援 IE 瀏覽器
    • 同時承受 5000 人使用
    • 同時承受 25000 人使用
    • 同時承受 100000 人使用
    • 訂票網站服務上線率 99.999%

將我們的 User Story 分類完之後,還需要去分 Release Time,我們不可能在一兩個 Sprint 之後就把所有 User Story 全部做完,在之後也會講到關於開發時程估計的方法。

因此我們會把所有 User Story 切分為幾個不同的 Release 階段,每一個階段都會完成部分的 User Story。

Release 1

為了打造 最小可行性產品集合(MVP,Minimal Value Product),我們會先挑選部分 User Story 作為 First Release。講求做出 Walking Skeleton(只是骨架就走到市場去試水溫,調整產品方向),所以可能我們的 User Story Mapping 會像是這樣子:

  • 訂票
    • 選擇日期、地點、時間
  • 付款
    • 臨櫃付款
  • 取票
    • 臨櫃取票
  • 退票
    • 臨櫃退票

Release 2

到了第二次的 Release 就可以補全下一個階段,Product Owner 認為較為重要的功能。

PO 挑選 User Story 時,應該優先挑選價值最高的 Story:

  • 訂票
    • 選擇日期、地點、時間
    • 選擇座位靠窗或靠走道
  • 付款
    • 信用卡付款
    • 超商付款
  • 取票
    • 手機 APP 取票
    • 超商取票
  • 退票
    • 臨櫃退票

以此類推,後面則不再贅述。

Scrum Meeting

敏捷評估

在產品開發初期時,應該要由 PO、SM、Dev Team 來對於發佈產品的時間與內容作估算,同時也需要對 User Story 做估算時程。

  1. 專案的完成條件
  2. User Story 評估
  3. Sprint 週期長度
  4. Dev Team 開發速度
  5. User Story Priority
  6. 選擇要做的事情

至於在評估 User Story 的時候,有一種叫做 Story Point 的評估方式,我們會以 [1, 2, 3, 5, 8, 13, ...] 的數列來針對幾項 User Story 作為評估。

至於選擇 [1, 2, 3, 5, 8, 13, ...] 的原因是因為,在決定故事複雜度時,若以 [1, 2, 3, 4, 5] 來計算,則不易分辨出其相對難易度,因為難易度的距離太接近了。

而這時會使用 Playing Poker 的方式,由 Dev Team 來互相決定這一個 User Story 的複雜度,舉個例子:

想要實作信用卡刷卡付費的功能

而 Dev Team 的六個人同時說出自己認為此項 User Story 的完成難易度,假設大家的結果為:[3, 5, 5, 8, 8, 13]

這時則由點數最低的 3,這位工程師來表明為什麼認為信用卡付費功能很簡單,像是:

因為信用卡付費應只需串接銀行 API 就能夠實作了吧?

在此同時,點數最高的 13,這位工程師也必須說明為什麼認為此 User Story 的複雜度這麼高:

因為我沒有實作過串接金流服務,而且銀行只會有一家嗎?這感覺很複雜

大家聽完原因之後,就進入第二輪,再次出完數字,並以多數決來決定這個 User Story 的難易度。

發佈規劃

決定好各 Feature 的難易度之後,就挑選一個中間值的 Feature 來估算時間:

  • f1: 3
  • f2: 2
  • f3: 5(中間值,由 Dev Team 估算需要多少人天來完成)
  • f4: 8
  • f5: 13

藉由 f3 為基底,計算其他 Feature 的耗費時間。

然而,這並不會準確,但是比 PO 自己拍版決定開發時程好多了,且也能夠運用實際開發時間來估算總時程。

Feature Size Est Time Iter Act
f1 3 15 1 18
f2 2 10 1 12
f3 5 25 2
f4 8 40 3-4
f5 13 65 5-7
Total 155 7

在發現 f1 估算 15 人天,但實際上卻耗費 18 人天才完成時,我們能夠利用簡單的乘法:155 * (18 / 15),就能夠推出實際上可能需要多少時間才能完成。

而在 f2 也完成時,也能夠再次計算:155 * (30 / 25) 來得到更接近真實情況的時間。

Sprint Plan Meeting

但是不僅如此而已,在 Sprint Plan Meeting 時,我們需要把一個 Feature 切分為更小的 Task 去估算,而這邊時常會把任務想得十分美好,在此列出幾個很重要的重點:

  1. Tasks 之間有 Dependencies
  2. Cross Functional
  3. Task 的 Size 應控制於 1 ~ 2 天完成
  4. 可以考慮使用 Task Template
  5. 有些較特別的 Task 都會被無視(或因假設條件忽略)
    • Continuous Integration
    • Infrastructure
    • Task Integration
    • Testing

像是在思考 訂票功能 時,往往會直接認為就只是寫一個 Backend,開 API 給 FrontEnd 使用,只需要去操作資料庫,Query 出空位,並 Insert 資料進去 Database 就可以了吧?

但實際上,我們的 Database 架構也需要考慮、主機環境部屬也要考慮、網頁介面 UI 也需要設計,並不是一切都如同表面上這麼美好。

而這也是因為將 User Story 細切為 Feature,再細切為 Task 的盲點,只需要妥善考慮以上所說的那些問題,當然還需要考慮兩個 Task 之間整合起來能否運作等問題,就不會有估計時間與實際開發時間大大偏差的悲劇發生了。

Daily Scrum Meeting

每日立會則沒有太多需要講的,只需要在 相同時間相同地點 開會,並控制在固定時間內,且在 Meeting 中只需提出:我昨天完成的項目我今天要做什麼我有碰到什麼問題,不需要在當下馬上解決問題。

Scrum Review Meeting

這時就是全員出動的 Meeting 了,從 PO、SM、Dev Team 以外,當然還有 Customer。

由 RD 來 Demo 給大家看,以下是一些 Demo Tips:

  1. Story based
  2. Using real data
  3. Don’t use hotkeys(不然別人不知道你做了什麼)
  4. Performance Test Report
  5. Windows update 先做好 / Personal data 藏好

以上大概就是較為重要的重點整理了,這門課帶給我的收穫十分豐盛,雖然現在除了 OpenSource Project 以外,還沒碰到和別人 co-work 的時候,但希望這些經驗與知識能夠讓之後的開發更順利 ( ´ ▽ ` )ノ

Leave a Reply

Your email address will not be published. Required fields are marked *