http://www.infoq.com/cn/presentations/qac-agile-requirement-analysis/ —— 錢安川
需求分析貫穿整個項目生命周期午乓，需求分析和管理
一抑淫、需求分析的階段 —— 重點是和客戶交流、提問、確認想法——信息交換——達成一致
* quick start （會議）| 2-4周 | 識別需求呼伸、規(guī)模，識別客戶業(yè)務目標闻坚、價值 |產(chǎn)生一些 must user story（粗粒度）
? ? 1. 目標：愿景和動機妆丘，快速產(chǎn)生需求列表，可視化的項目需求原型技竟，（了解技術風險冰肴，驗證可行性——TL），初步成本估算（財務模型），發(fā)布熙尉、迭代計劃——計劃是基于目前認知的联逻，輕量的可視化文檔，業(yè)務流程圖（非常重要）
? ? 2. 交付物：技術架構圖检痰，平臺包归，界面原型，功能分解圖（must User story）
* 發(fā)布計劃階段：對高風險需求的可行性分析
* 迭代：需求細化铅歼，每個迭代會納入新的需求
* 實施：反復驗證需求公壤，確認需求能夠被實現(xiàn)
* 發(fā)布Release
動態(tài)的工作計劃。是非線性的椎椰，迭代重新審視需求列表厦幅，優(yōu)先級
人員配置：5（團隊人數(shù)）+1（BA）/ 10+2
2. 如何表述需求：user story卡片，每個卡片是一個user story
3.
二慨飘、用戶故事結構：
#102 ——? us編號
注冊用戶 ——屬于哪個功能模塊的分類
一句話表達作為一個用戶确憨，我的用戶資料被系統(tǒng)的記錄下來，以便我能享受到個性化的待遇——US通常為該模式的一句話話
作為 XX（角色）套媚，我希望……（系統(tǒng)能夠實現(xiàn)...）缚态，以便……（達成某業(yè)務目標）。
估算點數(shù)（大械塘觥）——一般為1 2 4 8 16
US 優(yōu)先級
三玫芦、用戶故事原則：
1. 站在用戶角度，用用戶語言描述
2. 3C原則本辐，卡片本身代表了一個需求的存在桥帆，它是一段多角色對話（conversation）和交流的橋梁，confirmation確定性慎皱，驗收條件（完成的標準）和范圍是什么要定義清楚
3. 如何表達用戶故事XYZ
x 用戶
y 功能 ——實現(xiàn)的一種途徑
z 價值 —— 真正業(yè)務目標
另一種方式ZXY老虫，突出價值
4. 如何產(chǎn)生用戶故事：常用方式叫角色流程方法，識別用戶角色茫多，和用戶在一起討論他們目前的流程是什么樣的祈匙，未來的流程是什么樣的，形成角色流程圖天揖，根據(jù)業(yè)務流程圖切分User story
為了我能快速購買我想要的書夺欲，作為用戶我希望能夠通過書名和作者名去查找書籍
為了我能批量的購書，作為用戶我希望把我感興趣的書籍加入購物車
為了方便我做出購買決定今膊，作為用戶我希望我能查看我購物車里的書
5. 如何寫一個好的用戶故事些阅，評價、鑒定斑唬、督促原則
I - independent 可以獨立開發(fā)的 —— 現(xiàn)實中可能有依賴關系市埋，在迭代計劃時要考慮依賴關系
N - negotiation 對客戶來說可協(xié)商黎泣，價值不會變，但選擇最優(yōu)的實現(xiàn)方式可協(xié)商
V - valuable 有業(yè)務價值的
E - evaluative 可評估的缤谎，大小可評估抒倚。若不可評估說明一定問題，技術不確定性坷澡，遺留系統(tǒng)衡便，需要和技術人員討論進行spark
S - 合適的粒度，大小合適洋访，1/2/4個點的，短時間的谴餐，開發(fā)節(jié)奏
T - 可測試姻政、驗證的，US完成之后用戶能夠有可視化的業(yè)務價值（除了業(yè)務story岂嗓，還有技術US汁展，用戶可能不可見如，并發(fā)量多少厌殉，支持多少用戶食绿，采用什么框架等）
6. 需求的分解 —— 需求分析是一個把信息通過分解，進行分類轉化公罕，形成知識的過程
形成知識結構后器紧，再傳遞給開發(fā)人員
mingel——項目管理工具
7. 細化用戶故事，細化楼眷、明確需求在迭代計劃階段——望遠鏡（quick start）到放大鏡
新技術使用之前做spak铲汪，確定能夠駕馭
8. 需求實施階段——顯微鏡
每個細節(jié)，從業(yè)務角度判別需求已完整實現(xiàn)從而確認
四罐柳、 非功能需求卡片（可用性掌腰，歸檔，安全性张吉，可審計齿梁，授權，本地化等）
需要與用戶澄清這些story
五肮蛹、驗收用戶故事的條件
屬性： 各種業(yè)務場景如Happy path勺择，異常事件流（在迭代之前考慮清楚，列出場景蔗崎，而把技術實現(xiàn)的決策交給技術團隊）酵幕、性能
六、管理需求——如何管理實體卡片
用戶故事的生命周期指導開發(fā)
例子：interation story的生命周期（迭代時候用的）*must story 建議在release 和迭代計劃時重新寫
1. 迭代前——有一張卡片缓苛，標示我有這個需求→ 排優(yōu)先級→ 開始分析（驗收條件芳撒、非功能需求等）→ 納入迭代計劃 {or} 技術風險進行spak
2. 迭代中——等待開發(fā)邓深，開始開發(fā)，開發(fā)完成
3. 迭代后——業(yè)務分析師在測試之前就進行驗收（修復優(yōu)先級最高sign off issue）笔刹，再去測試芥备，發(fā)現(xiàn)的問題再去排優(yōu)先級再修復bug
看板管理（精益生產(chǎn)）——知識可視化，目的是增強管理的透明性舌菜，鼓勵每個人發(fā)現(xiàn)問題萌壳、解決問題，而非等待別人來做
可視化管理如何做：用戶角色頭像在第一行更生動日月，用顏色區(qū)別優(yōu)先級袱瓮，用三列區(qū)分出開發(fā)狀態(tài)
七、業(yè)務分析師在迭代過程中段怎么做
等待分析
1. 業(yè)務分析師細化業(yè)務需求
2. 與客戶討論爱咬、驗證業(yè)務目標是否滿足
3. 與開發(fā)團隊討論尺借、實現(xiàn)的可行性
正在分析
1. 業(yè)務分析師隨時解答開發(fā)人員疑問
2. 需要時再向客戶澄清、確認
3. 開發(fā)完成后精拟，業(yè)務分析師做第一手測試驗收
正在測試
業(yè)務分析師與測試人員一起驗收
向客戶驗收完成驗收
驗收完成
八燎斩、書籍推薦
能力要求：理解能力、邏輯思維能力蜂绎，會議組織能力栅表，挖掘用戶需求，信息形成知識
咨詢項目總結出的實踐敏捷過程中的最大問題——思想意識师枣，人的能力（技術怪瓶，BA，管理）
如何寫User Story
金字塔的與原理
