以流動債務為例論指標的合理使用

\

關鍵點

\\

• 流動債務是改進軟體開發過程的一個重要指標\\t
• Cynefin框架可以像鏡頭一樣，在不同情境下使用不同的指標\\t
• 我們應該在適當的情境下用上所有指標\\t
• 可預測性意味著減少可變性\\t
• 有些情況下減少可變性是好的，有些情況則相反\

\\

目前軟體開發的一個重大問題是，在需要把軟體開發考慮成建立一個基於服務的生態時，卻偏偏把它假定為生產一個產品。

\\

軟體開發過程和工廠裡的生產線之間的關鍵區別在於，每一個工作專案都解決了一個不同的問題，使之有別於其它的工作專案。軟體開發是在構建獨特的東西。這種獨特性正是一般客戶認為的價值所在。

\\

然而，我們看到生產製造的模式被應用到一個軟體開發這樣的非製造過程中了。在精益生產中已經體現了我們需要消除過程中的可變性的想法。不幸的是，這種想法蔓延到了敏捷軟體開發中。我們看到人們在為生產週期（Lead Time，從訂貨到交貨的時間）構建統計過程控制圖，以跟進開發過程是否處於控制之下。他們的想法就是：只要我們可以消除變化，工作就可以順利推進，我們所有的問題就都將得到解決。

\\

可變性是新產品開發過程的天然夥伴。杜絕了可變性就會杜絕創新。我們必須瞭解產生可變性的具體條件，並管理我們的過程來創造這些條件。我們需要在可變性存在的前提下讓開發過程也可以多樣化發展。

\\

指標應當在恰當的情況下使用。測量一個複雜的軟體開發過程時首先假定它是有序的，那這從根本上就已經錯了。

\\

讓我們選擇流動債務指標作為一個例子來說明指標是怎麼被非正當地使用的，也就是說壓根沒有在它們的適用範圍之內。要達到同樣的效果，我們也可以使用其它指標，如生產週期的散點圖等，但流動債務是一個重要的指標，值得廣泛使用。

\\

流動債務是什麼？

\\

流動債務是一個先行指標，它給我們提供了一個檢視，可以看到交付系統內部正在發生著什麼。我們把生產週期定義為“完成時間-開始時間”，那麼如果為了人為地讓處於“進行中”的工作專案數量減少而不得不向其它的進行中的工作專案借用生產週期，那就出現了流動債務。這個詞最早出現在Daniel Vacanti的優秀著作《可操作的預測性敏捷指標：導論》中。

\\

這裡就是一個流動債務的例子。假如說我們只有一個正在進行中的工作專案。如果我們在完成第一個工作專案之前又開始了另一個工作專案，那麼我們將有兩個正在進行中的專案。如果我們在第一個工作專案完成之前完成了第二個工作專案，那麼我們就引入了流動債務。

\\

通常人們引入流動債務的原因有：

\\

• 阻礙物，即阻礙工作流程繼續進行的障礙物。如果我們不想無所事事，那麼當我們目前的工作專案受阻時，我們就會再開始一個新的工作專案。
  \\t受阻狀態和等待狀態之間的區別是什麼？讓我們用我每天上下班的道路情況來做個類比。道路是工作流程。工作專案就是我的車。每一個交通燈都是工作流程的一部分，也是潛在的等待狀態。這樣的等待是預料之中的，我總不能把我遲到了的原因歸結於交通燈變紅了！但如果發生了撞車事故，我的車就會被堵住走不了，這就是阻礙，因為它是意料之外的，它有它特定的原因，解決阻礙也需要做一些工作。在這種情況下，交通警察應該過來幫忙恢復正常的交通流。\\t
• 一般的策略都會支援多種在製品（WIP），即多工。多工意味著同時有多個工作專案一起處於進行中的狀態。在現實中我們會不斷地阻礙和疏通各個工作專案，以便專心處理另一個進行中的工作專案。\\t
• 對拉動策略的隨意使用。一旦決定了將要提交某些工作專案之後，拉動策略決定了將這些工作專案拉入到交付流程中的順序。在Kanban中這樣的策略被稱為服務分類。但在實際專案中，大部分團隊根本不遵循任何拉動策略。他們只是對事件作出反應並暫停某些工作專案，以便為其它“更重要”的工作專案讓開道路。除非他們知道為什麼要使用一個特定的拉動策略，否則他們會堅持先進先出（FIFO）或先來先服務（FIFS）的策略。\\t
• 並行工作。有些工作專案只是與其它專案相比更大（根據隨機分支抽樣的概率專案規模大小定義規模）。雖然我們正在忙於一個大專案，但我們仍然可以並行地完成幾個小的工作專案，並因此產生流動債務。\

如何計算流動債務？

\\

計算一個給定的報告間隔內的流動債務的方法之一是：

\\

\

流動債務=近似平均生產週期（由CFD方法預測）減去已完成專案的實際平均生產週期。

\

\\

通過這種計算方法，正數意味著我們正在積累流動債務，而負數意味著我們正在支付它。然而，當我們使用它時符號就會反過來，顯示流動債務為負。

\\

償還流動債務

\\

如果你的流程中有許多“人為延長”的進行中的工作項，導致它們的生產週期“比正常時間長”，那對流動債務的償還就很難具有可預測性。其結果是，你本以為你會對你的平均生產週期很有信心，可實際上卻一點都沒有。

\\

流動債務是一個可預測性的指標。

\\

可預測性是對未來的狀態做出定量預測的能力。在這裡，我們把範圍縮小一下，專注於估計既定工作專案（功能、專案等）的完成時間。時間預測包括日期範圍和發生概率——比如有85%的概率少於3天。只做預測而不關聯概率，那麼預測就毫無意義。預測的日期範圍越小，可預測性就越大。例如，“生產週期有85%的概率會少於10天”，這個比“生產週期有85%的概率會少於20天”更具備可預測性。

\\

可預測性和速度不一樣。人們可以預見快速，但也可以預見慢。但只有當我們具備可預測性時，我們才可以開始尋找提高我們的交付速度的方法。

\\

在情境中的指標

\\

在我們追求可預測性時，在高度受限、高度受控的環境中是非常有效的。然而，我們不應該在實踐中幾乎沒有秩序的地方卻假設有秩序。在假設有秩序的前提下去衡量一個複雜的軟體開發過程是根本錯誤的。測量標準也應該在情境中考慮。複雜的事務不應該和明顯的事務一起測量。要做到這一點，首先，我們需要知道我們正在處理什麼型別的問題——有序的、複雜的還是混亂的。Cynefin框架可以幫助我們做到這一點。

\\

Cynefin框架是一個意義構建框架。意義建構是人類在多種可能的感官解釋和其它輸入之間選擇的方式，因為他們試圖藉助現實來確認他們的觀點，以便決定或回應他們周圍的世界（參考文獻2）。該框架首先是關於語境意識，其次是與情境相應的適當行動。

\\

正如InfoQ的文章《適用還是可預見？爭取兩者都要：可以預見的適應性！》中詳細說明的那樣，我們建立了兩種情境Cynefin框架：一個提供給客戶，另一個提供給能力（由交付組織的知識、技能和生產能力為代表）情境。

\\

客戶需求的不確定性本質為客戶的情境定義了Cynefin域。我們將只使用三種：

\\

1. 客戶清楚地知道他們需要的是什麼。他們已經為這些需求下了定義。（明顯的）\\t
2. 客戶知道他們需要什麼，但不明確。他們需要一些專家來幫忙分析，以確定它。（複雜的）\\t
3. 客戶只是對他們需要什麼有模糊的想法。在最終成為一個定義之前，他們將不得不研究幾個備選方案。（龐雜的）\

對於開發能力是否與客戶需求相匹配的不確定性決定了能力情境的Cynefin域。這一次，我們仍然使用三個例子：

\\

1. 組織有完成這項工作所需要的所有知識和技能。（明顯的）\\t
2. 組織有完成這項工作所需要的部分知識和技能。我們將研究和分析其餘的知識和技能，因為會有人在某個地方已經做過了，可供我們借鑑。（複雜的）\\t
3. 組織完全不具備完成這項工作所需要的知識和技能。我們在此之前沒做過這樣的工作，我們需要研究各種可能性並學習知識。（龐雜的）\

我們通過由域索引的每個Cynefin框架將客戶的需求進行匹配。由此產生的能力-客戶矩陣代表了我們將要交付的工作專案的不確定性。

\\

\\

如果某個需求屬於一個龐雜域，它會被認為是高度不確定的。如果一個需求屬於一個複雜域，它會被認為是中等不確定的。低不確定性在這兩個框架中都屬於明顯的需求。

\\\

\\

對流動債務的合理使用

\\

讓我們看看一個不錯的例子，即資訊科技運營團隊對流動債務在合適的情境下的使用。他們提供與內部員工和合同工的使用者生命週期有關的身份識別和訪問管理服務。

\\

我們用上文中講述的基於Cynefin的方法來對服務請求進行分類。

\\

首先，從客戶的角度情境化——當客戶提出服務需求的時候，他們知道他們真正需要的是什麼嗎？事實上，在大多數情況下，他們知道他們的需求。他們需要我們提供給他們訪問不同的應用的方法。

\\

接下來，從能力的角度情境化——資訊科技運營團隊知道如何滿足服務需求嗎？事實上，他們也知道如何滿足。根據源自團隊知識庫的最佳實踐，我們可以完成明顯的訪問配置請求。複雜的請求是通過利用團隊內部和外部的專業知識來完成的。很少有要求是龐雜的——這些請求都被轉交給另外的專門的團隊。

\\

基於以上的情境化工作，我們可以將服務需求歸類為低等和中等不確定性。

\\

正如之前提過的InfoQ關於可預測的適應性的文章中羅列的那樣，明顯的問題已經有基於最佳實踐的解決方案了。複雜的問題有可預測的解決方案，但需要專業知識來理解，因此有多種好的實踐做法。這樣，歸類為低等和中等的不確定性的工作專案可以在一定的預期下交付。

\\

流動債務是可預測性的一個指標。我們可以在資訊科技運營團隊的背景下使用它，檢查它們是否是可預見的。

\\

他們的交付率可以用下面的累積流圖（Cumulative Flow Diagram ，CFD）以圖形化的方式展示出來。

\\

\\

X軸是報告週期內的日期。Y軸顯示在交付過程中的不同狀態的工作專案的累積值。工作流用這種方式表示：已經開始的工作的累積數量（橙色帶的頂部）和已提交的累計數量（藍色帶的頂部）。為了便於理解，累積流圖沒有顯示未啟動的專案，只有已經開始和已經交付的工作專案。藍色帶越陡峭，每天交付的工作專案越多。

\\

但是隻從累積流圖中，我們看不出工作流是否會比“正常”的預期花費更多時間。

\\

下面的流動債務圖則提供了累積流圖不能提供的內部資訊。時間是在幾個星期內。

\\

\\

圖表上的紅條顯示了流動債務的發生時間，綠條顯示了流動債務的償還時間。我們看到這個團隊大部分時間都有流動債務。效果在下方的生產週期散點圖中可見。

\\

\\

X軸表示由我們的資料得出的基礎過程的時間軸。Y軸仍然表示的是我們以天為單位的生產週期。

\\

在報告期內，為每一個完成了的工作專案繪製一個點，就產生了散點圖。我們通過尋找工作專案完成的日期，並根據它的生產週期的長度在圖表上繪製一個點。如果有幾個工作專案在同一天完成，並且有相同的生產週期，那麼我們就簡單地從上到下繪製幾個點，把它們疊起來。

\\

通過這樣的方法，我們可以推斷出他們的生產週期是不可預測的。事實上，他們的客戶已經提供了反饋，客戶們的訪問配置已經被延遲了，因此還損失了業務的生產力，提高了成本。客戶對團隊提供的服務非常不滿，感到生氣和沮喪。

\\

流動債務的不正當使用

\\

現在，讓我們來研究一個案例。在這個案例中，錯誤地使用流動債務作為管理決策的基礎，這種的情況可能會產生誤導，甚至造成破壞。在2011年時，有一個提供虛擬招聘的專案——一個聊天機器人，類似於今天的美國陸軍\"中士的明星\"，能夠在Facebook的聊天工具中回答問題，比如“MA，你在波士頓有什麼java工作嗎？”功能上，也可以實現申請工作、安排面試、支援多種語言等。

\\

使用和上面的資訊科技運營團隊例子中的同樣方法，讓我們對專案的需求進行分類。

\\

首先，將從客戶的角度情境化——當你的客戶要求在Facebook上實現虛擬招聘機器人的時候，他們真的知道他們要的到底是什麼嗎？不，他們並不知道。他們對他們的需求只有一個模糊的想法——因此，這是一個龐雜領域的問題。

\\

接下來，將從開發能力的角度情境化——開發團隊知道如何在Facebook上開發虛擬招聘機器人嗎？不，他們並不知道。在那個時候，已經有了各種為不同目的而開發的聊天機器人，但在Facebook上並沒有虛擬招聘機器人。同樣，那時候也還沒有實踐過的開發聊天機器人方式，只有許多相互競爭的技術和架構。團隊必須選擇一種技術並設計架構。這種工作肯定屬於龐雜領域。

\\

基於以上的情境化結果，我們可以將大多數的專案工作內容納入高不確定性的類別中。我們特別要注意，不是所有的工作專案——也就是說是專案範圍內的一部分內容——都是高不確定性的。它們當中的許多項都是中等的不確定性，但專案的主體確實是高不確定性的。

\\

軟體開發的基本工作就是將一個高不確定性問題從複雜的轉變成有序的，並且用一種讓它具有可預測性的方式維護它。

\\

這就是為什麼我們首先安排高不確定性的工作專案的原因所在。因為我們需要探索解決方案，而且它們可能有很高的概率會對時間安排產生負面影響。但同時，還有很高的概率就是我們可以非常幸運地早於預期時間完成這樣的工作專案。我們可以同時採用大量的、一致的、失敗的代價可以承受的、細粒度的並行實驗，這些將提供反饋讓我們知道哪些是可行的，哪些不可行。我們將實驗作為一個組合來進行管理。

\\

我們在高不確定性的工作專案結束之後再做低等和中等不確定性的專案。如果不這樣做，將意味著我們在試圖隱藏不確定性。

\\

下面的累積流圖說明了上述內容。還是用相同的方法，工作流程由累計的到達數量（紅色帶的頂部，正如我們看到的那樣，它非常小）和累積的交付數量（藍色帶的頂部）來表示。

\\

\\

交付率為S型或Z型曲線的樣子。我們可以看到，最初的交付率很低。這是因為專案剛開始時團隊需要首先解決高不確定性的需求，例如通過進行實驗來選擇要使用的技術和實現的系統架構。這些實驗和與它們相關的作決定過程需要耗費大量的時間。在九月中旬，團隊成功地將核心問題推進到了複雜的領域內，交付率開始急劇上升。

\\

讓我們想象一下，假如專案發起人讀過Daniel Vacanti的好書《可操作的預測性敏捷指標：導論》。在這本書的啟發下，他們決定使用流動債務作為一項指標，看看團隊的工作是否具備可預測性，並且最終確保管理方式可以保證該專案的內容被以可預見的方式交付。

\\

如果他們在9月1日建立了圖表，他們會看到下圖的內容。

\\

\\

他們會感到震驚，因為流動債務圖顯示，前三個月實際平均生產週期比“正常”的平均生產週期多差不多四個星期！照這樣進行下去的話，贊助商甚至可能會考慮取消該專案，因為它看起來已經完全失控！

\\

當然，他們搞錯了，因為他們在完全不瞭解背景的情況下，就直接使用了流動債務這樣的指標。我們現在明白了，如果在不合適的情況下直接使用流動債務去判斷專案的進展將是有誤導性、甚至破壞性的！

\\

因為我們瞭解背景我們才會知道，這樣的流動債務水平是符合預期的，因為首先被安排的是高不確定性的工作專案，並且作為一種平行地試探性組合在進行。並行式進行的東西從概念上來說就會產生流動債務。正如我們通過Cynefin框架看到的我們的管理辦法，在專案的開始階段，就肯定會產生大量的流動債務！

\\

累積流圖表明，交付率在九月發生了變化。事實上，正如我們在下面的圖中看到，9月6日開始流動債務已經被償還，團隊已經完成了探索並切換到研發階段，即他們的注意力已經開始集中到中等和低等不確定性的工作專案中了。

\\

\\

之後我們看到，在做中等和低等不確定性工作專案的時候，團隊管理的流動債務水平和預期一樣。

\\

這個專案確實講述了一個故事，並且這個故事是一個將巨大的前期不確定性轉變成可預測的表現的故事，是一個可預見的適應性的完美例子！

\\

結論

\\

文章的主旨是講述如何將複雜性理論，尤其是Cynefin框架，應用到程式的軟體開發過程中。

\\

通過Cynefin，我們以流動債務作為流動指標的例子，知道了該如何正確地使用指標。

\\

引用文獻

\\

1. Vacanti, Daniel S.：《可操作的預測性敏捷指標：導論》，Daniel S. Vacanti公司 (2015)\\t
2. D.J. Snowden, Multi-ontology sense making: a new simplicity in decision making Informatics in Primary Care, 13 (1) (2005), pp. 45–54\

作者簡介

\\

Dimitar Bakardzhiev是一個在有限支出的情況下成功地管理開發過程的專家。作為一個精益-Kanban大學（LKU）認可的Kanban教練（AKT）、狂熱並專業的Kanban實踐者和2015年度Brickell Key獎入圍者，在管理複雜的軟體專案過程中，Dimitar將精益原則融入每日的工作中。可以通過LinkedIn或Twitter（@dimiterbak）聯絡他。

\\\\

閱讀英文原文：Proper Usage of Metrics with Flow Debt as an Example