需求條目化快捷之道：SEAi 需求分析法

火星人陳勇企業(yè)級敏捷轉(zhuǎn)型框架：QAD量化敏捷開發(fā)手冊2QAD量化敏捷開發(fā)宣言??全程優(yōu)化

勝過

局部優(yōu)化極限編程，聚焦于編碼、測試、集成等技術(shù)實(shí)踐；Scrum，聚焦于計(jì)劃、跟蹤等項(xiàng)目管理實(shí)踐；看板，聚焦于項(xiàng)目管理中的任務(wù)管理；某些流派的DevOps，聚焦于持續(xù)集成、自動(dòng)化發(fā)布上線等技術(shù)實(shí)踐……盡管我們認(rèn)為右側(cè)的敏捷理念也很重要，但要實(shí)現(xiàn)企業(yè)級敏捷轉(zhuǎn)型，我們更加認(rèn)同：??企業(yè)級敏捷轉(zhuǎn)型，需要一種端到端完整、自洽、連續(xù)的敏捷體系具體方法

勝過

指導(dǎo)理念全程優(yōu)化

勝過

局部優(yōu)化具體方法

勝過

指導(dǎo)理念銜接步驟

勝過

零散實(shí)踐量化指標(biāo)

勝過

文字評價(jià)?如今，敏捷開發(fā)已經(jīng)成為常態(tài)，從業(yè)界頂尖團(tuán)隊(duì)到資質(zhì)平庸的無名團(tuán)隊(duì)都在嘗試敏捷。這時(shí)候，僅僅是“按用戶價(jià)值優(yōu)先級排序”、“自組織團(tuán)隊(duì)”、“INVEST原則”、“故事點(diǎn)”這些模糊原則和概念，已經(jīng)很難讓普通團(tuán)隊(duì)學(xué)習(xí)和掌握了。企業(yè)級敏捷轉(zhuǎn)型，需要各個(gè)環(huán)節(jié)都有一種各種資質(zhì)的人員30分鐘都能學(xué)會(huì)，且工作結(jié)果接近的具體方法。???銜接步驟

勝過

零散實(shí)踐?敏捷開發(fā)中存在各種似是而非的概念。比如：產(chǎn)品經(jīng)理正在用戶故事地圖上張貼三種顏色的需求紙片，

ScrumMaster則在維護(hù)兩個(gè)Backlog，人們立會(huì)站在看板前移動(dòng)任務(wù)紙片，但開發(fā)人員回去之后完成的是用戶故事

，測試則正在研究需求實(shí)例和測試用例……企業(yè)級敏捷轉(zhuǎn)型，必須統(tǒng)一需求、計(jì)劃、人物、開發(fā)、測試等各環(huán)節(jié)的定義，方可在令下一道工序繼承上一道工序的輸出，從而達(dá)到事半功倍的效果?量化指標(biāo)

勝過

文字評價(jià)?當(dāng)前，所有敏捷流派都是“行為驅(qū)動(dòng)”的，主要以在團(tuán)隊(duì)中建立起某種管理、技術(shù)過程為主，而缺乏可比較的量化效果?！巴掏侣省薄肮适曼c(diǎn)生產(chǎn)率”等概念到底多大程度上表征實(shí)際生產(chǎn)率？自動(dòng)化測試為什么常常比原來人工測試顯得生產(chǎn)率更低？迭代開發(fā)是否帶來了高質(zhì)量？在效果不明的情況下貿(mào)然進(jìn)行大規(guī)模全員轉(zhuǎn)型，常常走向騎虎難下的境地。?企業(yè)級敏捷轉(zhuǎn)型需要建立起有說服力的度量項(xiàng)，從而作為判斷試點(diǎn)成功，進(jìn)行后繼推廣的決策依據(jù)。3敏捷開發(fā)

端到端流程

全貌看板用戶故事地圖精益創(chuàng)業(yè)

MVScrum項(xiàng)目經(jīng)理Scrum

MasterDDD

+

需求產(chǎn)品經(jīng)理oduct

Owner創(chuàng)新

Why用戶

Wh質(zhì)量報(bào)告DevOps微服務(wù)

+

重構(gòu)

+

XP團(tuán)隊(duì)Team0.25～12人月QAD核心實(shí)踐早期估算表迭代度量表迭代規(guī)劃故事地圖迭代跟蹤DevOpsBan+

實(shí)時(shí)度量表項(xiàng)目管理度量項(xiàng)：o發(fā)布周期天ooo名義生產(chǎn)率

FP/人天實(shí)際生產(chǎn)率

FP/人天成本

RMB/FP版本規(guī)劃整體計(jì)劃會(huì)簡化迭代計(jì)劃會(huì)每日立會(huì)迭代回顧需求，計(jì)劃，開發(fā)，測試，質(zhì)量，發(fā)布，六大領(lǐng)域全程量化管理場景

Scenario（商業(yè)目標(biāo)）實(shí)體

Entity（史詩故事）行為

Action（用戶故事）需求實(shí)例

Instance（驗(yàn)收測試用例）頁面/接口方法測試缺陷發(fā)布缺陷數(shù)據(jù)庫表類微服務(wù)測試用例測試水平度量項(xiàng)：測試質(zhì)量度量項(xiàng)：發(fā)布與運(yùn)維度量項(xiàng)：ooooo行為覆蓋率

%oo測試缺陷密度

D/FPooooo發(fā)布周期天開發(fā)水平度量項(xiàng)測試密度TC/FP測試用例有效率

D/TC發(fā)布缺陷密度D/FP缺陷響應(yīng)周期天發(fā)布缺陷成本

人天/D發(fā)布缺陷次率

次/Doo編碼消耗率

LLOC/FP陳舊語法密度

個(gè)/FP測試用例自動(dòng)化率

%D測試測試用例生產(chǎn)率

TC/測試人天測試工作量占比%o過程效益=

——————%D測試+D發(fā)布）5SEAi

需求分析法行為

Action（用戶故事）場景

Scenario（商業(yè)目標(biāo)）實(shí)體

Entity（史詩故事）需求實(shí)例

Instance（驗(yàn)收測試用例）按成敗快慢程度，將單個(gè)將產(chǎn)品功能按商業(yè)目將其中每個(gè)場景描述為一段話：其中會(huì)被增查改刪的賓為每一個(gè)實(shí)體，如【訂單】，分析增查改刪行為：行為分解為需求實(shí)例標(biāo)分解為若干場景：語就是【實(shí)體】：

商鋪管理場景

購物場景

收發(fā)貨場景

常規(guī)廣告場景

聚劃算促銷場景

節(jié)日活動(dòng)場景訂單.創(chuàng)建：購物場景：購物場景：訂單：增：最快成功：正常創(chuàng)建；成功：調(diào)整商品數(shù)量大于0；調(diào)整商品數(shù)量小于等于0（被阻止）；顧客搜索商品，找到以后創(chuàng)建訂單，賣家會(huì)生成發(fā)貨記錄，等買家確認(rèn)收貨之后，淘寶產(chǎn)生結(jié)算記錄結(jié)算貨款及傭金。顧客搜索【商品】，找到以后創(chuàng)建【訂單】賣家會(huì)生成【發(fā)貨記錄】，等賣家確認(rèn)收貨之后，淘寶產(chǎn)生【結(jié)算記錄】結(jié)算貨款及傭金。創(chuàng)建查多個(gè)：

列表，搜索，報(bào)表查單個(gè)：

詳情改：刪：支付刪除，取消失?。簞?chuàng)建不存在的商品訂單；創(chuàng)建未上架的商品訂單；最快失?。翰坏卿浽L問創(chuàng)建訂單鏈接；拷貝訪問別人的創(chuàng)建訂單鏈接；SEAi

需求層次與傳統(tǒng)方法的映射關(guān)系用戶故事地圖XP，JiraScrumSAFe，TFS看板~1個(gè)橙色紙片--~1個(gè)Epic-~1個(gè)藍(lán)色紙片~1個(gè)史詩故事Epic-~1個(gè)Feature-~1個(gè)黃色紙片~1個(gè)用戶故事Story~1個(gè)Sprint

Backlog

Item~1個(gè)Story~1個(gè)任務(wù)UML功能點(diǎn)分析FPAWordFP，工作量--~1個(gè)實(shí)體Entity~1個(gè)ILF或EIF~1個(gè)3級目錄~35/15FP，30/12人天~1個(gè)用例~1個(gè)EI或EO或EQ~1個(gè)4級目錄~1個(gè)2級目錄~N/A，30~300人天~5.4FP，5人天11~N1~6.5(3~10)1~6.5SEA層次場景

Scenario（商業(yè)目標(biāo)）實(shí)體

Entity（史詩故事）行為

Action（用戶故事）需求實(shí)例

Instance（驗(yàn)收測試用例）~1個(gè)數(shù)據(jù)庫表~1個(gè)業(yè)務(wù)類~1個(gè)Model~1個(gè)Conroller~1個(gè)~1個(gè)頁面

或

接口~1個(gè)驗(yàn)收測試用例~1個(gè)微服務(wù)~1個(gè)Package(Java)~1個(gè)Area(.net

mvc)~1個(gè)公開方法（函數(shù)）~1個(gè)Action~1個(gè)接口的返回值技術(shù)術(shù)語~1個(gè)代碼中的業(yè)務(wù)分支~1個(gè)View或子View7基于SEA的估算法先將產(chǎn)品功能按商業(yè)目標(biāo)分解為若干場景Scenario：?商鋪管理場景，購物場景，收發(fā)貨場景，常規(guī)廣告場景，聚劃算促銷場景?，節(jié)日活動(dòng)場景……以購物場景為例，將其中每個(gè)場景描述為一段簡短但邏輯完整的文字：?顧客搜索商品，找到以后創(chuàng)建訂單，賣家會(huì)生成發(fā)貨記錄，等買家確認(rèn)收貨之后，淘寶產(chǎn)生結(jié)算記錄結(jié)算貨款及傭金。早期估算點(diǎn)分析其中需要被增查改刪的實(shí)體Entity（名詞，賓語，可理解為史詩故事），共有四個(gè)，使用方括號(hào)強(qiáng)調(diào)標(biāo)出：?顧客搜索【商品】，找到以后創(chuàng)建【訂單】，賣家會(huì)生成【發(fā)貨記錄】，等買家確認(rèn)收貨之后，淘寶產(chǎn)生【結(jié)算記錄】結(jié)算貨款及傭金。其中發(fā)貨記錄在“收發(fā)貨場景中”詳述，故此下一步驟中只有另外三個(gè)實(shí)體。中期估算點(diǎn)為每個(gè)實(shí)體，合理猜測用戶潛在的增查改刪行為Action（動(dòng)詞，可理解為用戶故事），得到：?實(shí)體【商品】創(chuàng)建【訂單】【結(jié)算記錄】?增創(chuàng)建創(chuàng)建早期估算公式?查（多個(gè)）?

（單個(gè)）?改列表，搜索，報(bào)表詳情列表，搜索，報(bào)表列表，報(bào)表詳情詳情?

功能點(diǎn)FP

=

實(shí)體

*

35中期估算公式修改，上架/下架刪除，查封8支付-?刪取消，刪除8-.?

功能點(diǎn)FP

=

行為

*

5.4?數(shù)量48敏捷快速估算表（1FP對應(yīng)的數(shù)據(jù)）估算項(xiàng)目（單位）AFP功能點(diǎn)公式早期EFP3*35

=

10594人天中期AFP20*5.4

=

10896人天未調(diào)整功能點(diǎn)

*

應(yīng)用調(diào)整因子AFP

/

1.12人天/FPAFP

*

920~988~10881.3*人月^0.5（根號(hào)人月）工作量（人天)成本（元）工期（月）代碼行94,00096,0002.7個(gè)月55652.8個(gè)月5724JavaAFP

*

53(27，14)歷史中值（2015中值，QSM最好成績）（2835，1470）

（2916，1512）C#AFP

*

58(27)AFP

*

55(27)-（2835，-）-（2916，-）C++-（2835，-）-（2916，-）合理的測試用例數(shù)合理的測試缺陷數(shù)AFP

*

1.2AFP

*

0.33AFP

*

0.0281263513036合理的發(fā)布缺陷數(shù)2.93.0發(fā)布后一個(gè)月內(nèi)9基于SEA繪制用戶故事地圖

真實(shí)發(fā)布策略

vs.

內(nèi)部原型策略購物場景訂單購物場景商品結(jié)算記錄商品訂單結(jié)算記錄創(chuàng)建列表搜索創(chuàng)建列表創(chuàng)建列表列表詳情詳情搜索詳情支付創(chuàng)建取消修改詳情刪除支付詳情上下架取消刪除報(bào)表刪除搜索報(bào)表報(bào)表搜索019

北京列表報(bào)表報(bào)表報(bào)表詳情10基于SEA的Scrum，Kanban，DevOpsBan購物場景待開發(fā)開發(fā)中開發(fā)完畢商品訂單結(jié)算記錄創(chuàng)建列搜索詳情上下架刪除支付取消創(chuàng)建刪除列表詳情支付取消刪除創(chuàng)建報(bào)表報(bào)表搜索列表詳情報(bào)表創(chuàng)建列表詳情報(bào)表報(bào)表搜索報(bào)表11QAD團(tuán)隊(duì)級框架12QAD組織級框架其他團(tuán)隊(duì)其他團(tuán)隊(duì)ooo開源微服務(wù)開源代碼度量模版行業(yè)量化基線組織量化基線內(nèi)部開源庫分享組織級先鋒團(tuán)隊(duì)（量化績效最佳團(tuán)隊(duì)）產(chǎn)品經(jīng)理

/

業(yè)務(wù)部門項(xiàng)目經(jīng)理

/

技術(shù)團(tuán)隊(duì)首席教練

/

教練團(tuán)隊(duì)原始需求Scrum/Kanban?DevOps循環(huán)?微服務(wù)框架量化需求量化計(jì)劃工作量?

成本?

工