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

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

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

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

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

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

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

　　2.2 如何避免多任務并行

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

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

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

　　我們在領取“待開發”狀態欄中的卡片時，保證每次每人只領一張卡片，不要多領，完成了這張卡片之后，再回來領下一張。當一張卡片被認領之后，我們會對這張卡片進行跟蹤，在站會上談論它的完成情況，談論實現過程中碰到的問題。當它的進度和估計的可能偏差較大時，我們能夠及時而不是在后一刻察覺到，提供需要的幫助，確保它能夠順利完成。這樣一種方式讓我們能夠將注意力集中到小粒度的需求（例如用戶故事）上，更多地關注這些用戶故事的流動速度。而當每個小的用戶故事能夠順暢地流動起來時，整個項目的交付也得到了保障。

　　當然這一實踐并不能自動保證團隊內不再出現多任務并發、拖延、或者做和任務無關的其他事情等問題。可能有些人在做一個用戶故事的過程中，突然中斷去做了一些其他事情，但是

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

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

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

　　一個需求的交付周期（leadtime）是從它被識別到終交付給用戶手中所耗費的時間。交付周期越短，意味著客戶從提出想法到能夠在軟件中實際使用到這個點子的時間越短。從客戶的角度來看，更短的交付周期意味著自己的軟件能夠對市場變化的更快地響應，因而獲得更強的競爭力，同時也意味著能夠更快地驗證自己的想法。

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