在傳統(tǒng)的瀑布流程中，我們往往是期望通過前期細致入微的工作來確保一個階段的工作被高質(zhì)量完成之后才移交到下一階段。后來我們慢慢從失敗的經(jīng)驗中學(xué)習(xí)到，這種方法在變化的需求環(huán)境下實在是太過脆弱，不僅不能如愿保證質(zhì)量，而且會造成更大的浪費，交付周期也不能滿足要求。于是我們引入了迭代式開發(fā)方法，一個需求的分析、開發(fā)、測試、驗收成了一個小粒度地更連續(xù)的過程，在這個小的交付循環(huán)中，看板幫助我們以更細節(jié)的粒度來管理一個任務(wù)每個階段的工作質(zhì)量。

　　通常我們是這么做的。當(dāng)我們把一張故事卡從“待開發(fā)”移動到“開發(fā)中”時，這張卡片必須是已經(jīng)分析完成的。也是說，當(dāng)開發(fā)人員準(zhǔn)備真正開始開發(fā)這張故事卡之前，我們的需求分析師們必須保證這張卡片所包含的所有內(nèi)容和細節(jié)已經(jīng)被分析完成，不再有模棱兩可的細節(jié)，不再留給開發(fā)人員過多的自我發(fā)揮和想象空間，而且這些細節(jié)必須和客戶確認過，而不只是團隊自己“設(shè)計”的結(jié)果。

　　這一道關(guān)看似很尋常，實際上很多項目會在這里出問題。很多時候開發(fā)人員開始開發(fā)的時候，需求還沒有分析完成，很多細節(jié)尚須澄清確認，實現(xiàn)上的技術(shù)風(fēng)險還沒有被完全排除。也有的分析師善于給開發(fā)人員留有大量自我發(fā)揮空間，需求過于言簡意賅。開發(fā)人員開始開發(fā)這樣的需求時，要么做不下去，要么按照自己的理解做下去。做完了之后分析師一看發(fā)現(xiàn)不對，和我想的不一樣，于是開發(fā)人員返工。糟糕的情形莫過于后被客戶發(fā)現(xiàn)說，這不是我當(dāng)初想要的東西。

　　由此可見，確保開發(fā)人員挪卡的時候，這張待開發(fā)的用戶故事已經(jīng)被真正分析完成，是我們準(zhǔn)確實現(xiàn)用戶需求的第一步。通過規(guī)定這一挪卡的前提，同時輔以用戶故事的澄清（由分析師向開發(fā)人員澄清）或者反向澄清（由開發(fā)人員向分析師講述自己的理解），可以很大程度上將返工減少到低。

　　還有一種浪費發(fā)生在測試過程中。測試人員經(jīng)常會發(fā)現(xiàn)，處于“待測試”狀態(tài)中的一些故事卡，在測試的時候主要的流程都走不通，根本無法進一步展開測試，于是乎不得不將故事卡

　　打回到開發(fā)人員手中。而往往這個時候開發(fā)人員已經(jīng)工作在另一個用戶故事上了。要么他停下手中的任務(wù)解決測試的問題，要么讓測試人員等到這些問題修復(fù)過后再測。無論哪種都是不好的選擇。

　　這種問題的一個主要原因是因為開發(fā)人員聲稱他已經(jīng)“開發(fā)完成”，將故事卡從“開發(fā)中”挪到“待測試”時，實際上自己并沒有對這部分功能進行測試。或者是因為疏忽，或者是因為懶惰，或者是因為過于自信。通過在這個狀態(tài)轉(zhuǎn)換階段引入用戶故事初驗，讓分析師在挪卡之前先到開發(fā)人員機器上看看是否該故事卡包含的功能被實現(xiàn)了，可以很大程度上提升效率，減少浪費。若分析師在初驗過程中發(fā)現(xiàn)了問題，那么開發(fā)人員馬上能以小的成本進行修復(fù)，而不用等到之后測試人員發(fā)現(xiàn)時再來修復(fù)。而且，分析師初驗也提供了一個判斷實現(xiàn)是否良好的反饋點，這是我們能夠看到一個需求是否被實現(xiàn)并能夠真正工作的早的時間點。

　　2.2 如何避免多任務(wù)并行

　　多任務(wù)之間的頻繁切換是一個常見的問題。表現(xiàn)在團隊里的成員，特別是開發(fā)人員，會在不同的任務(wù)間切換。像前面的故事中提到的，可能這一刻還在實現(xiàn)某一個需求，而下一刻馬上會被叫走去修復(fù)某一個遺留版本的缺陷。又或者該人手頭被分配了多個任務(wù)，每個任務(wù)都在進行中，而沒有一個處于完成狀態(tài)。任務(wù)切換是導(dǎo)致效率降低的一個重要原因，不同任務(wù)間的上下文的切換會導(dǎo)致頻繁地將任務(wù)當(dāng)前狀態(tài)在頭腦中“壓！焙汀俺鰲！，這些操作會耗費時間。如果完成一個任務(wù)需要一個人時間，那么兩天內(nèi)這個人可以完成兩個任務(wù)，但是如果他在第同時開始并行工作在這兩個任務(wù)上，那么完成這兩個任務(wù)會需要大于兩天的時間。

　　大家可能已經(jīng)注意到了，在前面的看板圖中，處于“開發(fā)中”的所有任務(wù)卡片上都有一個小紙條，上面標(biāo)記著正在這張卡片上工作的人的名字。如果說有兩個人結(jié)對在一個卡片上工作，那么這張卡片上應(yīng)該有兩個名字。這一小小的實踐可以幫助我們隨時發(fā)現(xiàn)團隊內(nèi)某一時刻，是否每個人只工作在一個任務(wù)上。

　如果這一簡單的規(guī)則能夠嚴(yán)格被遵循，那么當(dāng)我們看到一個人的名字出現(xiàn)在多張卡片上的時候，我們知道這個人此刻可能忙著在多個任務(wù)之間切換，而每一個任務(wù)都將不會在估計的時間點內(nèi)完成。如果我們看到有人的名字沒有出現(xiàn)在任何卡片上，那么他目前大概處于休息狀態(tài)。團隊內(nèi)的每個人的名字都應(yīng)該對應(yīng)在一個小紙條上，如果你此刻工作在某個任務(wù)上，那么將自己的名字貼到相應(yīng)卡片上，如果此刻沒有工作在該任務(wù)上，將自己的名字移去。

　　我們在領(lǐng)取“待開發(fā)”狀態(tài)欄中的卡片時，保證每次每人只領(lǐng)一張卡片，不要多領(lǐng)，完成了這張卡片之后，再回來領(lǐng)下一張。當(dāng)一張卡片被認領(lǐng)之后，我們會對這張卡片進行跟蹤，在站會上談?wù)撍耐瓿汕闆r，談?wù)搶崿F(xiàn)過程中碰到的問題。當(dāng)它的進度和估計的可能偏差較大時，我們能夠及時而不是在后一刻察覺到，提供需要的幫助，確保它能夠順利完成。這樣一種方式讓我們能夠?qū)⒆⒁饬械叫×６鹊男枨螅ɡ缬脩艄适拢┥，更多地關(guān)注這些用戶故事的流動速度。而當(dāng)每個小的用戶故事能夠順暢地流動起來時，整個項目的交付也得到了保障。

　　當(dāng)然這一實踐并不能自動保證團隊內(nèi)不再出現(xiàn)多任務(wù)并發(fā)、拖延、或者做和任務(wù)無關(guān)的其他事情等問題？赡苡行┤嗽谧鲆粋用戶故事的過程中，突然中斷去做了一些其他事情，但是

　　卻沒有及時在狀態(tài)墻上更新自己的狀態(tài)。重要的是團隊要有實現(xiàn)交付目標(biāo)的共同愿景，能夠透明地暴露問題，并且善于利用狀態(tài)墻來發(fā)現(xiàn)和改進自身的問題。對于不成熟的團隊，這可能需要一個轉(zhuǎn)變的周期。

　　如果一個團隊的職責(zé)共享較好，代碼被所有人集體擁有，每個人都被鼓勵熟悉和工作在代碼的不同部分，那么在這樣的團隊內(nèi)便不太會出現(xiàn)把一大塊任務(wù)事先明確給某一個人的情況。相反，所有人的工作事先不具體確定，大家會更容易形成某一時刻只領(lǐng)取一張卡片的情況，避免同時工作在多個任務(wù)上。實際上，狀態(tài)墻的使用也可以幫助團隊走向職責(zé)共享之路，只需要在大家領(lǐng)取任務(wù)的時候有意地給人們分配一些之前沒做過的內(nèi)容，同時安排好有經(jīng)驗的人與其結(jié)對工作，一段時間之后，團隊內(nèi)的人便會逐漸體會到和之前只是專注在一個模塊內(nèi)不同的工作方式。

　　2.3 如何減少半成品庫存，縮短交付周期

　　一個需求的交付周期（leadtime）是從它被識別到終交付給用戶手中所耗費的時間。交付周期越短，意味著客戶從提出想法到能夠在軟件中實際使用到這個點子的時間越短。從客戶的角度來看，更短的交付周期意味著自己的軟件能夠?qū)κ袌鲎兓母斓仨憫?yīng)，因而獲得更強的競爭力，同時也意味著能夠更快地驗證自己的想法。

　　任務(wù)管理的粒度太大會直接導(dǎo)致交付周期變長。極端的情況是將屬于某一模塊的任務(wù)在一開始全部分給負責(zé)這個模塊的人，所有這個模塊相關(guān)的修改都由他來實現(xiàn)。在一個按模塊劃分職責(zé)，每個人只負責(zé)自己具體模塊的團隊里，通常這個模塊的負責(zé)人會實現(xiàn)這個模塊的所有修改。不然，是將一個可能需要做2周到一個月的任務(wù)分給某個人；蛘吒靡稽c的情況是，單個任務(wù)本身不大，但是會將相關(guān)聯(lián)的任務(wù)成批地分配給某個人。如果你的團隊內(nèi)也是采用大篇的“規(guī)格說明書”等word文檔來組織需求的，那么要小心，這種問題很可能在團隊內(nèi)已經(jīng)存在。整個團隊沒有小粒度頻繁交付的概念，習(xí)慣了大批量長時間地交付方式。由于批量大，所以估計常常不準(zhǔn)，而且時間跨度長，中間也會有更多地干擾因素出現(xiàn)，這些都導(dǎo)致任務(wù)不能在開始承諾的時間點交付。開發(fā)周期長同樣導(dǎo)致測試活動的滯后，極端地滯后演變?yōu)樗虚_發(fā)工作完成之后才能進行測試，這是我們熟悉的瀑布模式。終的影響是需求的交付周期會很長。