作為一個(gè)強(qiáng)技術(shù)背景的敏捷教練蒜埋，我會(huì)更關(guān)注于敏捷的最核心單元 - 敏捷團(tuán)隊(duì)凌彬。

我們理想中的敏捷沸柔，應(yīng)當(dāng)是 強(qiáng)、有力且具備柔活性

理想的敏捷狀態(tài)

現(xiàn)實(shí)中铲敛，即使高層培訓(xùn)的再有敏捷思維褐澎，敏捷理念，敏捷意識(shí)伐蒋，而團(tuán)隊(duì)的能力工三，沒(méi)有變化時(shí)迁酸，其敏捷狀況如同改造前的美國(guó)隊(duì)長(zhǎng)，很多事心有余而力不逮俭正。

現(xiàn)實(shí)中的敏捷狀態(tài)如同改造前的美國(guó)隊(duì)長(zhǎng)

在SAFe 5.0中奸鬓，敏捷企業(yè)的七大核心能力之一，便是 “團(tuán)隊(duì)與技術(shù)的敏捷力"掸读， 忽略這個(gè)核心能力串远，只會(huì)造成更多的痛苦和加班。

團(tuán)隊(duì)的能力建設(shè)是個(gè)持續(xù)的且需要時(shí)間的儿惫。我經(jīng)常在思考如何更好的解決這個(gè)問(wèn)題澡罚，幫助團(tuán)隊(duì)開(kāi)啟追求技術(shù)卓越之路。

這篇分享肾请，誕生于第一屆SAFe中國(guó)大會(huì) 留搔，當(dāng)時(shí)考慮到，參會(huì)的大部分人筐喳，或許沒(méi)有太多的技術(shù)背景催式，那么如何把一個(gè)技術(shù)的主題，變成一個(gè)不需要太多技術(shù)背景的人都能理解避归，并且能夠帶回的組織中荣月，開(kāi)箱即用，就是這個(gè)分享的主要目標(biāo)梳毙。

一開(kāi)始哺窄，我以為會(huì)來(lái)聽(tīng)的人不會(huì)太多，出乎意料的是账锹，這個(gè)分會(huì)場(chǎng)萌业，幾乎坐滿了。
上海的敏捷之旅奸柬，來(lái)聽(tīng)的人也都坐不下生年。

很開(kāi)心的看到，關(guān)注團(tuán)隊(duì)能力成長(zhǎng)的伙伴很多廓奕。
也希望分享的內(nèi)容抱婉，能幫助更多的團(tuán)隊(duì)走向技術(shù)卓越。

1. 背景 - "敏捷團(tuán)隊(duì)" 常見(jiàn)的有趣問(wèn)題

產(chǎn)品 - 開(kāi)發(fā) - 測(cè)試 以為的 "理解一致"

需求的"理解一致"

在需求溝通宣講的過(guò)程中桌粉，經(jīng)痴艏ǎ可以看到的場(chǎng)景是，產(chǎn)品拿著原型和PRD對(duì)著團(tuán)隊(duì)一頓Blablabla的講铃肯，然后問(wèn)團(tuán)隊(duì)有沒(méi)有問(wèn)題患亿，此時(shí)團(tuán)隊(duì)可能會(huì)提一下問(wèn)題，測(cè)試伙伴的問(wèn)題通常會(huì)多一些押逼；很多時(shí)候是一頓安靜 "沒(méi)問(wèn)題"步藕。 好了惦界，大家達(dá)成理解一致了，過(guò)下一個(gè)需求 ....咙冗。

然后表锻，測(cè)試伙伴去負(fù)責(zé)寫測(cè)試用例， 開(kāi)發(fā)去負(fù)責(zé)寫實(shí)現(xiàn)乞娄，一切很美好瞬逊，到了聯(lián)調(diào)的時(shí)候，尤其是多團(tuán)隊(duì)聯(lián)調(diào)的時(shí)候仪或，這個(gè)熟悉情景就在重演

image.png

讓我們把視角從最外層向最內(nèi)層逐級(jí)放大看看:

• 客戶(用戶) 收到交付的時(shí)候确镊，會(huì)對(duì)PO說(shuō)這不是Ta想要的或者與Ta的要求有出入.
• 視角放大， PO驗(yàn)收開(kāi)發(fā)團(tuán)隊(duì)的交付是范删，會(huì)說(shuō)這個(gè)功能與Ta的要求有出入蕾域，按常理說(shuō), 這應(yīng)當(dāng)blablabla.....
• 視角再放大, 測(cè)試人員在收到開(kāi)發(fā)提測(cè)的功能，會(huì)說(shuō)這個(gè)功能不滿足測(cè)試用例到旦，blablabla....
• 視角繼續(xù)放大旨巷，開(kāi)發(fā)人員之間，前端與后端聯(lián)調(diào)的時(shí)候添忘，接口的參數(shù)與行為與彼此的預(yù)期也不一致采呐。

每天都能看到這個(gè)場(chǎng)景

容易被忽略的缺陷發(fā)現(xiàn)成本

缺陷發(fā)現(xiàn)成本的變化

本圖取自 SAFe 認(rèn)證課程 Agile Software Engineering 敏捷軟件工程

那么開(kāi)發(fā) - 測(cè)試 誰(shuí)更懂需求?

由于經(jīng)驗(yàn)也好 認(rèn)知也罷, 多數(shù)團(tuán)隊(duì)中

• 測(cè)試比開(kāi)發(fā)更懂需求，更清楚要實(shí)現(xiàn)的功能
• 實(shí)際干活的人經(jīng)常不太清楚應(yīng)該干到什么地步
• 常常變成測(cè)試在指導(dǎo)開(kāi)發(fā)交付工作, 反復(fù)提測(cè) 反復(fù)打回
• 兩者不一致時(shí)搁骑，引入 PO 仲裁斧吐， 一定幾率爆出前面的 "PO-開(kāi)發(fā)-測(cè)試 理解一致"

工作量的估算

人天？
常規(guī)的工作量單位仲器，大家都喜歡用人天煤率，為什么呢，因?yàn)楹蜁r(shí)間關(guān)聯(lián)在一起乏冀，做項(xiàng)目計(jì)劃就方便多了蝶糯。
敏捷中卻不提倡用人天，原因有幾點(diǎn)

• 人天(人時(shí)) 屬于絕對(duì)估算辆沦，而非相對(duì)估算
• 很難找到作為標(biāo)準(zhǔn)的基準(zhǔn)人天昼捍，每一項(xiàng)工作，不同水平的人用的人天是不同的
• 那么估算的人天众辨，是誰(shuí)的人天
• 通常就演變成端三，誰(shuí)估算的人天舷礼，就默認(rèn)誰(shuí)做鹃彻。這個(gè)工作，未來(lái)大概率還是會(huì)有Ta來(lái)做妻献。最后演變成工作預(yù)先鎖定人蛛株。

故事點(diǎn)团赁？
敏捷中，在估算上倒是蠻一致的說(shuō)谨履，要用 故事點(diǎn) 來(lái)作為相對(duì)規(guī)模的估算標(biāo)準(zhǔn)欢摄。
有一篇很好的參考文章 故事點(diǎn)

聽(tīng)起來(lái)很美，于傳統(tǒng)的人天絕對(duì)故事對(duì)比笋粟，有了明顯的改進(jìn)怀挠，至少理論上把估算與實(shí)現(xiàn)的人分離開(kāi)了。
然而害捕，據(jù)我觀察的不少團(tuán)隊(duì)绿淋，操作起來(lái)卻很骨感。

原因也有類似的:

• 基準(zhǔn)故事點(diǎn)尝盼，也一樣沒(méi)那么直觀 好找
• 不同團(tuán)隊(duì)的基準(zhǔn)故事不同吞滞，估算規(guī)則也就不同，團(tuán)隊(duì)之間也就失去比較基礎(chǔ)
• PO盾沫、用戶對(duì)故事點(diǎn)的大小裁赠，缺乏直觀的感知，你告訴他 8 還是 5, 對(duì)于他來(lái)說(shuō)就是一個(gè)數(shù)字
• 一個(gè)故事赴精，給不同團(tuán)隊(duì)佩捞，便會(huì)得到有不同的估算故事點(diǎn)，PO就容易困惑了

關(guān)于估算這個(gè)事情蕾哟，我會(huì)單獨(dú)寫一下我的經(jīng)驗(yàn)和認(rèn)知, 先挖個(gè)小坑失尖，感興趣可以發(fā)信息給我。

- 號(hào)稱“敏捷團(tuán)隊(duì)”了渐苏，過(guò)程中小瀑布味道卻還很濃

Sprint的前半段集中開(kāi)發(fā)掀潮，后半段集中提測(cè)，修BUG
前端后端協(xié)作與聯(lián)調(diào)的等待與同步
業(yè)務(wù)流程中用戶故事之間的批次串行和等待

這些問(wèn)題琼富，在我接觸過(guò)的團(tuán)隊(duì)身上仪吧，比比皆是。
我自己帶的團(tuán)隊(duì)很快能擺脫出來(lái)鞠眉；
接受過(guò)我的咨詢輔導(dǎo)的團(tuán)隊(duì)也獲得有效的改進(jìn)薯鼠，有些用的時(shí)間長(zhǎng)，有些用的時(shí)間短械蹋，取決于團(tuán)隊(duì)自身的進(jìn)取程度出皇。
這些差異，讓我不斷的反思哗戈，如何更有效的幫助團(tuán)隊(duì)郊艘，讓團(tuán)隊(duì)具備走出困境的能力。
這便有了下面的內(nèi)容

2. BDD - Behavior Driven Development 行為驅(qū)動(dòng)開(kāi)發(fā)

定義:

行為驅(qū)動(dòng)開(kāi)發(fā)（Behavior-Driven Development）（簡(jiǎn)寫B(tài)DD），在軟件工程中纱注，BDD是一種敏捷軟件開(kāi)發(fā)的技術(shù)畏浆。

行為驅(qū)動(dòng)開(kāi)發(fā)(BDD)是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的延伸，開(kāi)發(fā)使用簡(jiǎn)單的狞贱，特定于領(lǐng)域的腳本語(yǔ)言刻获。這些DSL將結(jié)構(gòu)化自然語(yǔ)言語(yǔ)句轉(zhuǎn)換為可執(zhí)行測(cè)試。結(jié)果是與給定功能的驗(yàn)收標(biāo)準(zhǔn)以及用于驗(yàn)證該功能的測(cè)試之間的關(guān)系更密切瞎嬉。因此蝎毡，它一般是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)測(cè)試的自然延伸。

BDD 作為一種設(shè)計(jì)方法氧枣，可以有效的改善設(shè)計(jì)顶掉，并在系統(tǒng)的演化過(guò)程中為團(tuán)隊(duì)指明前進(jìn)方向。

這里面我認(rèn)為最重要的是最后的那句話 "BDD 作為一種設(shè)計(jì)方法挑胸，可以有效的改善設(shè)計(jì)痒筒，并在系統(tǒng)的演化過(guò)程中為團(tuán)隊(duì)指明前進(jìn)方向。"

然而B(niǎo)DD相當(dāng)長(zhǎng)的一段時(shí)間沒(méi)有過(guò)多人關(guān)注茬贵，與 "它一般是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)測(cè)試的自然延伸簿透。" 這個(gè)表述有著很大的關(guān)系。

- 基于技術(shù)認(rèn)知的BDD

通常大家對(duì)的BDD的認(rèn)知解藻，是在技術(shù)維度上的老充，包括我。
常見(jiàn)的一個(gè)BDD例子, 用BDD來(lái)驅(qū)動(dòng)一個(gè)技術(shù)類的行為

image.png

推導(dǎo)出來(lái)的測(cè)試用例

image.png

這會(huì)有什么問(wèn)題呢螟左？
多年前啡浊，我看到BDD的是，也是很興奮胶背，也練習(xí)了類似這個(gè)的例子巷嚣。結(jié)果是，做完了钳吟，BDD我便將它放到一邊去了廷粒。
原因很簡(jiǎn)單

1. BDD說(shuō)要業(yè)務(wù)人員參與，你認(rèn)為業(yè)務(wù)人員會(huì)參與(或去看)一個(gè)技術(shù)實(shí)現(xiàn)類(Class) 的行為嗎红且？
2. 本身不會(huì)寫單元測(cè)試的人坝茎，他玩不轉(zhuǎn)這個(gè)BDD測(cè)試
3. 能寫這個(gè)BDD測(cè)試的人，他本身也具備單元測(cè)試TDD的能力和基礎(chǔ)

那么暇番，我既然能TDD嗤放，為何不直接直接寫單元測(cè)試，比起B(yǎng)DD來(lái)壁酬，更直接了當(dāng)次酌。

這便把BDD鎖在了技術(shù)這個(gè)維度上恨课，TDD本來(lái)就小眾，結(jié)果是BDD就更小眾了和措。

- 基于用戶故事的BDD認(rèn)知

直到我接觸了敏捷、用戶故事 和 敏捷實(shí)踐 (1) - 我們是如何自動(dòng)化App驗(yàn)收標(biāo)準(zhǔn)
里面發(fā)生的事情蜕煌。
讓我對(duì)BDD有了不同的認(rèn)知派阱， 那便是 ----

基于用戶故事的BDD

既然是講 Behavior 行為，那為什么要局限于技術(shù)維度呢斜纪？業(yè)務(wù)的行為應(yīng)當(dāng)是更合適的維度贫母。
通過(guò)業(yè)務(wù)維度的BDD，我輔導(dǎo)的團(tuán)隊(duì)盒刚，通常能更好的前面的困境中走出來(lái)腺劣。

3. 用戶故事與驗(yàn)收條件

既然BDD的行為，是從業(yè)務(wù)的行為開(kāi)始因块，業(yè)務(wù)的行為橘原，我們通常是借助 【用戶故事】 來(lái)進(jìn)行表達(dá)

- 用戶故事

定義:

用戶故事是從用戶的角度來(lái)描述用戶渴望得到的功能。

一個(gè)好的用戶故事包括三個(gè)要素：

1. 角色：誰(shuí)要使用這個(gè)功能涡上。
2. 活動(dòng)：需要完成什么樣的功能趾断。
3. 商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來(lái)什么樣的價(jià)值

示例:

作為 購(gòu)書(shū)者
我要 根據(jù)作者姓名模糊查詢書(shū)籍
這樣(so that) 方便我找到要的書(shū)籍加到購(gòu)物車

做為一名 極客
我想要提交我今天的工作日?qǐng)?bào)
以便于其他人了解我的一天工作情況

關(guān)于用戶故事的編寫吩愧，又將會(huì)是另一篇分享的內(nèi)容芋酌，可以先參考 【敏捷反思之三: 用戶故事是否可以不寫 "So that" ?】

- 驗(yàn)收條件 (Acceptance Criteria - AC)

之前將 Acceptance Criteria - AC 翻譯為驗(yàn)收標(biāo)準(zhǔn)， Scrum中我們有 DoD (Definition of Done 完工標(biāo)準(zhǔn)), 為了避免混淆雁佳，Ethan 老師提議統(tǒng)一翻譯成 驗(yàn)收條件 .

驗(yàn)收條件定義:

• 驗(yàn)收條件就是一系列可以接受的驗(yàn)收條件或者業(yè)務(wù)規(guī)則脐帝，且與功能或feature相互匹配和滿足，同時(shí)也能被產(chǎn)品負(fù)責(zé)人和相關(guān)人接受糖权。

• 驗(yàn)收條件可作為驗(yàn)收測(cè)試用例的具體例子堵腹。這也是我們常說(shuō)的實(shí)例化需求，也是為了避免誤讀星澳，讓抽象的需求變得具體和可測(cè)試秸滴。

• 一個(gè)用戶故事包含若干個(gè)驗(yàn)收條件，包括快樂(lè)路徑（Happy Path）與異常場(chǎng)景（Exceptional Scenario）

• 驗(yàn)收標(biāo)準(zhǔn)是 最小化的 無(wú)分支的 用戶故事

• 用來(lái) 限定工作范圍

最后的兩點(diǎn)是我補(bǔ)充的

(驗(yàn)收條件可以作為后續(xù)要填的第三個(gè)坑)

驗(yàn)收條件的格式:

image.png

團(tuán)隊(duì)做敏捷轉(zhuǎn)型募判，一開(kāi)始就會(huì)遇到的兩個(gè)攔路虎荡含，用戶故事 與 驗(yàn)收條件。
驗(yàn)收條件寫的如何届垫，甚至可以用來(lái)評(píng)價(jià)一個(gè)團(tuán)隊(duì)的需求分析和協(xié)作的水平如何释液。

要讓團(tuán)隊(duì)接受通過(guò)驗(yàn)收條件來(lái)進(jìn)行需求分析和確認(rèn)，改變工作習(xí)慣装处，不是一件容易的事情误债。
需要讓大家了解驗(yàn)收條件具有哪些作用浸船，能夠讓大家在更好的理解和接受。

- 驗(yàn)收條件的作用

• 1. 以用戶的視角表達(dá)業(yè)務(wù)交互過(guò)程.
• 2. 為PO與用戶的需求理解上提供場(chǎng)景化寝蹈、具象化的溝通和明確 (實(shí)例化需求)
• 3. 有助于用戶體驗(yàn)友好性的識(shí)別和改進(jìn)
• 4. PO與團(tuán)隊(duì)需求共識(shí)的標(biāo)準(zhǔn)和記錄
• 5. 可視化一個(gè)用戶故事的粗細(xì)粒度
• 6. 開(kāi)發(fā)與測(cè)試對(duì)功能實(shí)現(xiàn)與質(zhì)量的共識(shí)
• 7. 作為結(jié)對(duì)工作的基礎(chǔ)
• 8. 自動(dòng)化測(cè)試用例
• 9. 需求完成邊界的限定
• 10. 比單純故事點(diǎn)更為直觀的工作估摸 估算標(biāo)準(zhǔn)
• 11. 活文檔
• 12. 用戶手冊(cè)(幫助 FAQ)的素材
• 13. 一個(gè)更公平透明的甲乙方的定價(jià)標(biāo)準(zhǔn)(敏捷合同的基礎(chǔ))

當(dāng)然李命，還有其他作用，后面再補(bǔ)充吧箫老。

我曾經(jīng)開(kāi)玩笑的說(shuō)封字，我應(yīng)該是第一個(gè)把驗(yàn)收條件的作用挖的最深的 ;)

- 驗(yàn)收條件編寫的實(shí)戰(zhàn)技巧

在團(tuán)隊(duì)開(kāi)始學(xué)習(xí)編寫驗(yàn)收條件的前期，經(jīng)常收到的反饋耍鬓，便是阔籽，

• 驗(yàn)收條件編寫很耗時(shí), 寫一個(gè)用戶故事的驗(yàn)收條件，要一個(gè)小時(shí) 甚至更長(zhǎng)
• 場(chǎng)景容易遺漏 尤其是異常場(chǎng)景
• 驗(yàn)收條件編寫質(zhì)量層差不齊, 不知道如何有效編寫

在輔導(dǎo)過(guò)程中牲蜀，我總結(jié)了一些編寫的實(shí)戰(zhàn)技巧笆制，加速團(tuán)隊(duì)的能力變化

1. 先寫快樂(lè)路徑的場(chǎng)景標(biāo)題
2. 完成一個(gè)快樂(lè)路徑的具體內(nèi)容
3. 以復(fù)制粘貼+微調(diào)的方式，快速完成剩余的快樂(lè)路徑
4. 對(duì)著快樂(lè)路徑上的步驟涣达，寫成可能需要處理的異常路徑標(biāo)題
5. 再以復(fù)制粘貼在辆，完善每一個(gè)異常路徑的具體內(nèi)容
6. 對(duì)驗(yàn)收標(biāo)準(zhǔn)進(jìn)行價(jià)值排序

通過(guò)這種方式，能夠大大提升編寫驗(yàn)收條件的效率度苔，場(chǎng)景完整性識(shí)別开缎。

4. 基于用戶故事的BDD

- 常規(guī)的BDD過(guò)程

image.png

- 基于用戶為中心的BDD過(guò)程

image.png

- 用戶故事和驗(yàn)收條件 與 BDD正好無(wú)縫結(jié)合

image.png

上面的驗(yàn)收條件，已經(jīng)是很多新手團(tuán)隊(duì)在入門階段時(shí)林螃，寫的算不錯(cuò)的了奕删。但是，如果用這個(gè)進(jìn)行開(kāi)發(fā)疗认，里面依然坑很大完残。
所以，驗(yàn)收條件需要明確化横漏，向前一步谨设，便是可以人工測(cè)試的驗(yàn)收條件

可人工測(cè)試的驗(yàn)收條件

前一個(gè)驗(yàn)收條件，我們只能知道 在哪 要做些什么事情缎浇。 但是事情具體怎么做扎拣，是沒(méi)有畫(huà)面感的。
上面的可人工測(cè)試的驗(yàn)收條件素跺，我們甚至可以通過(guò)驗(yàn)收條件中的步驟二蓝，反向推導(dǎo)出 UI原型 (最基本的交互元素)

這里講一個(gè)好玩的真實(shí)故事:
我在18年的時(shí)候，幫助一個(gè)基金公司孵化的一個(gè)產(chǎn)品 - 約伴活動(dòng), 這個(gè)產(chǎn)品當(dāng)時(shí)是外包給深圳某大廠中的一個(gè)小團(tuán)隊(duì)(產(chǎn)品經(jīng)理 后端 前端 測(cè)試 各1名, 共4人指厌，利用業(yè)務(wù)時(shí)間兼職接的單)刊愚， 預(yù)期工yu三個(gè)月，結(jié)果踩验，到我接手的時(shí)候鸥诽，實(shí)際已經(jīng)干了七八個(gè)月了商玫，每次交付的時(shí)候，一堆Bug牡借，外加一堆實(shí)現(xiàn)與需求不符的改進(jìn)問(wèn)題拳昌。

我觀察了兩次交付之后，叫他們說(shuō)钠龙，把測(cè)試計(jì)劃和用例拿給我看看炬藤，結(jié)果丟給我一個(gè)簡(jiǎn)單的功能模塊的思維導(dǎo)圖，告訴我俊鱼，這就是他們的測(cè)試計(jì)劃和用例刻像，當(dāng)時(shí)畅买，我下巴都快掉下來(lái)了并闲，他們還跟我說(shuō)，他們廠(深圳最大的游戲場(chǎng))谷羞，就是這么工作的帝火。
這簡(jiǎn)直顛覆我的大廠的認(rèn)知呀。幾個(gè)人湃缎，都還是30左右歲的大齡資深從業(yè)者了犀填。
然后還說(shuō)，交付質(zhì)量不好 測(cè)試不到位嗓违，是因?yàn)闇y(cè)試人手不足九巡，測(cè)試只有一個(gè)人，測(cè)不過(guò)來(lái)蹂季，其他人有不知道該如何測(cè)冕广，幫不上忙。

實(shí)現(xiàn)與預(yù)期不符偿洁，外包團(tuán)隊(duì)說(shuō)是需求變更撒汉，基金公司說(shuō)是他們需求沒(méi)理解到位。這個(gè)問(wèn)題從day one就有涕滋，雖各執(zhí)一詞睬辐，卻彼此都沒(méi)有拿得出手的邊界證明，就這么每次交付的時(shí)候宾肺，重復(fù)著這個(gè)場(chǎng)景溯饵，就這么從原來(lái)預(yù)期的三個(gè)月，干到了七八個(gè)月都還沒(méi)能上線锨用。

我便喊停了開(kāi)發(fā)工作瓣喊，要求通過(guò)驗(yàn)收條件來(lái)界定交付范圍，和清晰場(chǎng)景黔酥。訓(xùn)練了那個(gè)團(tuán)隊(duì)如何編寫驗(yàn)收條件藻三，用了一個(gè)多星期洪橘，把功能故事與驗(yàn)收標(biāo)準(zhǔn)全部梳理一遍，召集整體進(jìn)行確認(rèn)棵帽。 驗(yàn)收條件規(guī)定怎么做熄求，就怎么做。做少了 偏了 就是外包團(tuán)隊(duì)的問(wèn)題逗概；基金公司提出驗(yàn)收條件之外的東西弟晚，就屬于需求變更，可以重新談費(fèi)用逾苫。

其結(jié)果就是卿城，有了驗(yàn)收條件后，人人都能夠根據(jù)驗(yàn)收條件做測(cè)試铅搓，基金公司這邊的另一個(gè)小團(tuán)隊(duì)也能投入幫忙做驗(yàn)收瑟押，兩個(gè)Sprint，項(xiàng)目便交付上線星掰。

可人工測(cè)試的驗(yàn)收條件實(shí)例

Feature: US003_提交工作日?qǐng)?bào)
  做為一名 極客
  我想要提交我今天的工作日?qǐng)?bào)
  以便于其他人了解我的一天工作情況

 Scenario: AC_US003_003 正常提交工作日?qǐng)?bào)
     Given 我已經(jīng)作為用戶 John 登錄
       And 我尚未填寫過(guò)任何日?qǐng)?bào)
      When 我已打開(kāi)頁(yè)面 "新建日志"
       And 我選擇日?qǐng)?bào)時(shí)間為 2020-11-15
       And 在完成中輸入提交工作日?qǐng)?bào)用戶故事
       And 在待辦中輸入日?qǐng)?bào)列表故事
       And 在心得體會(huì)中輸入Elixir真實(shí)方便
       And 在做得好的地方中輸入項(xiàng)目結(jié)構(gòu)整理
       And 在心得體會(huì)中輸入Elixir真實(shí)方便
       And 在自我評(píng)價(jià)中選取工作輕松
       And 我點(diǎn)擊按鈕創(chuàng)建
      Then 應(yīng)當(dāng)看到提示日?qǐng)?bào)提交成功
       And 我應(yīng)當(dāng)在日?qǐng)?bào)詳情頁(yè)面

再進(jìn)一步多望，可人工測(cè)試的驗(yàn)收條件，便能成為 可自動(dòng)化測(cè)試的驗(yàn)收條件

Feature: US003_提交工作日?qǐng)?bào)
  做為一名 極客
  我想要提交我今天的工作日?qǐng)?bào)
  以便于其他人了解我的一天工作情況

  Scenario: AC_US003_003 正常提交工作日?qǐng)?bào)
     Given 我已經(jīng)作為用戶 "John" 登錄
       And 我尚未填寫過(guò)任何日?qǐng)?bào)
      When 我已打開(kāi)頁(yè)面 "新建日志"
       And 我選擇 "日?qǐng)?bào)時(shí)間" 為 "2020-11-15"
       And 在 "完成" 中輸入 "提交工作日?qǐng)?bào)用戶故事"
       And 在 "待辦" 中輸入 "日?qǐng)?bào)列表故事"
       And 在 "心得體會(huì)" 中輸入 " Elixir真實(shí)方便"
       And 在 "做得好的地方" 中輸入 "項(xiàng)目結(jié)構(gòu)整理"
       And 在 "心得體會(huì)" 中輸入 "Elixir真實(shí)方便"
       And 在 "自我評(píng)價(jià)" 中選取 "工作輕松"
       And 我點(diǎn)擊按鈕 "創(chuàng)建"
      Then 應(yīng)當(dāng)看到 "提示" 為 "日?qǐng)?bào)提交成功"
       And 我應(yīng)當(dāng)在 "日?qǐng)?bào)詳情" 頁(yè)面

- UI自動(dòng)化測(cè)試

講到UI自動(dòng)化測(cè)試氢烘，常見(jiàn)的幾個(gè)問(wèn)題

• 誰(shuí)來(lái)寫怀偷？
• 誰(shuí)維護(hù)？
• UI自動(dòng)化測(cè)試什么時(shí)候?qū)懀?
  • 功能穩(wěn)定后寫?
  • 功能開(kāi)發(fā)完成后寫播玖？
  • 功能開(kāi)發(fā)過(guò)程中寫椎工？
  • 功能開(kāi)發(fā)前寫？

• 什么是UI自動(dòng)化測(cè)試腳本蜀踏？

  
  
  是RobotFramework的代碼维蒙？
  
  
  是Cucumber的代碼?

我發(fā)現(xiàn)絕大多數(shù)人的UI自動(dòng)化測(cè)試認(rèn)知是錯(cuò)誤的！

有效的做法是

• 誰(shuí)來(lái)寫脓斩？ (開(kāi)發(fā)團(tuán)隊(duì) + PO)
• 誰(shuí)維護(hù)木西？ (開(kāi)發(fā)團(tuán)隊(duì) + PO)
• UI自動(dòng)化測(cè)試什么時(shí)候?qū)懀?br> 應(yīng)當(dāng)是在 功能開(kāi)發(fā)前寫
• 什么是UI自動(dòng)化測(cè)試腳本？
  驗(yàn)收條件才是UI自動(dòng)化測(cè)試腳本随静， 那些 RobotFramework Cucumber的steps八千，只能稱為基礎(chǔ)性支撐腳本。

驗(yàn)收條件 才是UI自動(dòng)化測(cè)試腳本

- BDD的UI自動(dòng)化測(cè)試帶來(lái)的哪些收益

• 用戶故事拆解驗(yàn)收標(biāo)準(zhǔn)完成燎猛，即測(cè)試用例也完成

• 不再是單純依靠測(cè)試人員寫恋捆，有效緩解測(cè)試人員的工作負(fù)載

• 測(cè)試用例團(tuán)隊(duì)共同維護(hù)，需求變更帶來(lái)的測(cè)試用例維護(hù)成本重绷，近乎為零

• 測(cè)試左移

  • 由于自動(dòng)化測(cè)試在開(kāi)發(fā)人員實(shí)現(xiàn)功能前沸停，就已經(jīng)準(zhǔn)備好?開(kāi)發(fā)過(guò)程中的自測(cè)工作量，最大可減少為原來(lái)的三分之一
  • 迭代內(nèi)交付質(zhì)量至少可以提升50%+

• 相同功能的用戶端(Web App 小程序 H5 ...) 越多昭卓，增加的工作量近乎為零

• 每個(gè)迭代都能自動(dòng)化跑全回歸愤钾，而非妥協(xié)式的局部回歸

驗(yàn)收條件自動(dòng)化的示例

image.png

image.png

image.png

運(yùn)行錄屏 B站傳送門 工作日志驗(yàn)收標(biāo)準(zhǔn)自動(dòng)化錄屏

- 測(cè)試金字塔模型瘟滨？

image.png

這些模式的演變過(guò)程，可以再來(lái)一篇文章解釋 (坑繼續(xù)挖).

5. 單團(tuán)隊(duì)的用戶故事BDD是如何進(jìn)行的?

- Scrum團(tuán)隊(duì)的開(kāi)發(fā)節(jié)奏

image.png

其中能颁，PO-開(kāi)發(fā)-測(cè)試每日 "協(xié)作" 的基礎(chǔ)便是用戶故事與驗(yàn)收條件.
敏捷團(tuán)隊(duì)杂瘸，大家都知道要基于用戶故事來(lái)進(jìn)行開(kāi)發(fā)和協(xié)作，道理都懂伙菊，很多團(tuán)隊(duì)呢還是在迭代前半部分集中開(kāi)發(fā)败玉，后半部分提測(cè)，迭代中的小瀑布很明顯镜硕，這點(diǎn)大家都很容易識(shí)別出來(lái)运翼。

玩的好一點(diǎn)的團(tuán)隊(duì)，能夠一個(gè)故事一個(gè)故事的交付兴枯，這看起來(lái)似乎滿足要求血淌，但是，這些玩的"好"的團(tuán)隊(duì)念恍，也依然普遍存在另一個(gè)瀑布模式六剥，就是單個(gè)故事看起來(lái)是一個(gè)個(gè)交付晚顷，是可以了峰伙，但是整個(gè)業(yè)務(wù)流，卻還是在最后的時(shí)間才能串聯(lián)起來(lái)驗(yàn)證该默。然而滿足業(yè)務(wù)流完整性才是交付的重點(diǎn)和目標(biāo)瞳氓。

因此，我們可以通過(guò)栓袖，用戶故事地圖匣摘，把用戶故事的上下游可視化出來(lái)，通過(guò)上下游的依賴關(guān)系作為優(yōu)先級(jí)裹刮，從而令到整個(gè)業(yè)務(wù)流程音榜，在迭代的前半部分便能完整串聯(lián)和驗(yàn)證，而不是把業(yè)務(wù)流程的整合風(fēng)險(xiǎn)放到最后捧弃。

image.png

這種方式赠叼，便正式基于用戶故事為中心的BDD。哪怕你沒(méi)能做的驗(yàn)收條件的自動(dòng)化违霞，全靠人手測(cè)試嘴办，我戲稱為 人肉BDD，也已經(jīng)能為團(tuán)隊(duì)帶來(lái)50%+的能效提升买鸽。

6. 多團(tuán)隊(duì)的基于用戶故事BDD

單團(tuán)隊(duì)中的內(nèi)部依賴等待問(wèn)題涧郊，在多團(tuán)隊(duì)中，N倍存在眼五，而且還容易造成很大的計(jì)劃 溝通 協(xié)調(diào) 同步 成本妆艘。
解決的方式彤灶，依然以透明依賴，并且反過(guò)來(lái)批旺，用依賴來(lái)驅(qū)動(dòng)多團(tuán)隊(duì)的協(xié)作.

在SAFe中枢希，PI活動(dòng)能夠有效幫助我們一起識(shí)別這些依賴。

image.png

通過(guò)更高視角的用戶故事地圖朱沃，來(lái)識(shí)別并規(guī)劃團(tuán)隊(duì)間的故事優(yōu)先級(jí)

image.png

持續(xù)的通過(guò)依賴順序的反轉(zhuǎn)苞轿，來(lái)打通多個(gè)團(tuán)隊(duì)直接的業(yè)務(wù)數(shù)據(jù)流。

7. 總結(jié)

我們做了這些逗物，至少要知道搬卒，團(tuán)隊(duì)和組織，從中能獲得哪些幫助和收益翎卓，有回報(bào)才能繼續(xù)契邀。

image.png

這上面的收益，是具備疊加效果的失暴。
也就是說(shuō)坯门，
僅做到了第一、二點(diǎn)逗扒，團(tuán)隊(duì)的能效便能提升 20%~30% 以上古戴，這兩點(diǎn)還僅僅是改進(jìn)了做事的方式，還沒(méi)牽涉到團(tuán)隊(duì)技術(shù)實(shí)踐(eg. TDD)上的改變, 便能收獲到的矩肩。
從團(tuán)隊(duì)實(shí)踐的觀察來(lái)看现恼，快的團(tuán)隊(duì)，大概兩到三個(gè)月能夠做好這一點(diǎn)黍檩，慢的團(tuán)隊(duì)有四到五個(gè)月的叉袍。

你可能未必有直觀的理解，提升 20%~30%是什么概念刽酱？
那么我給你個(gè)數(shù)據(jù)喳逛，我們每天的工作時(shí)間是 8小時(shí)，提升 20%~30% 意味在棵里，多出2個(gè)多小時(shí)润文，意味著，你能夠在原來(lái)996的事情衍慎，你能夠在正常工作時(shí)間內(nèi)完成转唉。 在公司不再加碼的情況下，你從需要996的時(shí)間才能交付的東西稳捆，變成了正常工作時(shí)間就能交付赠法。
原來(lái)996的時(shí)間，你便可以用來(lái)學(xué)習(xí)，提升砖织，改進(jìn)款侵，還技術(shù)債。
看侧纯，消滅996新锈，是不是沒(méi)那么難呢？

從上往下的每一步眶熬，都是團(tuán)隊(duì)成長(zhǎng)的自然進(jìn)程妹笆，而且，當(dāng)前的每一步都是在團(tuán)隊(duì)當(dāng)前的能力情況下娜氏，稍微努力便能達(dá)到的拳缠。
而且，當(dāng)前的這一步贸弥，做到了窟坐，團(tuán)隊(duì)自然而然的，就會(huì)往下一步前進(jìn)绵疲，因?yàn)檎茉В找娴恼蚍答仭?/p>

這條路徑，正好是團(tuán)隊(duì)成長(zhǎng)的快樂(lè)路徑盔憨。

在這個(gè)過(guò)程中BDD TDD徙菠，也就是自然達(dá)成的。

我也多次在交流中表達(dá)般渡，BDD TDD難懒豹，是因?yàn)?姿勢(shì)不對(duì)芙盘， 路徑不對(duì)驯用，以及開(kāi)發(fā)語(yǔ)言不對(duì)。