敏捷開發——User Story

敏捷開發流程：

一、咱們首先須要肯定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

二、Scrum Team根據Product Backlog列表，作工做量的預估和安排；

三、有了Product Backlog列表，咱們須要經過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story做爲本次迭代完成的目標，這個目標的時間週期是1~4個星期，而後把這個Story進行細化，造成一個Sprint Backlog；

四、Sprint Backlog是由Scrum Team去完成的，每一個成員根據Sprint Backlog再細化成更小的任務（細到每一個任務的工做量在2天內能完成）；

五、在Scrum Team完成計劃會議上選出的Sprint Backlog過程當中，須要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每一個人都必須發言，而且要向全部成員當面彙報你昨天完成了什麼，而且向全部成員承諾你今天要完成什麼，同時遇到不能解決的問題也能夠提出，每一個人回答完成後，要走到黑板前更新本身的 Sprint burn down（Sprint燃盡圖）；

六、作到每日集成，也就是天天都要有一個能夠成功編譯、而且能夠演示的版本；不少人可能尚未用過自動化的每日集成，其實TFS就有這個功能，它能夠支持每次有成員進行簽入操做的時候，在服務器上自動獲取最新版本，而後在服務器中編譯，若是經過則立刻再執行單元測試代碼，若是也所有經過，則將該版本發佈，這時一次正式的簽入操做才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

七、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，咱們要進行 Srpint Review Meeting（演示會議），也稱爲評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每個Scrum Team的成員都要向他們演示本身完成的軟件產品（這個會議很是重要，必定不能取消）；

八、最後就是 Sprint Retrospective Meeting（回顧會議），也稱爲總結會議，以輪流發言方式進行，每一個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；

user story 定義：

Story就是一個可測試的小功能點（Story：功能點=1：1）、或者是多個繼承性的小功能點組成的一個Story（Story：功能點=1:N）、或者是一個沒法再分割的功能點（再分割這個功能點就沒法進行測試了）包含多個Story（Story：功能點=N：1）。

1、Story

Story最原始的目的是指導開發工做量的劃分，Story是將一個大的特性劃分紅小顆粒度的功能塊，方便分配工做量，以便得到快速反饋；

2、特性：

敏捷中的特性相似於在雙V模型或者其餘模型中的子系統、子模塊或者說是較大的功能模塊，是由不少的功能塊組成的，一個特性是耦合度很高的子模塊；

3、功能塊：

敏捷中的功能塊相似於雙V模型或者其餘模型中的較小的模塊，從子模塊裏劃分出來的較小的功能模塊，是由不少的功能點組成的；

4、功能點：是不可再分割的可測試的小功能模塊；

5、特性團隊：

特性團隊是指由設計人員、開發人員、測試人員、資料人員、特性團隊組長等人一塊兒組成的一個完整的團隊（7人左右），特性團隊是按特性進行劃分的團隊，團隊成員對該特性的交付全權負責

6、頭腦風暴：

由特性團隊中全部成員一塊兒就一個Story的方案、設計、用例設計、驗收標準等內容而進行的團隊中的討論會，以澄清Story的設計，用例，測試驗收標準等；

7、Story驗收標準

每個Story都須要在進行頭腦風暴時，由團隊裏的人一塊兒制定該Story的驗收標準；

Story劃分時以測試功能點做爲依據，實現Story與功能點的融合，測試時基於功能點進行設計測試用例，開發基於Story進行開發。