這兩天在學習用戶故事拆分，突然感覺它和MFQ是存在着那麼多的相似性，故在此簡單談談我的感想。
一.思維方式
2015年外部教練邰曉梅在她授課過程中分享了TED的一段脫口秀視頻，視頻中揭示了成功人士的思維方式，如下圖所示：
成功人士在做一件事情的時候總會先思考意義是什麼（Why)?其次是如何去做(How)?在這個基礎上纔去考慮做什麼(What)?非成功人士思考方式可能截然相反。
聯想到我們的測試設計和故事拆分工作的思維方式何嘗不是這樣呢？
1.1測試設計的思維方式
新手在做測試設計時會基於對被測系統有限的信息“拍腦袋”直接給出測試測試設計用於，稍好些會套用一些諸如“等價類、邊界值…”這樣測試設計技術。但這些測試用例是否足夠？哪些地方冗餘？能否覆蓋到用戶最關心的功能點？這些都是很難得到保障的。而在現有的敏捷背景下的測試人員/QA越來越提倡的是做缺陷預防，在做測試設計之前先做被測對象和需求相關的信息收集和分析。在這個基礎上得到正確的測試策略，甚至通過在需求澄清階段就提前介入將缺陷直接扼殺在搖籃。
1.2故事拆分活動的思維方式
再來看下故事拆分活動。在需求分析和故事拆分階段常出現的問題是喜歡用研發的語言去交流需求，一來上就直接從方案出發，特別是在已有系統上做需求尤爲明顯。比如：“當前我們XXX模塊當前的處理流程是什麼樣的，這個需求就是要增加YYY結構，ZZZ流程”。也就是說通過現有系統能提供什麼反推如何去滿足用戶的需要。而成功的需求工作應該是從用戶價值出發，採用用戶的思維和語言去考慮和描述，然後纔是特性和設計。
二.協作方式
回想一下敏捷模式和傳統模式下的研發的協作方式的差異無非就是橫向切蛋糕和縱向切蛋糕的差異,如下圖所示：
分層的思想隨處可見,比如OSI 7層協議和TCP/IP 5層協議。分層的好處就是每層可以專注自己的事情單一職責，避免受其他層的影響，但也由於這個封閉性，每一層獲得的上下游信息是是否有限的。現實中很多事情並不是局部最優解全局就是最優解，在越來越講究協作的今天也很難沒有任何依賴僅憑藉一個人(或相對小的工作單位)就把一個龐大的事情搞定。正所謂羣狼猛於虎。
2.1開發工作的協作方式：
在以往的研發工作的協作方式稱作WBS(Work Breakdown Structure)，創建WBS是把項目可交付成果和項目工作分解成較小的，更易於管理的組成部分的過程。WBS是把項目可交付成果和項目工作分解成較小的，更易於管理的組成部分的過程。WBS是把項目可交付成果和項目工作分解成較小的，更易於管理的組成部分的過程。如下圖所示：
圖2.1.1 WBS交付流程
以往的開發工作中，需求分析這塊相對比較薄弱，接到原始需求之後直接進入方案討論，總體方案確定之後橫向切蛋糕，將任務分解爲上層業務、底層平臺來實現，而平臺再繼續切蛋糕分解到各個子系統分別完成，完成後再進行聯調，各個子系統的團隊都專注自己的任務而整體上考慮用戶價值(WHY)比較少，而蛋糕層與層之間的交流成本卻很高。
而在現有的敏捷研發流程是縱向切蛋糕，更加強調完整團隊和從用戶價值出發。更強化需求管理是保證團隊從Why的角度，從用戶價值出發去做產品，而完整團隊是保證信息順暢的傳遞和更好的協作。在敏捷背景下的DOD交付過程大致是這樣的，如圖2.1.2所示：
圖2.1.2 DOD交付流程
2.2測試工作的協作方式：
傳統瀑布模型中測試工作即是橫向切蛋糕的過程，分部門分團隊進行單元測試->集成測試->系統測試逐層進行，但每一層的測試聚焦在自身有限信息和範圍的基礎之上，比如單元測試聚焦代碼邏輯和流程測試，系統測試基於前端的軟件系統測試，但都缺乏對於對於整個交付流程信息完備的瞭解，雖然進行了分層但單元測試、集成測試、系統測試的覆蓋依然會存在重複和遺漏。而敏捷背景下應用MFQ要求QA在前端的需求研討、需求分析、需求澄清和故事拆、需求開發階段都要介入。首先要站在用戶視角發出自己的聲音，爲缺陷預防貢獻自己的力量。還需要不斷收集信息，結構化的整理到KYM中，並作爲測試策略、測試設計的依據，如圖2.1.2：
- 需求分析階段：
TS/QA做KYM，測試方案，反饋問題缺陷預防 - 故事澄清和拆分：
TS/QA做KYM，TCO，反饋問題缺陷預防 - 需求開發:
QA更新KYM，TCO信息TCON->TC,自動化用例開發，反饋問題缺陷預防 - 需求驗收：
QA執行手工測試用例，將自動化用例部署到CI，反饋問題缺陷預防
三.語言：
3.1用戶故事的描述語言：
在故事卡上我們採用如下格式做用戶故事的描述：
As a Role For Value I want to do
這是一種站在用戶視角的描述方式，As代表用戶角色，用戶是誰。For代表的是用戶價值，do代表的是用戶場景。
3.2 MFQ中TCON的描述語言：
TCON在MFQ框架中的含義是測試條件/測試場景，它的三段式描述如下所示：
GIVEN:用戶場景 WHEN:用戶行爲 THEN:用戶期待/價值
它也是一種基於用戶視角的描述方式。
我們發現它們的共同點是描述語言基於用戶語言，也就是研發和用戶採用“統一語言”，統一語言的意義同樣是拉近用戶和研發的距離，能夠更好的溝通。
四.準則:
用戶故事的拆分和編寫需要滿足INVEST準則：
- I:Independent 獨立：
可以獨立交付，避免和其他故事產生依賴。依賴會妨礙優先級的的判定和 開發計劃的評估。
這一點和MFQ中M單功能的劃分類似，在MFQ中M也被認爲是可以獨立驗證的軟件功能。但MFQ中是可以存在功能交互的，我們稱爲F。F功能交互的測試也會比單功能的測試相比M來說難度也更大（更復雜的測試環境，測試人員需要了解的被測對象的領域知識更豐富）。非獨立的故事多了是否也會導致測試設計階段F類型的測試點增多，增加測試難度呢？MayBe….
- N:Negotiable 可協商的：
用戶故事是可協商可調整的。
現有敏捷實踐都主張“擁抱變化”，主張的是與用戶溝通和調整而不是通過合同和條款制約。同樣MFQ也需要是擁抱變化的，KYM和TCO梳理出來後並不是一成不變的需要根據需求的變化調整，在整個開發過程中當獲得更多的信息後也需要進行調整。
- V:valuable 有價值的:
用戶故事是端到端的要能夠體現出用戶的價值，不能體現出用戶價值的工作可以考慮合併或用任務的方式進行跟蹤。
測試中的價值體現在項目”風險”和“價值”。測試是無窮盡的，測試策略、設計和執行都應該向“風險”和“價值”傾斜。
E:Estimatable 可估算:
用戶故事要用於迭代計劃，只有可估算才能保證團隊開發節奏的穩定。故事不可估算的原因可能爲領域知識不足、缺乏技術能力無法準確估計故事的工作量，缺乏封閉性。S:Small 足夠小：
故事要足夠小，能夠在一個迭代內交付。
在MFQ中M也是要求劃分爲足夠小的能夠被獨立測試的功能單元。但這個大小應該是根據功能的重要程度來決定，它是相對的。從測試策略的角度來說對於一個重要的單功能，我們需要拆分更多小的單功能，對於一個低風險的單功能我們可能不需要再繼續進行拆分。
- T:Testable:
故事要有明確的驗收條件，能夠被測試和驗收。需要用測去試證明一個故事滿足客戶的期望。
五.層次
分層細化的思想隨處可見，用戶故事和MFQ也都應用着這樣的思想讓需求的交付和測試過程可控。
5.1用戶故事的層次
如上圖所示用戶故事分爲迭代內的、發佈的，和史詩故事。
5.2MFQ的層次
如上圖，在做TCO的時候我們也會將一個大的單功能M進行拆分爲M1.1,M1.2…等等。
六.優先級
在故事卡和測試用例中我們都會存在優先級的標識來決定重要程度和執行順序。用戶故事的交付和測試優先級的排定都應該是基於風險和價值的，他們優先級排定都可以用下圖來表示：
