將看板應用於軟體開發：從敏捷到精益

將看板應用於軟體開發：從敏捷到精益

2009-12-23

在敏捷軟體開發中，專案的視覺化（例如在牆壁上放置任務卡片就是常見的實踐）往往被叫做“軟體看板”，或者“任務看板”。我們甚至可以看到一些產品維護團隊在類似瀑布過程模型中使用看板系統。那麼，看板到底是什麼呢？為什麼它會被用於軟體開發環境之中呢？

摘要
看板1是豐田生產方式（Toyota Production System，TPS）中用來支援非集中“拉動式”生產控制（non-centralized "pull" production control）而使用的卡片。作為精益生產的工具，它現在已經應用於世界各地的製造企業之中。如今在敏捷軟體開發中，專案的視覺化（例如在牆壁上放置任務卡片就是常見的實踐）往往被叫做“軟體看板”，或者“任務看板”。我們甚至可以看到一些產品維護團隊在類似瀑布過程模型中使用看板系統。那麼，看板到底是什麼呢？為什麼它會被用於軟體開發環境之中呢？

在本文中，我首先解釋一下在精益生產中，尤其是TPS中的看板是什麼樣子的，來理解下這個成熟行業中的實踐和法則，並圈定可以應用於軟體開發的概念。其次，我將環顧我們的軟體開發專案並指出看板應用的例子。然後，我會分析生產環境中的看板系統與軟體開發中的看板系統有何異同，並嘗試提出觀點來有效地在軟體開發中應用看板系統，其中還介紹了新近在kanbandev2討論列表中萌芽的“KSSE——持續工程的看板系統（Kanban System for Sustaining Engineering）”運動。最後，我給出TPS的一個全景檢視，也就是看板這種工具的原始背景，軟體開發仍可從中有所借鑑。

 

TPS中的看板
在“拉動式”生產系統中，看板是指示移動或者製造零部件的訊號裝置（通常是放在透明塑膠封套中的卡片），它是在豐田生產系統（TPS）中發明和發展起來的。在介紹軟體開發中的看板之前，我來詳細的介紹下看板最初的用法，也就是TPS中的看板。
看板的目的是透過確保只有當下遊工序需要時上游工序才生產零部件，進而最大限度地減少工序（process）之間的在製品（Work-In-Process，WIP）或者庫存。“拉動式”是指下游工人從他們的上游工序中領取或者“拉”出所需要的零部件。

圖1 看板和拉動式生產

圖1是看板系統的抽象模型。圖中以兩個工序，上游工序和下游工序為例，其中上游工序為下游工序供應零部件。為了給終端使用者提供產品，這一工序需要生產零部件並將其流向下游，但是不能生產太多，因為生產過剩被認為是最糟糕的浪費。為了避免生產過剩，上游工序不是將成品零部件“推”給下游工序，反而是下游工序主動地從上游工序中拉出（拿）零部件。零部件存放的地方叫做“倉庫”（或者“超市3”——Taiichi Ohno首次提出看板的思想，是在他參觀了某個美國超市之後，在那裡不是由商店售貨員而是由顧客自己去獲取他們想要的東西）。倉庫位於上游工序，作為在製品的“緩衝區”或者“佇列”。當一名來自下游工序的工人——叫做“物料管理員”——來到倉庫並拿到新近完成的零部件，同時他也反饋一個生產訊號——也就是，下游從上游中獲取東西並在同時透過看板卡將資訊推給上游。這是必須的，因為沒有來自下游工序的訊號上游工序決不會生產零部件。

 

那麼在圖1中有兩種型別的看板一同工作：
領取看板（Withdraw Kanban）——是由物料管理員遞交給倉庫的購物清單。
生產看板（Production Kanban）——指示上游工序為其下游工序生產零部件。
如圖1所示，領取看板迴圈於兩道工序之間，而生產看板迴圈於工序內部，並且兩者在倉庫內發生交換。讓我們稍微仔細的瞭解下這個交換細節。圖2顯示了在倉庫中是如何進行“看板交換”。

圖2 倉庫中的看板交換

位於下游的物料管理員收到領取零部件的訊號。此訊號由下游工序定義，為下面兩種情況之一：
（a） 由收集到的領取看板的數量觸發訊號
（b） 由定時時間間隔觸發訊號

物料管理員帶著空托盤（pallet）和收集到的領取看板訪問上游倉庫，並將他收集的領取看板當作購物清單——其中標明瞭下游工序需要什麼，需要多少。
由上游工序完成的零部件用托盤裝著，並附上生產看板放入倉庫。（這些發生在一個單獨的執行緒中，和（1）是獨立的。）
物料管理員拿取領取看板（購物清單）中指定的零部件，檢查是否與附在零部件上的生產看板相匹配，然後交換兩個看板。
他將生產看板放入“生產板（Production Board）”中——稍後當看板累計到一定的閥值時，它將直觀地觸發上游生產。
物料管理員將所需的零部件附帶著領取看板一同從倉庫搬運至下游車間。
你可以看到倉庫是由一個單獨的執行緒控制的、位於兩個工序之間的佇列（queue），它透過看板來交換物品和資訊。看板卡上面寫明瞭像零部件號碼、名稱、數量、托盤型別、倉庫位置這樣的資訊，這樣物料管理員拿到卡片就知道去做什麼了。

 

對於看板的運轉有著嚴格的規定——被稱作“看板六準則”：
客戶（下游）工序精確按照看板上指示的數量領取產品。
供應者（上游）精確按照看板上指定的數量和順序生產產品。
沒有任何產品在看板之外製造或者流動。
每件產品每時每刻都要與看板相伴。
質量殘次和數量有誤的產品決不能發往下游工序。
謹慎地減少看板的數量來降低庫存並揭露問題。

正如我們所瞭解到的，倉庫用作零部件的佇列，托盤用作零部件的載體，而看板卡用作客戶之所需的資訊載體。透過維持“連續流通（continuous flow）”（消除等待帶來的浪費）和“最小化在製品（minizing WIP）”（消除生產過剩帶來的浪費）之間的平衡，它們共同形成了“拉動式”系統。在超市中也是用同樣的機制來把從採購到銷售之間的流程中的在製品維持在“適當”數量，做好這一步是提高商店盈利率的關鍵。

 

目前為止，我已經講述了看板是如何在製造業中工作的。注意以上是對真實看板系統的簡化模型。這裡沒有明確提及的另一件事是看板形象地向每一個工人展示了資訊和產品的流程，並激勵在現場5（Gemba，指工作場所）的改善4（Kaizen，指工序改進）。改善源於對現場中發生事件的關注。透過看板，每個工人（不是管理人員）都可以看到生產流程，進而有機會發現其中的浪費，並建議改進他們所在的工序。

看板的特性
根據前一節的詳細介紹，這裡列出了從TPS最初的看板概念中總結的特性和作用。
實體的：看板是實體的卡片。可以拿在手中，可以移動，可以放在某些東西上面或者裡面。
限制在製品數量：看板限制在製品的數量，也就是防止生產過剩。
連續流通：它會在倉庫耗盡庫存之前通知生產的需求。
拉動式：下游工序從上游工序中抽取零部件。
自導向（Self-Directing）：它有要完成的工作的所有資訊，能以一種非集中的方式實行生產自治，並且不需要微管理（micro-management）。
視覺化：堆放或者張貼著的看板直觀地展示了當前的狀態和進度。
訊號：看板的視覺化狀態為下一步的領取操作或者生產操作作出指示。
改善（Kaizen）：視覺化的流程觸發並刺激改善。
附著的（Attached）：看板附在所供給的零部件之上並隨其一同移動。
圖3為以上9個特性之間的相互影響，它顯示瞭如何將這些組成一個因果效應網路。你從中可以看到看板的兩種含義，一是“在維持連續流通的同時限制在製品數量”，而另一種是“改善”。

圖3 看板的特性和作用

圖表右側說明了如何在維持連續流通的同時，最大限度地減少在製品。如果倉庫中的在製品太少的話，下游工序不得不等待所需的零部件準備就緒，但是在製品還應該保證最小化以防止生產過剩。這樣看來這兩個目標是相矛盾的，而看板正被看作是解決這個難題的策略。
看板附著於零部件，並且可以被收集和重用，因此看板的數量是固定的。而且看板還可以直觀地指示下游工序僅當需要時才獲取零部件。這裡有兩種限定在製品數量的機制。

 

第一個機制“附著的看板”工作機制同“能量守恆定律”類似。一旦根據產品市場銷售的速度和當前工序的內在變化規律確定了看板的數量，那麼不管零部件的流入和流出如何，在製品的數量都被限制為看板數量的一定比例。在任何時候，看板（相當於系統中的“能量”）的最大數量都與在製品的上限保持守恆。在圖4中，你可以看到“系統”指的是上游工序和下游工序之間的庫存，也就是“倉庫”中的在製品。

圖4 限定在製品數量的看板機制

第二個機制——“拉動式”——透過依據下游消耗速度來確定上游工序的生產速度，這種機制也限制了在製品的數量。第一個機制僅僅涉及到在製品的數量，而第二個則涉及到流程——流程的方向和速度。
“方向”——僅由下游工序來驅動生產。
“速度”——透過看板傳達下次生產的時機和數量。
透過確保上游工序的生產以下游工序首次衍生訂單中的消耗為依據，“拉動式”限制了在製品的數量。透過在倉庫中交換看板，將生產控制資訊從下游推到上游，這種依賴性便得以實現。

回到圖3：圖表左側說明了如何促使工作自導向並促進改善。透過檢視張貼在皮膚上的看板卡，每個人都可以瞭解到發生了什麼事，以及工序運轉的健康狀態。改善起始於對現場（Gemba）工作流的觀測。放置於皮膚之上的看板卡直觀地幫助工作在沒有中央控制管理之下自導向。為了支援改善，這種自治的工序向外提供其效能資料，並將管理重點從對具體工作的指派或者排程上轉移到改善活動。

圖3中的箭頭最終都指向了三個結果，如其所示，看板的終極目標可以表示為“限制在製品數量”、“連續流通”和“改善”。看板系統在維持“連續流通”的同時“限制在製品數量”。它緩衝由普通變因引起的變化情況，並暴露特殊變因引起的變化情況，以備改善。

 

軟體開發中的看板
現在，讓我們將視線回到我們自己的工作領域——軟體開發。在敏捷軟體開發中，透過在專案工作場所的牆上張貼卡片來呈現和分享專案狀態已經成為一種常見的實踐。我已經在我的上一篇InfoQ文章《用“看板圖”實現敏捷專案的視覺化》[Hiranabe07]給出了很多例子。特別是，貼在牆上用來展示當前專案狀態的任務卡片有時也被稱作“任務看板”或者“軟體看板”[Poppendieck03]。圖5是Change Vision公司的JUDE6開發團隊所用的任務看板。

圖5 敏捷看板

在皮膚上，工程任務用卡片（即時貼）來代表，並透過把卡片貼在在皮膚中的不同區域來象徵任務的狀態，這些區域被標註為“ToDo”、“Doing”和“Done”（標註的名稱可能因地而異，比如“進行中（In Progress）”、“已測試（Tested）”、“已驗收（Accepted）”、“停滯中（Blocking）”等等。）。這樣的看板皮膚有利於視覺化地通知任務並限制在製品（處理中的任務）數量。不過在這裡並沒有出現“工序”（上游或者下游），新出現的概念是“迭代”。對於每一次迭代，透過分解使用者故事識別出任務，並且將其張貼在皮膚的ToDo區域中。

這是一個拉動式系統嗎？在製造業中，零部件由上游工序傳遞至下游工序。而在圖5所示的敏捷開發中，並沒有看到“移交物”。一個看板卡片對應一個任務，上面寫明瞭如下資訊：任務編號、任務名稱、估計時間以及任務領取人的名字。任務有狀態，可以是“ToDo”、“Doing”或者“Done”，狀態資訊被分享給整個團隊。敏捷開發重視在一起工作，並趨向於減少團隊內部的移交物。我稱此為“敏捷看板”。

圖6是另一個看板皮膚例項，由Yamaha Motor Solution有限公司所採用。

圖6 持續看板（Sustaining Kanban）

在這裡，看板系統被用於帶有流程的傳統瀑布開發模型。專案被分解成“設計”、“開發”、“驗證”等連續的工序，而看板卡就在這些工序之間移動。每張卡片代表需要修改或者新增的系統需求，也代表給下游工序的移交物。注意這不是一個標準的瀑布流程——標準瀑布流程中所有的需求在同一時間內完成“設計”，而“開發”和“驗證”則在另一時間，這將使得所有的卡片作為一個整體進行移動。與標準的瀑布流程不同的是，這個專案中的卡片是一個接一個地移動，就像製造業中的單件流（one-piece-flow）一樣。這裡表現的是產品生命週期裡穩定的“持續（sustaining）”階段，處在帶有流程的瀑布狀態轉換模型的管理之下。在這裡，你可以清楚地看到“工作流程”的概念，而不同於敏捷中的“迭代”概念。它比敏捷看板看起來更像工廠中的看板，而且透過制定規則只允許下游工序移動卡片8，可以使其成為拉動式系統。我稱其為“持續看板”，這與稍後章節中討論的David Anderson的“持續工程的看板系統”是類似的。

圖7顯示的是另外一個例子——在整個產品開發流程的價值流中使用看板的思想實驗（thought experiment）[Poppendieck 07]。

 

圖7 精益+敏捷看板

假設在一個產品開發流中有客戶團隊、產品所有人、開發團隊和QA團隊，他們使用佇列傳遞移交物來協調工作，以使得團隊之間能非同步工作，並維持工作速度。每一個“DONE”空間是一個佇列，其工作方式就像製造工廠中的“倉庫”那樣，並且看起來非常像TPS看板系統。同時，它看起來就像每條工序內同步地使用敏捷看板，而在貫穿各個工序的整個價值流上非同步地使用持續看板。我認為看板系統可以擴充套件至覆蓋整個價值流，在這種情況下，它是價值流的一個活生生的視覺表現。

在這裡例子中，透過設定每一個區域的大小可以限制在製品的數量。而為了使其變成拉動式系統，還需要一種機制來使下游工序以某種訊號通知上游工序開始工作。其中一種方法是制定一個規則只允許下游移動DONE區域中的卡片來通知上游。另一種方法是定期召開“迭代會議”，來同步團隊和團隊之間傳遞（通訊）的資訊。這兩種通訊方式可能對應於我們在第一章節中討論的零部件領取的兩種訊號，即領取看板的數量（a）和時間間隔（b）的可視訊號。一次迭代中的一組使用者故事對應於迭代中托盤裡的零部件，而零部件的數量對應於迭代中的專案“生產率”（昨日天氣[Beck00]）。我叫它為“精益+敏捷看板”，如下一個例子展示的那樣它可以與“敏捷看板”相結合。

 

圖8中是一個小型的“行動式”看板系統，這是我在CENTRAL COMPUTER SERVICES有限公司的某個專案裡發現的。在這個專案中，團隊被分為了幾個小型子團隊（通常是一對人）。整個團隊有一個與圖7概念相似的工作流，還有圖8所示的小型敏捷看板皮膚（ToDo、Doing、DONE）。當一個子團隊選取了一個使用者故事，他們將其分解到任務並張貼在行動式看板皮膚上。在這種情況下，看板系統由兩個層面組成，在專案層面一張卡片代表一個使用者故事，而在團隊（或者結對）層面一張卡片代表一個任務。

 

他們很喜歡這個行動式小型看板系統，並命名為“看板nano”。

圖8 行動式敏捷看板（“看板nano”）

如你所見，將看板的概念應用於軟體開發有許多方式。“敏捷看板”用來在團隊中分享資訊並使工作自導向，但它不支援流程。“持續看板”是另一種型別的看板，能夠讓小批次的維護工作在幾個狀態之間流轉。這種結合便是“精益+敏捷看板”，使用“持續看板”貫穿價值流，同時在子流（sub-stream）中使用“敏捷看板”。

注意，圖5中的“敏捷看板”（在當今敏捷專案中隨處可見）僅僅可以看到價值流中的一個子流。當你考慮從客戶到客戶的完整價值流，經常由處於同一流中的某個團隊遞交給你需求，而另一個團隊則交付你的工作結果給客戶。這篇文章的目的之一，就是要設法讓看板的應用超越“敏捷看板”，擴大看板在價值流中的應用範圍。

 

生產與開發

軟體開發是不同於生產活動或者製造活動的。軟體工程師每次創造的產物都是不同的，而製造業總是週而復始的生產相同的東西。所以直接將兩者等同起來是危險的。可是，讓我們研究一下如何在軟體開發看板中找到TPS看板中的特性。表1顯示了我們在章節1中總結的看板特性在我們已經提及的兩種軟體看板中是否仍然有效。

圖5所示的敏捷看板例子本身並沒有實現“限制在製品的數量”、“連續流通”和“拉動式”特性。敏捷看板更關注於實現任務、“視覺化”和“自導向”，以便幫助團隊自治並改進其工序。為了使工序連續流通並限制在製品的數量，需要召開“迭代會議”交流資訊。

圖6中的“持續看板”不僅可以限制在製品的數量，還可以以“單件（one-piece）”和“拉動式”的方式控制流程，而不需要召開迭代會議。在這種方法中，它的關注點是“限制在製品的數量”、“連續流通”和“拉動式”，同時允許團隊（或者管理人員）借其改進工序。

回顧一下圖3，我將看板的特性和作用分成圖9所示的兩個關鍵區域，以便上面提到的兩類軟體看板概念的用途各得其所。圖10顯示了生產和開發的頻譜圖。生產是成功機率很高（高於99%）的工序，而開發的成功機率要低。當成功機率在50%左右的時候敏捷是理想的開發方法，而當成功機率超過90%的時候瀑布式則是理想的開發方式（依據Shannon理論，一個具有50%成功機率的專案是最有價值的專案）。通常隨著開發進入到支援維護狀態，修改缺陷和新增新功能的成功機率逐步提高。

看板系統的“工序控制焦點（Process Control Focus）”適合在“高於90%”的成功率下工作，而“工序改進焦點（Process Improvement Focus）”既適合在50%成功率也適合在90%成功率下工作。

值得注意的是，敏捷方法在產品維護狀態（sustaining mode ）下仍能工作良好，同樣看板的“工序改進焦點”特性也在維護狀態下工作良好。

圖9 看板的特性和作用（2）

圖10 使用看板的方法頻譜

 

KSSE——持續工程的看板系統
接下來，我介紹最近出現的一種軟體開發精益應用。Agile2007會議時，我參加了David Anderson主持的關於軟體看板的一個會中會（Conference-Within-A-Conference，CWAC）。他在Corbis.com管理著一個“維護狀態（maintenance mode）”型別的看板系統，並發表了一篇相關論文——持續工程的看板系統[Anderson 07]。他的方法首先關注於看板的“限制在製品數量”特性——就像在圖4所示的抽象圖表那樣——也關注“自導向”特性以使得團隊自組織，減少自上而下的（top-down）管理。然後，透過看板觀察流程，找出整個工序流中的駐點（stagnation point）並調整人力資源，也就是在工序間調動成員。這意味著他的方法，像圖3表現的那樣，涵蓋了看板特性中從“限制在製品數量”、“自導向”到“改善”。

會議之後，Anderson啟動了一個看板開發郵件列表2，這裡已經成為將看板應用於軟體開發的一個新興知識創新討論社群，名為“KSSE”——持續工程的看板系統，讀作Kiss-ee ;-)。Aaron Sanders還著手建立關於看板的知識體系，並已經開始構建KSSE詞彙表。

KSSE對於透過佇列在工序間傳遞移交物、連續相接的多個工序運作良好。請注意KSSE不一定需要納入“迭代”的概念。使用KSSE的方式，我看到了另一種縮放（scaling）敏捷的可能性方式並且好過“scrum of scrums”。[Ladas07]

 

創造價值流
當透過看板從敏捷放大到精益時，一張看板卡應該代表什麼東西呢？

 在敏捷看板系統中，一個卡片是一個從“使用者故事”中分解出來的“任務”。在開發團隊中，它作為工作的一個基本單元執行，因為團隊中每個人都能明白它的意思。但是，在看板系統中它貫穿了價值流中的多個工序（多個團隊），在其中流轉之物應該帶有客戶認可的價值。既然這樣，看板卡片就不是對應於“工作（work）”而是對應於“功能（feature）”，並且它不是WBS（任務分解結構，work breakdown structure）的組成部分，而是FBS（功能分解結構，feature breakdown structure）的組成部分。因此團隊中的每個人，甚至是客戶，都能夠理解看板的含義和流轉之物的價值。Jim Highsmith 在《敏捷專案管理（Agile Project Management）》[Highsmith04]書中所概述的原理也將FBS定位高於WBS。

 

“使用者故事”，“Backlog事項”或者“用例”都被抽象為“MMF”（最小可市場化功能，minimum marketable features），用來明確地宣告流轉之物具有客戶價值。於是精益開發就可以說成“使得MMF快速流過整個價值流。”

圖5中“敏捷看板”的例子是一個工作的分解，它在團隊內部工作良好。圖6中“持續看板”的例子是一個功能的分解並且一張卡片代表一個MMF。圖7中“精益+敏捷看板”的例子與圖8一起展示了上級功能分解和下級工作分解的結合。

 

一旦建立起工作流程，五個“精益思想”[Womack1996]的核心概念就可直接應用於整個工序。精益工序的管理可以簡單地遵循以下原則。
從客戶的角度定義價值——確定和分類MMF
明確價值流並消除浪費——找出駐點（停滯的任務）
在客戶的拉動下創造價值流——制定看板的拉動規則
關注員工並給予一定的權力——授權給在現場的團隊
追求完美的持續改善——反省和改善

TPS全景檢視
以下內容相當於附錄，我在這一部分分享從TPS中學到，並發現可以適用於軟體開發的知識。Mary和Tom Poppendieck已經發現有效的軟體開發方式和精益或者TPS方法有著很多的相同點——不是在實踐層面，而是在原理層面上[Poppendieck03, 07]。讓我們從更高的角度回過頭來再看下TPS中的看板。

讀者很容易假定看板是整個TPS的中心，但其實並不是。圖11展示了TPS的概念結構，有時也叫做“TPS之屋（TPS House）”。它有好幾種版本，圖11是基於Toshiko Narusawa和John Shook的版本[Narusawa06]。在TPS中，看板僅僅是“拉動式系統”實現準時制（Just-In-Time9）的一種方法。準時制可以解釋為“僅在需要的時候生產和交付所需要的東西，並且僅完成需要的數量”。它直接瞄準的是客戶的需要：“儘快以最低的價格提供最高質量的產品。”注意，準時制是TPS的兩大支柱之一，另一個是Jidoka10（譯註：寫作“自動化/自働化”，但其含義與對應於Automation的中文的“自動化”不同，詳見註釋）。製造業中的“Jidoka”即自動停機（Autonomation）與軟體開發中的測試驅動開發類似。Mary和Tom Poppendieck把Jidoka解釋為“停止流水線文化（Stop the Line Culture）”。豐田工廠的工人真正地可以停止流水線而不是把次品推到下一個工序——它不僅是一種規定，也是豐田公司的一種文化，它的萌芽可以追溯到（豐田集團創始人）豐田佐吉時期。

圖11 TPS概念結構

準時制由以下三部分元素構成，“節拍時間（Takt time）”、“連續流通”和“拉動式系統”。

節拍時間基於銷售率制定產品生產率。
連續流通與節拍時間相匹配，無停滯地在工序中生產部件。
拉動式系統在工序之間移動零部件並通知生產，同時限制庫存數量。
也應該注意到兩個支柱依賴於改善和人。豐田一年生產近千萬輛汽車，同時，他們透過在現場（也就是車間）中近1百萬次的改善來完善他們的工序。形象化地表示出團隊正在做些什麼，總是改善的出發點。

 

結論
文中，我分析了看板在製造業的實施，接著列出了看板的特性。看板系統用以達到以下目標：

更優的工序控制——在限制在製品數量的同時保持連續流通
更優的工序改進——使流程視覺化並且激勵改善
“敏捷看板”專注於#2，而“持續看板”專注於#1。我提出將兩者結合，來擴充視覺化和“拉動式系統”到整個價值流，以使得整個生產精益化。

 

感謝
Tom Poppendieck與Mary對本文進行了通篇審校，並給出了許多見解和建議，在此我表示非常感謝。感謝Yamaha Motor Solution有限公司總裁Yasuharu Terai以及Ryuichi Sato允許本文中使用其看板系統的圖片。另外David Anderson也參與了本文的審校工作並且提出了一個更好的看板抽象層次來推進KSSE的發展。KSSE概念最初來源於Kanbandev Yahoo團隊的討論。最後感謝Deborah Hartmann的最後校訂工作，使得我的表達更清晰。

 

關於作者
Kenji HIRANABE是日本Change Vision公司的CEO。他是JUDE（一個整合了ERD、DFD和Mind Map的UML編輯器）和TRICHORD 11（一個整合了Burndown圖表和Parking Lots圖的敏捷專案管理看板系統）的創始人。他還把《Lean Software Development》、《XP Installed》、《Agile Project Management》以及其他XP/Agile書籍翻譯成日文。Kenji把軟體開發看作是一種溝通遊戲，並一直在尋求提高軟體開發的生產效率、合作程度以及樂趣的途徑。