前言

在前面項(xiàng)目結(jié)項(xiàng)時(shí)，團(tuán)隊(duì)進(jìn)行項(xiàng)目反思會(huì)，大家提了很多有關(guān)質(zhì)量方面的擔(dān)憂。擔(dān)憂是兩個(gè)方面的：一個(gè)方面前期項(xiàng)目技術(shù)穿刺的特點(diǎn)，以進(jìn)度優(yōu)先，質(zhì)量方面還有不足；另外團(tuán)隊(duì)未來開發(fā)測(cè)試比例調(diào)整到4：1以后，如果用單元測(cè)試來保障功能，是否可行。最近兩個(gè)迭代也嘗試推進(jìn)需求實(shí)例化有一些進(jìn)步，也暴露出一些問題?？赡苄枰恍└到y(tǒng)的思路來使得敏捷繼續(xù)前行。

和產(chǎn)品經(jīng)理宇總討論后，結(jié)合Thoughtwork方教練的診斷，確定未來3-6個(gè)月的敏捷實(shí)踐落地計(jì)劃。主要有個(gè)以下幾個(gè)方面：

1、敏捷過程重構(gòu)

當(dāng)前的敏捷運(yùn)行模式以實(shí)用為主導(dǎo)，結(jié)合前期項(xiàng)目特點(diǎn)，以技術(shù)預(yù)研和快速實(shí)現(xiàn)為準(zhǔn)。在技術(shù)驗(yàn)證，代碼質(zhì)量改進(jìn)（修改告警和圈復(fù)雜度），架構(gòu)提示以及TDD試行方面，進(jìn)步很大。在和產(chǎn)品經(jīng)理確認(rèn)以后，和方教練請(qǐng)教以后，確認(rèn)一下提升點(diǎn)：

1）故事地圖梳理

現(xiàn)狀：Backlog以Excel保存，每次PO根據(jù)項(xiàng)目階段提供一個(gè)故事范圍，拆分成故事以后，在需求會(huì)議進(jìn)行評(píng)審討論。后續(xù)依次進(jìn)行迭代計(jì)劃安排。

改進(jìn)思路：

用戶故事地圖已經(jīng)成為敏捷需求規(guī)劃中的一個(gè)流行方法。用戶故事地圖可以將你的backlog變成一張二維地圖。 主要用于解決敏捷需求分析過程中的問題：

– 只見樹木不見林，重要的待辦項(xiàng)容易淹沒在各種細(xì)節(jié)中看不到全貌，因而難以排列優(yōu)先級(jí)

– 不能明顯地聚焦于用戶需求– 很難了解不同粒度故事(史詩(shī)故事、主題故事以及故事)之間的關(guān)系

– 不能方便地了解系統(tǒng)提供的功能的完整性

– 不能方便地了解系統(tǒng)提供的工作流以及價(jià)值流

– 不能方便地利用遞增和迭代的方式去確定發(fā)布計(jì)劃以及發(fā)布目標(biāo)

用戶故事結(jié)構(gòu)

– 每個(gè)用戶故事地圖代表一個(gè)完整的用戶故事

– 地圖的核心是一條從左到右的時(shí)間線

– 時(shí)間線的上部放置最大粒度的內(nèi)容（可以理解為Epic）

– 時(shí)間線的下部的第一行放置二級(jí)粒度內(nèi)容（可以理解為backlog item），并在每個(gè)一級(jí)粒度下按照從左到右的優(yōu)先級(jí)進(jìn)行放置

– 每個(gè)二級(jí)粒度內(nèi)容的下面，自上而下放置三級(jí)粒度內(nèi)容（可以理解為task）

最終我們繪制出來一個(gè)完整的端到端的用戶故事。

拆分示例

實(shí)踐計(jì)劃: leangoo上有用戶故事地圖的模板（可以參考下圖模板），后續(xù)用戶故事地圖在此維護(hù)。12月份開始試點(diǎn)，后續(xù)逐步統(tǒng)一在此維護(hù)。責(zé)任人：PO，SM

用戶故事地圖模板

2）N-1迭代第二周中期進(jìn)行N迭代故事評(píng)估

現(xiàn)狀：一般迭代開始前進(jìn)行故事澄清。內(nèi)容較多時(shí)，單獨(dú)成會(huì)。焦點(diǎn)集中在需求本身。

改進(jìn)：

時(shí)間提前-單獨(dú)成會(huì)，在前一個(gè)迭代的第二周的中期。

故事澄清-由PO進(jìn)行故事說明，并排列優(yōu)先級(jí)。

故事估算-對(duì)于下個(gè)迭代的故事進(jìn)行評(píng)估，給出團(tuán)隊(duì)整體工作量（可以是人天也可以是故事點(diǎn)）

基于承諾”Commitment”：Product Owner從Product Backlog中取下一個(gè)用戶故事（按照優(yōu)先級(jí)），對(duì)這個(gè)用戶故事進(jìn)行解釋，團(tuán)隊(duì)對(duì)用戶故事進(jìn)行討論，明確需要解決的問題，整個(gè)團(tuán)隊(duì)確定是否能夠在下一個(gè)迭代周期中完成這個(gè)故事，如果團(tuán)隊(duì)沒有信心完成該故事，計(jì)劃會(huì)議結(jié)束，或者把這個(gè)用戶故事進(jìn)一步劃分成更小的用戶故事重復(fù)第一步。如果團(tuán)隊(duì)有信心完成該任務(wù)，重復(fù)第一步。

基于速率”Velocity”：確定Product Backlog中用戶故事的規(guī)模（用“故事點(diǎn)”）確定團(tuán)隊(duì)迭代的開發(fā)速度（“昨天的天氣”）從Product Backlog中取出相應(yīng)量的用戶故事。

3）提前1個(gè)迭代故事測(cè)試用例分析及評(píng)審

現(xiàn)狀：當(dāng)前基于事后分析。

改進(jìn)：結(jié)合故事評(píng)估的改進(jìn)，將測(cè)試用例分析和評(píng)審前移至前一個(gè)迭代。采用故事（特性/需求）->用例（場(chǎng)景）兩級(jí)模式，采用GitLab+MarkDown的方式來管理。

4）4+1會(huì)議不超過1個(gè)小時(shí)

提倡流暢高效運(yùn)作，需要提前準(zhǔn)備內(nèi)容，縮短會(huì)議時(shí)間，有更多時(shí)間聚焦研發(fā)本身。

2. TDD持續(xù)推進(jìn)

TDD進(jìn)展很快，也存在一些問題，具體參見《TDD落地時(shí)間總結(jié)和展望》 。

3. 架構(gòu)診斷及持續(xù)改進(jìn)

在11月份和C++敏捷教練進(jìn)行溝通兄弟版本的診斷問題時(shí)，他提到了架構(gòu)問題。理想國(guó)是DDD來整體重構(gòu)，對(duì)我們來說，不現(xiàn)實(shí)。我們的版本相對(duì)于兄弟團(tuán)隊(duì)框架有了很大提多，因?yàn)橐曇凹寄茉颍瑧?yīng)該還有不足。只有不斷改進(jìn)，才可能保證良好架構(gòu)，保證未來響應(yīng)需求時(shí)，容易實(shí)現(xiàn)而不是頻繁做大的架構(gòu)調(diào)整。

4. 高效代碼走查

代碼走查一直都是有的。如何高效的定時(shí)3點(diǎn)半走查，對(duì)我們來說是一個(gè)難題。后續(xù)結(jié)合兄弟團(tuán)隊(duì)的一些良好做法，形成一個(gè)高效的3點(diǎn)半代碼走查。是未來改進(jìn)的一個(gè)目標(biāo)。

小結(jié)

敏捷過程持續(xù)改進(jìn)、TDD持續(xù)推進(jìn)、高效代碼走查和架構(gòu)持續(xù)改進(jìn)，是未來三個(gè)月敏捷實(shí)踐推進(jìn)的重點(diǎn)。敏捷過程持續(xù)改進(jìn)和TDD持續(xù)推進(jìn)已經(jīng)有了具體思路。高效代碼走查和架構(gòu)持續(xù)改進(jìn)未來在繼續(xù)細(xì)化方案。

參考：https://www.leangoo.com/9944.html

http://www.woshipm.com/pd/270289.html