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

以下為翻譯正文：

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

我是項目經理，看板對我來說意味著什么?

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

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

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

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

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

關于規則

所以，我們不再孤立地去談“制訂計劃”與“排列優先級”。我們更希望項目經理以區別于傳統思維的角度去思考問題，同時也強調一些細微差別和更明晰的概念。

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

收益

在項目管理中使用看板方法能夠改進產出物的質量，看板方法提高了項目的可預見性，并改進項目可接受的經濟指標。整個項目進程更加透明。雖然關注重點是在規則的制訂上，但是管理卻得到了改進。項目經理轉變為主抓風險管理，同樣，風險管理也得到了很好的改進。使用看板方法后，項目經理為項目團隊和整個組織，創造了更大的價值。

二、使用排序規則制訂計劃

不排優先級，怎么定計劃？

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

基于風險評估進行項目排期

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

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

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

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

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

創建用于排序和產能分配的策略

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

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

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

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

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

風險是個多維問題

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

基于策略的排期勝于傳統的待辦項排優先級

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

總結

這篇文章，僅僅是給大家一個關于使用看板方法進行項目管理的初步認識，您從中了解到我們如何制訂計劃，對工作項排序與選擇工作項。學習完整的相關技術，您可以考慮參加LKU相關課程。

三、項目預測

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

項目預測的統計學支柱

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

前置時間分布

圖1 前置時間分布

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

其次，要作出準確的預測，需要單一模態的數據。要獲得這樣的數據用于前置時間分布，對于不同種類的工作或不同級別的風險，需要有各自的分布曲線。因此，對需求進行風險評估，根據風險類型對歷史數據進行聚類和過濾，是作出準確預測的關鍵所在。

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

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

圖2 利特爾法則

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

建立進度預測

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

圖3 三階段項目進度預測

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

使用產能分配管理需求風險

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

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

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

總結

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

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

本文介紹了具有三個階段的預測模型（所謂“Z型曲線”模型）。如果使用LeanKit或者Swift Kanban產品，還可借助蒙特卡羅模擬功能，對項目的結果做出更加靠譜的預測。預測效率更高、成本更低，結果通常也較傳統的估算、計劃方法準確得多。看板系統讓預測能更廣泛地用于項目風險管理，同時也讓進度管理和產能分配相關的策略更加清晰，從而確保能較好地把控項目。

四、風險審查與阻礙集群

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

歸類阻塞項(Blockering Clustering)

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

事件風險分析

風險 = 可能性 × 影響

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

客戶拖延的風險 = 20% × 10天

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

風險審查會議

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

過程改進

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

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

（責編/錢曙光）

友情提醒：David Anderson將于2015年12月21-23日來華，坐標深圳，帶來\”項目管理進階\”的課程，為期三天，由David Anderson和軟件工程與管理專家、中國第一位KCP與AKT吳穹博士聯合授課。