前言

Scrum and XP from the Trenches (簡體中文譯名︰硝煙中的 Scrum 和 XP) 是我最近剛閱讀完的免費電子書。作者 Henrik Kniberg 在書中分享了他和他的團隊,實施 Scrum 的經驗和心得,內容相當實務而且有用,也相當輕薄好讀,我自己大概閱讀了幾個晚上就讀完了,因為我有在 Evernote 記錄讀書筆記的習慣,想說乾脆也順便貼上 Blog,在貼的過程中也算是幫自己再做一次觀念的複習。

因為第一章的內容比較偏向介紹,所以筆記的部份,會直接從第二章開始貼起。心得的內文有很大的部份都是剪貼自簡中翻譯版的譯文,只是照我自己的習慣做整理。如果我對簡中的翻譯名詞或語句不清楚,會再回頭去查看原文的內容,用自己的話再寫出來,但份量不多就是了。

當然還是很推薦直接去看電子書,收獲會更大,筆記只是摘要而已。

第二章、我們怎樣編寫 Product Backlog

  • Product Backlog 是 Scrum 的根本,由一群描述業務需求的 Story(故事) 所組成,並依照需求單位的優先順序(priority) 進行了排序。

  • Story 應該要是「業務導向」(business-oriented),每個 Story 應該描述的是業務目標,不應該有技術性質的 story。

  • 如果有用技術術語說明的 story,我們應該儘量去挖掘,這樣的技術說明,背後的業務需求是什麼?找出後,用業務術語重寫整個 story 的描述。

  • Product Backlog 文件,應該放在共享的文件資料夾中,讓大家都可以看得到。

  • Product Backlog 中,建議的欄位說明︰

    • ID (流水號)
    • Name (Story 描述)︰描述這個 Story 的需求和業務目標
    • Importance (重要性)︰以數值表示,數字越高越重要
    • Initial estimate (初始估算)︰以 story point (故事點) 來表示這個 Story 所需花費的時間
    • How to demo (如何展示)︰展示是 Scrum 中很重要的活動 (Activity),展示方式也關係到實作範圍、方式和複雜度
    • Definition of “done” (定義 Story 怎樣算完成?)︰對完成的定義也一樣牽扯到整個 Story 的實作範圍、方式和複雜度
    • Notes (註釋)︰story 相關訊息或參考文件的整理。
  • 在 backlog 中的 initial estimate 的 story point 的值,在撰寫時不要求精準無誤,只要讓團隊可以比較出不同 Story 的範圍、複雜度大小即可 (ex: 故事 A 的 story point 比故事 B 要來得高,則故事 A 要比故事 B 範圍上要來得大,或是實作上比較困難)。在後續的 Sprint Planning 中,對於 story point 會有更完整的估計方式。

  • Product Backlog 可能的長相︰

Baclog_Ex.jpg