看板實戰(zhàn)

• 在制品（WIP）
  我們將剖析在制品( Work In Process, WIP)的概念迅箩。首先，讓我們談?wù)刉IP這個縮寫梦谜，以及這個詞該如何解釋异希。WIP至少有兩個不同的含義:
  1.進行中的工作
  2.流程中的工作
  這兩個意義在精益文獻中都被廣泛使用。我們研究精益和看板的時候挡育，碰巧看到了“流程中”這個詞巴碗。在本書中，我們使用“流程中”這個表述即寒，但如果您愿意的話橡淆，也可以把這個詞換成“進行中”。

• 什么是在制品
  在制品是指你手頭正在處理的所有事情母赵，包括正在處理的任務(wù)逸爵、等著被驗證或者部署的工作項、還有那些雖然還沒開始處理凹嘲，但已經(jīng)等在你的收件箱里的事情师倔。也就是，所有那些需要完結(jié)周蹭，才能交付最終客戶價值的半成品趋艘。

• 約束在制品
  本章談到了流程中的工作，特別討論了通過約束在制品來縮短前置時間谷醉。利特爾法則確定無疑地告訴我們，更多的在制品會讓每個工作項的周期時間變長冈闭。你應(yīng)該約束在制品俱尼，以獲得更快的流速和更短的前置時間。

• 在制品形式
  在制品有多種表現(xiàn)形式萎攒，我們看看軟件開發(fā)領(lǐng)域中的幾種常見的表現(xiàn)形式:
  1.沒有被實現(xiàn)的需求規(guī)格說明;
  2.“在我的機器上可以運行”但還沒有集成的代碼;
  3.未測試的代碼遇八，它們可能符合也可能不符合你的標準;等待下一次發(fā)布矛绘，還沒有進入生產(chǎn)環(huán)境的代碼。大量在制品會帶來的問題和負面影響:.
  4.更多的上下文切換;
  5.被拖長的反饋環(huán)刃永，進而給你帶來額外工作货矮。
  還有我們提到的，有過多的在制品的幾個表現(xiàn)形式:
  風(fēng)險增加;
  消耗變多;
  質(zhì)量下降;
  動力降低斯够。

W1P太高
工作閑置
WIP太低
人員閑置

用戶故事與敏捷實踐

• 用戶故事
  故事卡包含對用戶或者客戶有價值的功能的簡短描述囚玫。
  故事卡是故事的可見部分， 但客戶團隊和開發(fā)人員關(guān)于故事的對話更重要读规。
  故事卡由客戶團隊編寫抓督， 因為他們最了解如何表達需要實現(xiàn)的需求， 也因為他們會在后期與開發(fā)人員共同確定故事細節(jié)并安排故事的優(yōu)先級順序束亏。按照故事對客戶的價值來安排故事的優(yōu)先級順序铃在。將各個故事放入迭代，進行發(fā)布與迭代規(guī)劃碍遍。

速率是開發(fā)人員可以在一-輪迭代中完成的工作量定铜。
如果故事太大以至于無法在一輪迭代中完成，可以考慮把它分成兩個或更多的小故事怕敬。
用戶故事是很有意義的揣炕， 因為它們強調(diào)口頭交流，你和開發(fā)人員都可以理解赖捌，可以用于進行迭代計劃祝沸，在迭代開發(fā)過程中能很好地工作，而且因為它們鼓勵推遲細節(jié)越庇。

優(yōu)秀的故事應(yīng)該具備以下特點罩锐，INVEST來代表這六個特征：
1.獨立的(Independent)
2.可討論的(Negotiable)
3.對用戶或客戶有價值的(Valuable to Purchasers or Users)
4.可估計的(Estimatable)
5.小的(Small)
6.可測試的(Testable)
故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價值。最好的做法是讓客戶編寫故事卤唉。故事可以注釋一- 些細節(jié)涩惑，但是過多的細節(jié)會使故事難以理解，也可能給人一一種開發(fā)人員和客戶無需交談的錯覺桑驱。給故事加上注釋的最好方法是給它編寫測試用例竭恬。 如果故事太大，復(fù)合故事和復(fù)雜故事可以分成幾個小的故事熬的。如果故事太小痊硕，幾個小故事可以合并成-一個較大的故事。故事應(yīng)該是可以測試的押框。

• 驗收測試
  驗收測試用于驗證實現(xiàn)的故事是否開發(fā)成符合客戶團隊的設(shè)想岔绸。
  驗收測試可以用來記錄客戶和開發(fā)人員討論的很多細節(jié)。
  驗收測試記錄了有關(guān)故事的一-些假設(shè),這些假設(shè)可能還沒有和開發(fā)人員討論過。
  驗收測試提供了檢查故事是否被完整實現(xiàn)的基本標準盒揉。驗收測試應(yīng)由客戶來寫而不是開發(fā)人員晋被。驗收測試應(yīng)在程序員寫代碼之前就寫好。 如果新的測試對闡明故事的細節(jié)或意圖沒有任何幫助刚盈， 就不用再寫羡洛。
  FIT和FitNesse是寫驗收測試的優(yōu)秀工具，它們用的是我們熟悉的表格或電子表格格式藕漱。
  開發(fā)人員職責(zé)
  若團隊覺得有需要欲侮，則負責(zé)實現(xiàn)自動化驗收測試。
  開始開發(fā)一個新的故事時谴分，負責(zé)考慮更多的驗收測試锈麸。
  負責(zé)為代碼作單元測試，使驗收測試就不必顧及故事的每個細節(jié)牺蹄⊥。客戶職責(zé)
  負責(zé)編寫驗收測試。
  負責(zé)執(zhí)行驗收測試沙兰。

• 故事點
  一種可以滿足所有這些目標的估算方法氓奈，即用故事點(story point)估算。故事點有個很好的特性是團隊可以定義自己認為合適的故事點鼎天。一個團隊可能決定定義一個故事點為一個理想日的工作(也就是說舀奶，一天中沒有任何干擾，沒有會議斋射，沒有電子郵件育勺，沒有電話，等等)罗岖。另一個團隊可能定義一個故事點為一個理想周的工作涧至。還有一個團隊可能把-一個故事點作為故事復(fù)雜度的測量。
  要正確使用故事點桑包，請記住下面幾點南蓬。
  你的團隊的故事點和我的團隊的故事點是不一-樣的
  一個故事(可能是一一個史詩故事)分解成-一些小故事后，這些小故事估算的總和不需要與開始那個故事或史詩故事的估算相等哑了。
  赘方。這些任務(wù)估算的總和不需要與故事的估算相等。

• 用故事點估算故事,
  故事點是故事復(fù)雜度弱左、工作量或工期的相對估算窄陡。
  應(yīng)由團隊估算故事， 估算屬于團隊而不是個人拆火。
  通過和其他估算進行比較來進行三角測量跳夭。
  團隊是否使用結(jié)對編程對故事點估算沒有影響鳖悠。
  結(jié)對編程影響的是團隊的速率,不是他們的估算。
  開發(fā)人員職責(zé)
  責(zé)用一個方式定義故事點优妙，并且對團隊可用和相關(guān)的。努力保證這個定義的一致性憎账。
  負責(zé)給出誠實的估算套硼。不屈服于誘惑或壓力而給出低的估算。負責(zé)以團隊估算胞皱。
  負責(zé)估算應(yīng)與其他估算--致邪意。即所有2點的故事都應(yīng)差不多。
  客戶職責(zé)
  負責(zé)參加估算會議反砌， 但是你的任務(wù)是回答問題并澄清故事細節(jié)雾鬼。你不必參與故事估算。

• 用戶故事估算
  為了計劃一個發(fā)布宴树， 客戶必須排列故事的優(yōu)先級策菜。 把故事劃分成諸如高優(yōu)先級、中等優(yōu)先級和低優(yōu)先級這三種類型是很有用的酒贬，但這會導(dǎo)致乏味冗長的爭論又憨，會針對某個故事是高優(yōu)先級還是中等優(yōu)先級而爭論不休。幸運的是锭吨，我們可以借用來自DSDM的方法蠢莺，它是另--種敏捷過程”。
  DSDM包括一個 排列優(yōu)先級的方法零如，稱之為莫斯科(MoSCoW)規(guī)則躏将。MoSCoW是以下短語的縮寫:
  必須有(Must have)
  應(yīng)該有(Should have)
  可以有(Could have)
  這次不會有(Won't have this time)
  “必須有的功能”是指系統(tǒng)的基本功能。 “應(yīng)該有的功能”是指很重要但短期內(nèi)有替代解決方法的功能考蕾。如果項目沒有時間約束祸憋，通常認為應(yīng)該有的功能是強制性的≡玻“可以有的功能”是指如果沒時間就可以在發(fā)布中不予考慮的功能夺衍。列為“不會有的功能”是客戶期望擁有但同時承認需要在后續(xù)發(fā)布中實現(xiàn)的功能。