業(yè)務(wù)特性：

1仔沿、我們是內(nèi)部的工具和平臺部門坐桩，主要的客戶群體是面向研發(fā)和交付線的同事以及領(lǐng)導(dǎo)們；

在輸入隊列封锉，任務(wù)優(yōu)先級排序绵跷，以及在制品的數(shù)量控制上都有一定的自主性，同時我們的交付事務(wù)成本和協(xié)調(diào)成本都很低成福，對于發(fā)布我們做了一鍵升級碾局，自動化的發(fā)布控制和針對產(chǎn)品升級的優(yōu)化設(shè)計（構(gòu)建隊列中的流程在升級后會繼續(xù)運行，升級對關(guān)鍵特性的流程調(diào)度任務(wù)沒有任何影響）

2闷叉、我們從以往的經(jīng)驗和上個迭代統(tǒng)計的數(shù)據(jù)得到擦俐，迭代中的插入任務(wù)占比：30%多

3、支撐性和維護工作占比工作量進：30%左右

4握侧、我們有版本迭代和里程碑的固定日期交付任務(wù)

看板演進：

起始我以為我們適合scrum的時間盒（其實我自己當(dāng)時不太了解）蚯瞧，就準(zhǔn)備用個板子按照書上的所說先做起來，然后慢慢的學(xué)習(xí)理論加實踐來改進

第一次看板：

圖丟失只有基本的pool品擎，dev tested埋合，ready，release萄传，c&a基本環(huán)節(jié)甚颂，在設(shè)置每個環(huán)節(jié)上都沒有仔細的考量（當(dāng)時也不懂具體的設(shè)計），主要在于先落地實踐秀菱。

第二次看板：

為什么把code review作為一個獨立的流轉(zhuǎn)環(huán)節(jié)（一是振诬、一個團隊成員提議的，也是為了促進大家的積極性減少落地障礙衍菱；二是赶么、code review我們也確實認為是一個重要環(huán)節(jié)和工作）

第三次看板：

改變是 確定了Doing的事務(wù)范圍，修改流轉(zhuǎn)的環(huán)節(jié)脊串，團隊內(nèi)達成共識辫呻，認為測試前要進行code review清钥。并設(shè)定了testing的限額，防止任務(wù)擠壓（在迭代的第二周發(fā)現(xiàn)我們的testing出現(xiàn)大量的擠壓放闺，我們只有一名測試人員祟昭，需要測試、發(fā)布版本怖侦、平時的業(yè)務(wù)支撐篡悟，所以限定測試環(huán)節(jié)的限額，強制減少轉(zhuǎn)入础钠，同時在測試擠壓時研發(fā)人員介入測試）

第四次看板：

Code Review不作為一個流動環(huán)節(jié)恰力，制約了任務(wù)的流轉(zhuǎn)（一是大家認為每一個需求做一次code review時間上來不及，第二可能也不必要旗吁，但是對關(guān)鍵模塊全員參與的代碼走查帶來的價值團隊成員都比較認可）踩萎，而是隱含在具體的事務(wù)工作中，此處的code review是做模塊級別的代碼走查很钓，同時計劃引入走查系統(tǒng)針對小的改動直接按單走查（尚未開展）香府，按模塊的code review已經(jīng)達成共識并在試運行了

PS：到這里還不是一個可用或是稍微正確的看板，僅能算作是一個任務(wù)跟蹤可視化板子

第五次看板：

經(jīng)劉部的指導(dǎo)码倦，并且也看了些書籍企孩，仔細思考了我們自己的業(yè)務(wù)模型和工作流方式，在看書和設(shè)計看板的工作流轉(zhuǎn)中都做了深入的思考袁稽，每一項為什么是這樣勿璃，工作流投影過來的方式是不是這個樣子，我們上個迭代和以往的工作中都有哪些具體的問題等推汽，結(jié)合這些問題進而做了下面的這個看板补疑。

通過前面介紹的業(yè)務(wù)模型，我們確實更加的適合看板這種拉動模式歹撒，我們也限定了我們的在制品莲组，具體的一些做法和思考如下：

1、為什么每個人的任務(wù)預(yù)留是3個暖夭？

這個是劉部的指導(dǎo)和最終與大家討論的結(jié)果锹杈，很多時候我們每個人手中同時做的任務(wù)有多個，太多了會分散大家的注意力迈着，降低開發(fā)效率竭望，太少可能因為相互依賴產(chǎn)能不好釋放。

2裕菠、我們只有一個測試人員咬清，為什么還設(shè)置測試中的限額是3，為什么不在測試中前面加一個緩沖待測試？

第一為什么不加緩沖枫振，原因是我們的版本受控庫只有一個，既是開發(fā)庫又是受控庫萤彩，如果轉(zhuǎn)入測試那么代碼一定需提交粪滤，此時如果有發(fā)布的需求，要封版本雀扶，未測試完成合入版本的功能代碼回退成本高杖小，并且團隊對回退有抵觸，不回退又會導(dǎo)致待測隊列太長愚墓，遲遲無法交付予权。（研發(fā)模式和版本受控方式先不改變，先按既定規(guī)則浪册，同時引入下面的方式來提高人員對質(zhì)量和全流程的關(guān)注）

第二為什么只有一個測試人員限額不就是3嗎扫腺，為什么還要設(shè)置為3？ 這個是為后續(xù)考慮村象，因為上一個迭代和以往的工作中我們發(fā)現(xiàn)測試這個環(huán)節(jié)成為瓶頸笆环。敏捷也不推薦按工作類型劃分職責(zé)角色，但專業(yè)的人來做專業(yè)的事還是有必要的厚者。我們后面準(zhǔn)備把測試的閥值設(shè)置為5或6躁劣，降低此處的瓶頸，人力從何而來库菲，我們準(zhǔn)備從研發(fā)人員中每個迭代周期抽調(diào)部分人員的部分產(chǎn)能投入到測試中账忘，這樣既讓大家了解全流程的運作又提高大家對“全流程”質(zhì)量的認識。

3熙宇、為什么已測試隊列限額為5鳖擒？

前面描述了，我們的交付事務(wù)成本和交付協(xié)調(diào)成本很低奇颠，如果按照準(zhǔn)出規(guī)則輸出的產(chǎn)品败去，只需要執(zhí)行一個發(fā)布流程就可以自動的發(fā)布版本了，而且是無縫的發(fā)布烈拒，對用戶來說幾乎沒有影響圆裕。

有了這個前提，我們希望盡快的把需求交付出去（交付等待時間越長荆几，變更成本和質(zhì)量風(fēng)險就越大吓妆，比如看板書中說的一些隱性約束），設(shè)置在制品限額為5吨铸，當(dāng)達到限額時就必須封版本行拢，作為一次交付版本。

4诞吱、為什么發(fā)布這個大項中還有一個已驗證的環(huán)節(jié)舟奠？

我們是對內(nèi)交付竭缝，我們的一個需求交付必須得到最終的用戶使用和驗證后才算一個需求交付最終完成。

第六次看板：

此次的變化時測試中的在制品限制為5沼瘫，當(dāng)前雖然還未設(shè)置虛擬人的角色抬纸，但有部分的功能不通過專職的測試人員來完成。

以上都是任務(wù)流轉(zhuǎn)的設(shè)置以及簡單運作的第一階段耿戚，還有最重要的事湿故，準(zhǔn)入準(zhǔn)出規(guī)則的落地和質(zhì)量內(nèi)建的工作。

現(xiàn)在指定了測試準(zhǔn)入和準(zhǔn)出的規(guī)則：

1膜蛔、進入測試中坛猪，比如要保證自測通過，自測說明皂股，單元測試用例

解決辦法墅茉，加強下一環(huán)節(jié)對流入的檢查，測試覆蓋率現(xiàn)在暫不強制

2屑墨、測試完成的準(zhǔn)出規(guī)則躁锁，需求維度的測試報告，測試全流程卵史，發(fā)布物描述战转，影響子系統(tǒng)說明

解決辦法，完善對版本質(zhì)量的冒煙測試建設(shè)以躯，減少新引入需求導(dǎo)致的重大故障

看板準(zhǔn)備增加和優(yōu)化：

1槐秧、服務(wù)分類，看板上的最上面一個泳道是固定交付期的任務(wù)忧设，也是一個加速泳道

2刁标、發(fā)布次數(shù)，以及故障統(tǒng)計（每一次發(fā)布的故障數(shù)）

3址晕、以用戶故事為交付維度膀懈，下面的是分解任務(wù)，任務(wù)關(guān)聯(lián)具體的用戶故事谨垃，對外交付都是故事

4启搂、統(tǒng)計每個用戶故事或是任務(wù)的實際開發(fā)時間，計算準(zhǔn)時交付率

未完待續(xù)：我們是完整的研發(fā)交付流程刘陶，在團隊看板的演進過程中胳赌，看板的空間約束了一些關(guān)鍵價值節(jié)點的呈現(xiàn)，下一階段我們主要是質(zhì)量內(nèi)建匙隔、關(guān)注服務(wù)分類疑苫，并持續(xù)改進的等待下一個階段的到來。

附這段時間統(tǒng)計的累積流圖：