国产精品不卡午夜精品网站,女女百合互慰av网站,亚洲福利一区二区三区在线观看

本文是軟件看板之父David Anderson 博客文章，項目管理系列集錦，由Agilean學(xué)院陳玉毅、張明翻譯，侯伯薇審校。

以下為翻譯正文：

一、使用看板方法管理項目

我是項目經(jīng)理，看板對我來說意味著什么?

我是項目經(jīng)理，我的組織正在采用Kanban，它對我意味著什么？以及我應(yīng)該在工作中如何使用看板？在企業(yè)已經(jīng)實施的看板體系中，你的現(xiàn)有角色并未發(fā)生改變，仍然是項目經(jīng)理。然而，為了在已經(jīng)實施的看板系統(tǒng)中充分利用可預(yù)測性和風(fēng)險管理，你應(yīng)該對自己的工作進(jìn)行適當(dāng)調(diào)整。我們相信，看板方法的理念和實踐，會幫助項目經(jīng)理提升到一個新的高度。

如何使用看板來制訂計劃及排列工作優(yōu)先級？

通常，項目經(jīng)理們會問：“如何使用Kanban來制訂計劃，以及排列工作優(yōu)先級？”當(dāng)然，在項目管理中，還有很多的事情要做，但是這兩件事非常重要。

非常重要的一點是：我們應(yīng)該深刻領(lǐng)會到，看板方法中對項目管理產(chǎn)生重大影響的核心實踐是制訂更明晰的規(guī)則。使用了看板方法之后，項目管理就演變成了一種更好地促進(jìn)和實施風(fēng)險管理的活動。項目經(jīng)理在整個項目交付周期中，負(fù)責(zé)制訂各種規(guī)則。這樣一來，項目經(jīng)理的角色，就不僅僅是簡單的項目管理者了。通常，項目經(jīng)理會做好多事情，例如：收集并匯報項目進(jìn)展、組織會議、制訂計劃、發(fā)布管理與變更管理等。另外或許還有一些更細(xì)致的工作，諸如：進(jìn)行任務(wù)分配，或者更為直接的命令和控制方法，以達(dá)到完成工作的目標(biāo)。這樣的項目經(jīng)理，實際是專注于“管人”的，只是在苦苦尋找與特定任務(wù)技能相匹配的人。我認(rèn)為，擁有這種職能的項目經(jīng)理，其角色更像是“項目秘書”或者“項目協(xié)調(diào)人”。這不是一種創(chuàng)造高價值的項目管理實踐。

好的項目管理實踐應(yīng)該是：有些活動能夠輔以自動化手段，而且團(tuán)隊成員應(yīng)該在一些約束條件（或者“規(guī)則”）下進(jìn)行自組織管理。在軍事組織中，這些約束條件，被稱作“約定規(guī)則”。以我的經(jīng)驗來看，美國的軍隊比企業(yè)更懂得如何授權(quán)。

關(guān)于規(guī)則

所以，我們不再孤立地去談“制訂計劃”與“排列優(yōu)先級”。我們更希望項目經(jīng)理以區(qū)別于傳統(tǒng)思維的角度去思考問題，同時也強(qiáng)調(diào)一些細(xì)微差別和更明晰的概念。

在看板方法中，我們探討的是：調(diào)度 (scheduling)、排序(sequencing)、選擇（selection）（即：3S）以及可選項、承諾、產(chǎn)能分配、風(fēng)險管理與規(guī)避。我們使用預(yù)測來替代估算。預(yù)期是建立在概率報告基礎(chǔ)上的，調(diào)度是基于對風(fēng)險承受能力的評估，與之相對，經(jīng)濟(jì)損失是基于特定成果發(fā)生的概率。我們教給項目經(jīng)理們?nèi)绾谓⒁?guī)則來管理這些活動，如何去調(diào)整這些規(guī)則去管理項目的業(yè)務(wù)目標(biāo)和業(yè)務(wù)風(fēng)險。傳統(tǒng)意義上的“制訂計劃”與“排列優(yōu)先級”這些具體的工作，就會從項目制訂的規(guī)則中分離出來。計劃實際上只是規(guī)則所產(chǎn)生的一個附屬成果。

收益

在項目管理中使用看板方法能夠改進(jìn)產(chǎn)出物的質(zhì)量，看板方法提高了項目的可預(yù)見性，并改進(jìn)項目可接受的經(jīng)濟(jì)指標(biāo)。整個項目進(jìn)程更加透明。雖然關(guān)注重點是在規(guī)則的制訂上，但是管理卻得到了改進(jìn)。項目經(jīng)理轉(zhuǎn)變?yōu)橹髯ワL(fēng)險管理，同樣，風(fēng)險管理也得到了很好的改進(jìn)。使用看板方法后，項目經(jīng)理為項目團(tuán)隊和整個組織，創(chuàng)造了更大的價值。

二、使用排序規(guī)則制訂計劃

不排優(yōu)先級，怎么定計劃？

看板方法中，我們不傾向用“排優(yōu)先級”一詞，因為對排優(yōu)先級這件事來說，并非是做一兩次然后形成一份按優(yōu)先級排序的清單那么簡單，在每個工作項在看板系統(tǒng)中被拉動時，都需要動態(tài)排優(yōu)先級?？窗宸椒ㄖ?，排優(yōu)先級不再是一種活動，而是當(dāng)看板系統(tǒng)中形成拉動信號時，根據(jù)可選工作的風(fēng)險情況動態(tài)決策所產(chǎn)生的結(jié)果。

基于風(fēng)險評估進(jìn)行項目排期

由于不再專門排優(yōu)先級，我們的方式是根據(jù)排序策略來制訂項目排期。排序策略是基于風(fēng)險信息的，在項目待辦列表中的每個工作項要使用某種風(fēng)險評估框架進(jìn)行分析（通常是定性分析）。風(fēng)險的所有維度中，“變化帶來的市場風(fēng)險”是最具影響力的一個。按照這個維度工作項大致可分成5類：必須項（Table stakes）、成本縮減項（Cost reducers）、法規(guī)變更項（Regulatory changes）、攪局項或尾隨項（Spoilers或Catch-ups，即跟進(jìn)競爭對手的差異項）、差異項（Differentiators）。在我所著的《Lessons In Agile Management: On the road to Kanban》一書中，對此進(jìn)行了介紹。這種分類方法也可以加入其他可能的類別。有時，我也會加入諸如“誤導(dǎo)類”等其他類別加以充實。然而，這里所提到的5類是最常見的。要點在于選取與項目相關(guān)的風(fēng)險維度和分類方式。如果項目的交付物是某種客戶可交付產(chǎn)品或服務(wù)，并且需要與市面上的類似產(chǎn)品或服務(wù)進(jìn)行競爭比較，或許所處行業(yè)還會受法律監(jiān)管，那么這種特別的分類方法就會非常有用。

軟件看板之父David Anderson：使用看板方法進(jìn)行項目管理

項目中，如果每個特性或需求都使用這個分類體系加以分類，我們就能夠基于風(fēng)險分類設(shè)置不同的策略，并根據(jù)這些策略制訂排期。

必備項（Table stakes）在項目生命周期中沒有變更風(fēng)險，因此它們可以先開始。雖然法規(guī)變更項（Regulatory changes）也是必備項，如果沒有這些項你的項目就無法完工，但它們需要被單獨列為一類，因為這些法規(guī)會根據(jù)政府和法規(guī)制定者而進(jìn)行調(diào)整和變化。

如果可能，最好將法規(guī)變更項（Regulatory changes）分成在整個項目生命周期中都不會變化的項、以及哪些會因為監(jiān)管審查、申訴、或政府和法規(guī)制定者的變化而受到影響的項。任何可能變化的日期都需要加以注意，以便能夠清楚該項何時不再受變化影響。例如，如果已知某個需求會受到政府換屆選舉的影響，那么就應(yīng)當(dāng)在需求定義中標(biāo)注出選舉的日期。

（如上圖）向上到成本縮減項（Cost reducers）、攪局項（Spoilers）、再到差異項（Differentiators），需求的不確定性的程度就會發(fā)生變化，所以，需求定義發(fā)生變更或工作項必要性發(fā)生變化的風(fēng)險隨之升高。我們不希望接手可能會從范圍中刪除或因重大變故而受影響的工作項。所以這些項應(yīng)當(dāng)推遲到項目更晚些時候再開始。

創(chuàng)建用于排序和產(chǎn)能分配的策略

如果項目不存在提前交付的風(fēng)險，我們就應(yīng)先對所有的必備項（Table stakes）排序，然后對所有成本縮減項（Cost reducers）排序，然后是所有的攪局項（Spoilers），最后是差異項（Differentiators）。對于法規(guī)變更項（Regulatory changes），一旦我們知道它們在項目交付日期前不再受到變更影響，就要盡快排期。

那些沒有交付日期提前風(fēng)險的項目，大多具有自然規(guī)律或與季節(jié)性業(yè)務(wù)或行業(yè)相關(guān)，例如，常見于服裝、服飾、時裝制售行業(yè)，或者世界杯或奧運會這種重大體育賽事。所以，如果我們遇到了具有這種性質(zhì)的項目，并且已經(jīng)評估了變更帶來的市場風(fēng)險，我們便能夠為看板系統(tǒng)的排序工作定義出一條簡單的策略。具有相同類別的工作項，比如成本縮減項（Cost reducers），能夠按照任何順序加以完成，因為無論多么細(xì)致地對它們進(jìn)行排優(yōu)先級或排序，都無法獲得風(fēng)險管理帶來的好處。當(dāng)然，前提是因變化導(dǎo)致的風(fēng)險是我們所專注管理的唯一風(fēng)險維度（更多風(fēng)險維度請關(guān)注Agilean公眾號）。通常，我們還會考慮其他風(fēng)險維度，所以策略會比這里所描述的更加錯綜復(fù)雜。

如果存在交付期提前的風(fēng)險，尤其對于商業(yè)產(chǎn)品或服務(wù)類的項目，那么我們就應(yīng)當(dāng)對沖這種風(fēng)險。根據(jù)戰(zhàn)略與市場定位，最有價值的當(dāng)屬攪局項（Spoilers）和差異項（Differentiators），因此，我們應(yīng)當(dāng)通過在看板系統(tǒng)中將產(chǎn)能更多分配給具備更高價值、更高風(fēng)險的項來對沖交付期提前的風(fēng)險。

我們可以通過細(xì)分需求來使得這種對沖的方式更容易。如果我們的產(chǎn)品或服務(wù)面向多個市場細(xì)分或用戶角色，那么每個需求都應(yīng)當(dāng)標(biāo)記上其所支持的市場細(xì)分或用戶角色。我們應(yīng)當(dāng)讓市場人員根據(jù)他們的傾向性（更多是基于當(dāng)前的市場目標(biāo)）對這些市場細(xì)分和用戶角色排優(yōu)先級或排序。比方說，我們希望針對服務(wù)于青少年來提升市場占有率，就應(yīng)給青少年這個細(xì)分或用戶角色更高的優(yōu)先級。

此外，我們應(yīng)當(dāng)在項目生命周期內(nèi)，制定按照一定比例增減產(chǎn)能分配的策略。舉例來說，我們希望最開始給必備項（Table stakes）分配80%的產(chǎn)能，項目收尾前降至0%，而最初差異項僅分配10%的產(chǎn)能，項目結(jié)束前增長值80%。這種產(chǎn)能分配會影響到系統(tǒng)中的看板（信號），并給出具體的拉動信號來告訴我們在任何給定的時刻應(yīng)當(dāng)拉入哪種需求。

風(fēng)險是個多維問題

當(dāng)然了，這篇文章中只關(guān)注單一風(fēng)險維度，而項目風(fēng)險是多維的。在這個領(lǐng)域，有太多的知識需要學(xué)習(xí)，有太多的實踐需要思考。因此，我們的排期策略要遠(yuǎn)比上面描述復(fù)雜得多。例如，我們會考慮技術(shù)風(fēng)險。如果某差異項工作項存在技術(shù)風(fēng)險（以前從未做過，并且不清楚如何來做），那么我們應(yīng)該制定一條策略，規(guī)定需要將這種類工作項拆分為兩部分。拆出的第1個工作項是用原型判定可行性（或者叫做\”spike\”），安排在項目早期以便及時為可行性分析提供有用的信息。拆出的第2個工作項是基于新技術(shù)能力開發(fā)高保真特性。這種差異化特性的實現(xiàn)應(yīng)當(dāng)推遲到項目后期再做。

基于策略的排期勝于傳統(tǒng)的待辦項排優(yōu)先級

沒有必要對項目范圍內(nèi)的每一個工作項進(jìn)行排序。實際上相互獨立的工作項不應(yīng)排序。當(dāng)看板信號指示有能力開始一項工作時，如果制定了一系列基于風(fēng)險評估的策略，我們就可以遵循它們來選擇工作項。這些策略比按優(yōu)先級排序的項目待辦列表更容易維護(hù)，還是一種更強(qiáng)大的風(fēng)險管理工具。要解釋為什么要制訂某一條策略是件很簡單的事情，而且當(dāng)環(huán)境發(fā)生變化，也很容易判斷策略是否也需要變更。策略的改變會立刻反應(yīng)在看板系統(tǒng)中新的工作項選擇決策上。因此沒必要維護(hù)項目待辦項列表。確保項目范圍內(nèi)的所有工作項在承諾時得到風(fēng)險評估，并且根據(jù)項目經(jīng)理所提倡的風(fēng)險管理方法對項目排期策略進(jìn)行維護(hù)，這些就是所要做的全部。

總結(jié)

這篇文章，僅僅是給大家一個關(guān)于使用看板方法進(jìn)行項目管理的初步認(rèn)識，您從中了解到我們?nèi)绾沃朴営媱?，對工作項排序與選擇工作項。學(xué)習(xí)完整的相關(guān)技術(shù)，您可以考慮參加LKU相關(guān)課程。

三、項目預(yù)測

2008年，看板方法第一次震驚了整個敏捷社區(qū)：它不必使用敏捷專家們大力推崇的一些實踐，包括帶有時限的迭代、優(yōu)先級的概念，甚至可以不使用估算！問題來了，如何才能借助一種不使用估算的模型來做項目計劃呢？答案是：使用歷史數(shù)據(jù)或者具有預(yù)測能力的模型構(gòu)建針對項目產(chǎn)出的概率預(yù)測。以下簡要介紹一種簡便而常用的模型，可用于對項目交付進(jìn)度作出預(yù)測。

項目預(yù)測的統(tǒng)計學(xué)支柱

使用看板時，我們可使用兩個關(guān)鍵的理念進(jìn)行項目預(yù)測，一是看板系統(tǒng)所拉動工作的前置時間分布，二是源自排隊論的利特爾法則（Little\’s Law）。

前置時間分布

軟件看板之父David Anderson：使用看板方法進(jìn)行項目管理

圖1 前置時間分布

圖1展示了針對在看板系統(tǒng)中流動的工作項（通常指項目的功能或需求）的前置時間分布。使用類似圖中的歷史前置時間分布前，我們有必要理解幾個假設(shè)，以確保選擇了正確的數(shù)據(jù)。此外，還必須相信，將來觀測到的表現(xiàn)與過去的相似。對于流動效率低下的工作環(huán)境來說，這一點尤其重要。這樣的環(huán)境中，個體技能和所采用的技術(shù)實踐對前置時間有重大影響，而需求的規(guī)?；蛘邚?fù)雜度沒有那么大的影響。因此，對于流動效率低下的環(huán)境，可以在更換人員、大幅改變需求捕獲方式和變更技術(shù)工作實踐的同時，保持觀察到的前置時間分布不會受到重大影響。在流動效率較高的環(huán)境下，我們要注意保持個體的技能和經(jīng)驗與采集歷史數(shù)據(jù)時的高度相似，保持工作實踐與分析和需求開發(fā)方法高度相似。這就可以保證我們可以預(yù)期將來的前置時間分布會與現(xiàn)有的數(shù)據(jù)充分一致，從而使用歷史數(shù)據(jù)進(jìn)行可靠的預(yù)測。

其次，要作出準(zhǔn)確的預(yù)測，需要單一模態(tài)的數(shù)據(jù)。要獲得這樣的數(shù)據(jù)用于前置時間分布，對于不同種類的工作或不同級別的風(fēng)險，需要有各自的分布曲線。因此，對需求進(jìn)行風(fēng)險評估，根據(jù)風(fēng)險類型對歷史數(shù)據(jù)進(jìn)行聚類和過濾，是作出準(zhǔn)確預(yù)測的關(guān)鍵所在。

再次，要創(chuàng)建最適合自己的分布曲線，要知道應(yīng)該從過去多久開始對前置時間直方圖進(jìn)行采樣。這時候前置時間趨勢圖就派上用場了。我們可以觀察趨勢圖中系統(tǒng)設(shè)計的變化，關(guān)注平均時間和數(shù)據(jù)點變差的分散程度。不連續(xù)的點通常反映了系統(tǒng)設(shè)計的變更（有望是改進(jìn)），如果找到這樣的點，只需采集到均值和變差分散程度發(fā)生改變的點即可。換句話說，我們需要一張能夠反映當(dāng)前狀況且不混有早期數(shù)據(jù)點的數(shù)據(jù)直方圖。還有一種找到這一時間點的方法，就是監(jiān)控看板系統(tǒng)的流動性，尋找流動性水平發(fā)生較大變化的日期。這樣的日期可作為制作直方圖時數(shù)據(jù)采樣的歷史時間起點。

只要有了針對項目范圍內(nèi)各類風(fēng)險（服務(wù)級別）或各類工作的直方圖，并假設(shè)項目范圍和需求由工作或者風(fēng)險的類型表示（本系列文章的第二部分已有討論），我們就能應(yīng)用利特爾法則對項目進(jìn)度作出預(yù)測。

圖2 利特爾法則

利特爾法則應(yīng)用于看板時，可表述為：離開看板系統(tǒng)（所有工作完成后被存檔）的工作項的平均交付速度等于系統(tǒng)中看板的數(shù)量（即WIP限制）除以平均前置時間。因此，只要我們知道看板系統(tǒng)的WIP限制以及前置時間的均值，就能計算出已完成的工作交付所需時間。

建立進(jìn)度預(yù)測

圖3展示了在大、中型規(guī)模項目中常用的一種簡單的三階段模型。該模型在為期短至六周、長至數(shù)年的項目中已驗證有效。模型中的參數(shù)是筆者所選，讀者可更換成適合自己的，不過三個階段應(yīng)該足夠。假定時間軸的前20%為第一階段，流動效率相對較低。接下來的60%為第二階段，流動效率高，一些敏捷專家稱這種效率為“超生產(chǎn)力”。在時間軸上剩下的20%的時間里，流動效率降低。筆者2003年出版的《軟件工程的敏捷管理（Agile Management for Software Engineering）》一書中首次闡述了該模型。雖然這里描述的概率預(yù)測方法早于看板方法，但在看板系統(tǒng)的使用過程中，前置時間的穩(wěn)定性得以不斷提升，從而提高了預(yù)測的精準(zhǔn)度。

軟件看板之父David Anderson：使用看板方法進(jìn)行項目管理

圖3 三階段項目進(jìn)度預(yù)測

圖3假設(shè)項目中的需求是同質(zhì)需求。換句話說，這些需求屬于相同類型，具有相同的風(fēng)險級別。具體什么意思呢？如果多種需求都通過同樣的方式（如用戶故事）獲取，則這些需求可視為同質(zhì)需求如果一些需求依賴于供應(yīng)商，而其他的沒有，那么前置時間分布中會有多個模態(tài)的數(shù)據(jù)，因為供應(yīng)商依賴將會導(dǎo)致某種延遲，從而影響交付時間。在這種情況下就不應(yīng)對所有需求一視同仁，而要對需求是否具有供應(yīng)商依賴進(jìn)行區(qū)分。所以，我們要從有無供應(yīng)商依賴的角度，對需求進(jìn)行標(biāo)記。如此一來，需求就不再同質(zhì)，而是分為兩種不同的類別，需要分別進(jìn)行估算。

使用產(chǎn)能分配管理需求風(fēng)險

我們會按照類型將需求劃分為多個批次，并針對各個批次構(gòu)建模擬仿真。例如，對于如本系列文章第二部分中所描述的調(diào)控性需求，我們將其與項目中非調(diào)控性需求分開預(yù)測。正如第二部分所討論的，調(diào)控性需求一般具有固定的交付日期，并且項目交付日期通常具有法規(guī)效力。一批調(diào)控性需求需要在項目結(jié)束前交付，如此一來，我們可以在看板系統(tǒng)中引入產(chǎn)能分配，在整個項目的生命周期中以穩(wěn)定的速度拉動調(diào)控性需求。

知道了調(diào)控性需求的規(guī)模、交付日期和當(dāng)前的日期，我們就可以計算出需求平均交付速度。通過看板系統(tǒng)可以得出拉動調(diào)控性需求的前置時間分布。有了這些參數(shù)，就可以計算出調(diào)控性需求的在制品（WIP）限制數(shù)量。這將成為在整個看板系統(tǒng)中的產(chǎn)能分配。我們在可視化看板上設(shè)計一個泳道或者使用不同顏色的卡片用來標(biāo)記調(diào)控性需求。至此，我們已卓有成效地建立了看板子系統(tǒng)，用以按照需要的節(jié)奏來拉動調(diào)試性需求。從現(xiàn)在開始，可以確保所有的調(diào)控性需求在交付項目的截止日期之前完成。

是否應(yīng)該對法規(guī)變更（Regulatory Changes）需求進(jìn)行排序？由第二部分討論可知，這取決于某些這類需求是否仍可能發(fā)生變化——原因可能包括游說、管理者決策多變或者是政治領(lǐng)導(dǎo)層的變化。如果需求沒有變化，則從業(yè)務(wù)風(fēng)險角度來看，調(diào)控性需求是同質(zhì)的，可以按自己喜歡的順序進(jìn)行拉動，而不需要對它們進(jìn)行排序。如果部分調(diào)控性需求仍然有可能改變，則這些需求應(yīng)該推遲到項目的后期。在項目開始和早期階段，應(yīng)該對需求進(jìn)行排序，并且選擇那些已知的比較穩(wěn)定的調(diào)控性需求，而推遲不穩(wěn)定的需求，直到所有不確定因素被消除。

總結(jié)

盡管使用歷史數(shù)據(jù)構(gòu)建前置時間直方圖、繪制最合適的分布曲線、預(yù)測項目完成進(jìn)度、建立WIP數(shù)量限制、構(gòu)造產(chǎn)能分配并將分配策略付諸實踐聽起來都比較復(fù)雜，而且需要對統(tǒng)計學(xué)有基本的了解，但這樣進(jìn)行項目計劃實際上卻非常高效、簡便。由于已對需求進(jìn)行評估并就風(fēng)險類別進(jìn)行了標(biāo)記，數(shù)小時之內(nèi)便可建立項目預(yù)測模型。即便對于周期超過1年、成本超過1000萬美元的重大項目，幾個人花上不到一天的時間對必要的數(shù)據(jù)進(jìn)行收集和分析，就能構(gòu)建出可靠、高質(zhì)的預(yù)測模型。

傳統(tǒng)的決定性的計劃方式中，需要對項目中的工作項逐一評估。相比之下，用本文所介紹的方式做出的概率預(yù)測，通常要準(zhǔn)確得多（與實際結(jié)果更加接近），同時構(gòu)建起來也快得多，成本也大幅減少。概率預(yù)測的一大好處是，不需要讓專注于客戶所關(guān)心的工作的員工停下來，對未來的（經(jīng)常是帶推斷意味的）工作進(jìn)行估算。打斷工作是對資源的浪費。許多看板案例研究都顯示，消除這種打擾之后，項目的交付速度、前置時間、可預(yù)測性和質(zhì)量等方面都有大幅改觀。

本文介紹了具有三個階段的預(yù)測模型（所謂“Z型曲線”模型）。如果使用LeanKit或者Swift Kanban產(chǎn)品，還可借助蒙特卡羅模擬功能，對項目的結(jié)果做出更加靠譜的預(yù)測。預(yù)測效率更高、成本更低，結(jié)果通常也較傳統(tǒng)的估算、計劃方法準(zhǔn)確得多?？窗逑到y(tǒng)讓預(yù)測能更廣泛地用于項目風(fēng)險管理，同時也讓進(jìn)度管理和產(chǎn)能分配相關(guān)的策略更加清晰，從而確保能較好地把控項目。

四、風(fēng)險審查與阻礙集群

本部分闡述了項目經(jīng)理如何促進(jìn)風(fēng)險管理并對平均前置時間與前置時間分布進(jìn)行控制。其重要之處在于確保在第3部分中所描述的預(yù)測在整個項目周期內(nèi)是準(zhǔn)確、可信的。以及描述的阻塞項歸類技術(shù)最早由Klaus Leopold提出，不僅可以用于管理項目風(fēng)險，還可用于促進(jìn)過程改進(jìn)。

歸類阻塞項(Blockering Clustering)

上圖中的例子是某次阻塞項歸類實踐的輸出。其中這些便簽在使用看板過程中收集到的一個月內(nèi)的阻塞項。每個便簽都記錄了阻塞原因和阻塞天數(shù)。本例中，我們把阻塞歸為外部阻塞和內(nèi)部阻塞，然后再根據(jù)根因做進(jìn)一步歸類。

事件風(fēng)險分析

風(fēng)險 = 可能性 × 影響

上面這個計算公式大家一定很熟悉，它屬于經(jīng)典的項目管理知識。目的是計算給定的風(fēng)險事件發(fā)生的嚴(yán)重性。通過對阻塞項加以歸類，我們就能夠得到代入公式所需的信息。如果仔細(xì)查看圖片，你就會發(fā)現(xiàn)，“客戶”（德語為\”kunde\”）這個阻塞歸類影響共130天（德語為\”tage\”），若我們準(zhǔn)確地知道這個歸類的阻塞項總數(shù)（這里貌似有13個便簽），就能推斷出，由于等待客戶響應(yīng)，會造成平均每個為此而阻塞的工作所受到的阻塞影響為10天。因此我們就可以知道，風(fēng)險（顧客拖延）平均對每個阻塞項的影響為10天。如果在這段時間內(nèi)，所有我們處理的便簽共有65張，則由于某客戶而導(dǎo)致某便簽被阻塞的可能性為13除以65，即1/5或20%。

客戶拖延的風(fēng)險 = 20% × 10天

因此，阻塞項歸并實踐使用直接從看板墻上收集到的便簽，便可以直接得到項目的風(fēng)險計劃。

風(fēng)險審查會議

看板方法第5個主要實踐是“實現(xiàn)反饋循環(huán)”。目前只有三種具體實踐：每日站會、服務(wù)交付評審會議和運營回顧會議。在精益看板《現(xiàn)代管理框架中》，我們增加了第四個具體的反饋循環(huán)實踐，即：風(fēng)險審查會議。而阻塞項歸并則是風(fēng)險審查會議中關(guān)鍵的協(xié)作活動之一。

過程改進(jìn)

阻塞項歸類的輸出不僅可以預(yù)示出項目風(fēng)險計劃，還可以用來促進(jìn)過程改進(jìn)。我們可以有針對性地對影響更大的延遲源有針對性地采取風(fēng)險降低和緩解措施，以圖消除延遲源或顯著降低發(fā)生延遲的可能性及影響。從這個角度來說，阻塞項歸類能夠在組織內(nèi)形成某種模型驅(qū)動的改進(jìn)和不斷改進(jìn)服務(wù)交付的進(jìn)化過程。

軟件看板之父David Anderson：使用看板方法進(jìn)行項目管理 作者介紹：David Anderson，軟件看板之父，管理咨詢公司 DJAA 的 CEO，國際看板認(rèn)證機(jī)構(gòu) Lean Kanban University 的核心創(chuàng)始人。擁有近30年的軟件開發(fā)行業(yè)經(jīng)驗，曾在Sprint、摩托羅拉、微軟、Corbis等公司從事軟件開發(fā)管理工作，倡導(dǎo)以敏捷方法進(jìn)行項目開發(fā)。2005年，他將Kanban方法引入軟件開發(fā)流程并取得顯著成效，之后，他將精益與敏捷思想與實踐更深入地應(yīng)用于IT交付、技術(shù)創(chuàng)新、產(chǎn)品運營等領(lǐng)域，在深層次催化組織的漸進(jìn)式變革。曾任全球精益Kanban大會的主席，經(jīng)常應(yīng)邀在知名的國際會議上演講。著作包括：《Lessons in Agile Management》、《Kanban》、《Agile Management for Software Engineering》等書籍。