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
金字塔的與原理