Scrum入門手冊(4) - Scrum的開始

摘錄至 Scrum Primer
http://www.scrumalliance.org/resources/339

Scrum的第一步是讓產品負責人去清楚地表達產品的遠景. 最終, 這將逐步形成精確的, 並且優先順序決定好的功能列表, 我們稱之為產品backlog. 這個backlog存在(演進)於整個產品生命週期, 它是產品的路線圖(見圖2). 在任何時候, 產品backlog是一個單一, 明確的概觀, 來說明"任何團隊需要做的事情, 以優先順序排列". 並且只有單一一個產品backlog存在, 這意味著產品負責人必須先對整個東西, 做出優先順序的決定, 以表達出利害關係人的利益和所影響到的團隊.  

產品backlog包含許多項目, 主要是新的客戶功能(例如:"讓使用者能把要買的書放到購物車中"). 但是像是工程上的改進目標(例如:"重寫交易處理的模組, 以使其可擴展的"); 探索和研究工作(例如:"研究加速信用卡驗證的解決方案"); 和可能或是已知的缺陷(例如:"診斷和修復訂貨處理腳本的錯誤"), 如果缺陷沒有太多的話(如果一個系統有太多缺陷, 通常會用缺陷追蹤系統(defect tracking system)來記錄), 以上這些也會列入產品backlog中. 產品backlog可以以任何形式描述, 只要能清楚描述和好維護就好. 不過使用個案(use case)或是使用者故事(user story), 常被使用來陳述產品的backlog, 以表達他們的價值給產品的客戶.

產品backlog其中的一部份, 會變成要目前發佈版本的功能, 也就是所謂的發佈的backlog. 一般來說, 這一部分的主要焦點是產品負責人.

產品backlog不斷被產品負責人更新, 以反映客戶需求的變化, 新的想法或見解, 競爭的行動, 技術障礙的出現等等. 針對產品backlog中每個項目, 團隊會提供所需努力的評估給產品負責人. 此外, 產品負責人會負責對每個項目, 給定一個商業價值的評估. 對於產品負責人來說, 這是一個陌生的習俗. 因此, 這是Scrum Master可以幫助產品負責人, 學習怎麼做的地方. 根據這兩個評估(努力與價值), 以及可能的額外的風險估算, 產品負責人會排出backlog的優先順序(事實上,通常只有處理要發佈的backlog的部份而已), 來最大化投資報酬率. 或其次, 來減低一些主要的風險. 我們將會看到, 當人們得到一些經驗後, 這些努力和價值的估計, 可能在每次sprint都會被更新. 因此, 這是一個不斷重新確定優先順序的活動, 就像產品backlog一樣不斷的演進和形成. 對於產品backlog上的項目, Scrum 沒有定義要用什麼技巧, 來表達其內容或是排定其優先順序; 同時, 它也沒有定義任何評估的技巧. 一種常見的方法是用相對大小(relative size)來評估(主要是考量努力(effort), 複雜度和不確定性等因素), 它使用的單位是所謂的"故事點數", 或是簡單地只用"點數"來計算

隨著時間的推移, 團隊追蹤每次的sprint可以做多少工作. 例如: 平均每個sprint可以作到26個點數. 如果這個平均值能持續下去, 並且沒有任何改變發生. 有了這些資訊, 他們可以預測那一天是發佈日期, 可以完成所有的功能. 或者是在某一個固定日期, 有多少功能可以被完成. 這個平均值被稱為團隊的"速度". 速度和產品backlog項目大小的估算, 是用相同的單位來表示.

產品backlog中的項目, 他們的大小或是所需的努力, 可能每個項目之間差距非常的大. 在產品backlog改進的討論會,或是sprint規劃會議中, 較大的項目會拆解成較小的項目; 較小的項目也可能合併成較大的項目. 對於即將到來的幾個sprints, 其產品backlog的項目應該小一些,並且有足夠詳細程度, 讓這些項目是可以被團隊成員所了解, 使得sprint規劃會議所做出的承諾是有意義的. 而這樣的大小, 被稱作"可採取行動的"大小.

有關於Scrum的其中一個神話, 是它可以讓你避免撰寫詳細的規格. 但是在現實狀況中, 它是由產品負責人和團隊決定多少詳細的程度是需要的. 每個backlog的項目可能都不相同, 會根據團隊的洞察力, 或是其他因素而定. 只用最少的量, 就能描述出最重要的資訊 - 換句話說, 不需要描述每一個可能的細節, 只需要把需要的部份寫清楚, 讓它可以被人家了解就夠了. 優先順序較低的項目, 要很後面才會被執行, 通常只要有個簡略描述或是大方向就可以. 至於優先順序高的項目, 因為不久就要被執行, 所以必須要有更多細節被寫下來.

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()