David Ko的學習之旅

User Story的細節呢?
很多人會說這樣的一句話，怎麼足夠表現出需求詳細的內容呢？很多細節我們還是不知道。那到底要怎麼辦呢？
其實User Story的重點是在於溝通。也就是希望程式設計師和顧客好好坐下來，一起談論想要的功能是什麼，想要拿它來解決什麼問題。也就是真正去了解整個來龍去脈，而並不是花時間去把文件寫的盡善盡美。所以這句話只是開頭，接下來的交談才是重點。

使用者故事(User Stories)
前面談完Product Backlog，可是我們並沒有說明要如何撰寫Product Backlog。在Agile中我們通常是以一個叫User Story的東西，來描述Product Backlog的內容。
這也就是說，你是可以以別種方式來描述Product Backlog的內容，例如use case或是傳統的需求規格書。Agile並沒有做限制。

Product Backlog所面臨的問題

1. Product Backlog的來源有很多個
一般來說，資料的來源有以下幾類：
(1) 產品功能：在這一次版本中需要實作的功能。
(2) Bug：上一版或是上一個循環(iteration)所遺留下來的問題，需要在這一版處理。或者是對客戶端有嚴重的影響，要求緊急處理的問題。
(3) 技術上的負債(Technical Debt)：有關於技術上的問題，例如執行速度太慢、無法容易擴充、使用介面不好操作、或者不方便日後維護等等。不算是bug，但是若是能修改，會對專案日後有很大幫助。(有些客戶會認為速度太慢，其實也算是bug)

Product Backlog
在專案一開始時，需要有一份要處理的工作項目。在傳統專案中，我們會使用需求規格書，或是者是使用個案。可是在Scrum的軟體開發中，我們使用的是Product backlog這個東西。你會問說這又是什麼新的名詞呢？讓我們來看看大家怎麼定義它：
A. Wiki上的定義
- 對於整個專案來說，它是一個較高層次(high-level)的文件。
- 包含了所有想要功能的描述，或者是wish-list等等。
- 是根據商業價值來排定優先順序
- 它列出了“什麼”東西要被建構
- 它是一份公開並且是任何人可以來編輯修改的文件，每個項目有對應的大約商業價值，以及所需的開發代價
來源：http://en.wikipedia.org/wiki/Scrum_(development)

功能, 時程, 和成本
在專案管理中, 功能, 時程, 和成本, 一直是最重要的三個要素, 也是不容易取得平衡的三個要素. 因此你可以看到你的專案經理, 常常痛苦掙扎要如何在三者間取捨, 到底要犧牲那幾個, 保留哪幾個.
傳統的一種作法(waterfall)是將要交付的功能固定, 然後在成本和時程間做調整. 主要是以計劃導向(plan-driven), 來導出時程和成本的規劃.