[原]敏捷開發-故事與估算

## 建立故事的時機

1. 由Scrum Master和Product Ower來寫故事。敏捷雖然是要提升你們的積極度或參與度，可是故事建立並不須要每一個成員都參與，若是都參與寫故事會形成故事風格不統一，對總體評估和說明反而不利。

2. 故事建立要提早。Scrum Master須要提早安排好下次迭代開發的故事，並把需求轉化爲故事，產品需求文檔和故事基本能夠同時送到團隊開發成員。咱們上次開發是，一塊兒過需求，而後給你們需求分析時間，而後列故事，對故事進行評估。這樣就形成一點很差，Scrum Master和開發人員同時拿到需求，都須要時間分析，而Scrum Master建立故事的時候，你們是沒事幹的，這個時間至少須要半天。因此Scrum Master須要提早把下次迭代的故事列到backlog裏面，下次迭代直接選取優先級高的故事開發，更有利也更合理。

## 如何建立故事

編寫好的故事，關注六大特徵 INVEST：獨立的 (Independent)，可討論的 (Negotiable)，對用戶或客戶有價值的 (Valuable to Purchasers or Users)，可估計的 (Estimatable)，小的 (Small)，可測試的(Testable)。咱們開發中的經驗是更注重，小的，獨立的，可測試的。
* 大的故事必定要拆分，別超過5天，不然故事到Done的時間過長，也不利於控制。
* 獨立的，避免故事之間的相互依賴，若是過大，按第一條拆分。
* 可測試的，表示對用戶有價值的一個流程，而不是經過頁面來劃分，很容易陷入這種模式，一個或幾個設計界面組成一個故事，這種看是明確的東西，其實隱藏了需求關聯性，也容易在開發中容易形成功能遺漏，比方說頁面之間的關聯功能。故事描述格式能夠寫做，做爲用戶，須要什麼功能，以便作什麼事情。比方說，做爲用戶需求登陸功能進入後臺管理。

## 時間預估

撲克牌，每人根據本身狀況得出一個天數
若是估算不一致，經過最多和最少估算人說出本身的估算方式，避免遺漏，也避免考慮過多
不須要把故事的需求細節瞭解的太細，並且不要把細節或實現方式放到估算會上，故事細節由用戶和開發人員討論得出。
預估是估算，不可能每一個故事都特別準確，但最終的總體時間是可參考的