klaus leopold在 goto berlin 2015會議上發表了演講。在演講中他闡述了為什麼專注團隊層面的效能往往會導致區域性次優化、並不能在整個團隊層面提高敏捷。infoq對其進行了採訪，主要關於為什麼安裝（install）敏捷框架並不有助於提高敏捷、如何使用 kanban加強協作、和團隊能夠從 kanban中獲得的優勢。
\\infoq：我聽說越來越多的團隊正在使用kanban從而以一種敏捷的方式工作。你能舉例說明你共事過的團隊是如何使用kanban的嗎？
\\
\\\leopold：我在許多不同的領域使用過 kanban。從經典的硬體開發到市場營銷、管理、人力資源部門和機構，幾乎沒有哪個領域是我沒有接觸過的。我知道有的企業使用 kanban管理招聘流程，或者在汽車行業，有的企業用 kanban管理開發流程，或者甚至是有多個工廠參與的**再利用流程。當然，軟體開發也是其中之一，但是，它僅僅佔我目前工作的30%。在每個環境中，你都需要更好地了解自己的工作環境，在此認識基礎上實現改進，從而提高客戶滿意度。
\
infoq：團隊可以從kanban中獲得什麼優勢？
\\
\\\leopold：一開始，許多團隊會尋求可見性（seeking visibility）。當談到使用 kanban時，我聽的最多的目的可能是「能夠看到發生了什麼」。然而，我認為可見性不是目的。當涉及理解你的工作系統時，可見性是達到目的的手段或者方法。並且我認為這是人們能夠通過使用 kanban獲得的最大優勢。從根源上來講，kanban僅僅意味著了解發生的事情，並基於這種了解實施正確的改進。這聽起來好像非常容易，但是相信我，完全不是這麼回事，因為知識工作並不是直觀的。比如：當我們不是無時無刻加班加點工作時，工作往往能夠更加快速地完成。當我們立即開始客戶工作時，往往不能很好地服務客戶。更快地工作與更快地完成工作沒有直接關係。更早地開始工作往往會更晚地完成工作，等等。這非常的不直觀，但是，當涉及到改進時，理解工作系統的這些方面是必不可少的。關鍵在於你需要弄清楚為了分別優化你的業務或者客戶你需要採取的手段。旨在按時交貨的系統與優化產品上市時間所採取的行動和設計的系統是不一樣的。
\
infoq：如果我們是有多個團隊，或者有數百名員工的較大組織？敏捷框架能否幫組我們組織工作，我們還需要其它一些什麼嗎？
\\
\\\leopold：我並不是十分熱衷於「安裝」框架，無論是敏捷、精益或者其它目前流行的框架。有一點是明確的，如果你想在當今的商業現實中生存，敏捷非常重要。另外一點也同樣非常清楚：安裝一種方法或者框架不會給你帶來想要的敏捷。我來告訴你為什麼。
\\ 敏捷意味著什麼？對我而言，敏捷意味著企業適應不斷變化的世界或者甚至是為了成為行業領導者和創新所需要的領先。為此最重要的前提是企業不斷地變化和改進。如果你安裝框架，中心思想是複製隨機實踐。但是持續改變和敏捷不能通過複製實踐獲得。情況恰恰相反；在許多情況下，框架阻礙了持續改進，因為它們的安裝被看成是達到一種目標狀態：正如框架所規定的，企業需要重組，員工需要為新的工作方式重新培訓，然後執行新的流程和實踐。搞定！不，這是完全錯誤的！如果真實目的分別是持續變化或者敏捷，那麼你就從來沒有搞定。
\
infoq：您能否詳細說明如何使用kanban了解較大組織內的團隊協作的情況，如何使用kanban為提公升協作尋求新的方式？
\\
\\\leopold：我認為最重要的一點是 kanban不注重組織結構，比如團隊、部門等等。kanban使公司服務和價值生成成為關注焦點，並希望改進它們。因此，第乙個問題是：「如何才能為客戶創造價值？」一旦你有了答案，你就可以專注第二個問題了：「為了實現客戶價值需要什麼？」因此方法不是在企業100個團隊中實施 kanban然後詢問：「如何讓團隊一起工作？」而是分別從尋求服務和創造價值開始。如果你需要多個團隊，從而確保服務的價值生成，然後答案才是不要在單個團隊層面實施 kanban，而應該跨多個團隊。並且我認為這是 kanban的偉大之處：絕對沒有東西可以限制規模化 kanban。這意味著3個人的團隊可以使用 kanban進行改進，擁有數百人的組織也可以。你唯一需要做的是實施真正意義上的 kanban。
\
infoq：在infoq文章kanban能否規模化一文中，你給出了如何使用kanban在完整的交付週期管理在製品數量的案例。您能解釋一下kanban是如何有助於優化整件事，並阻止區域性優化的？
\\
\\\leopold：對我而言區域性優化意味著乙個系統只有一部分被優化，並沒有考慮整個系統。如果我們討論的不是只有10名員工的公司，那麼為了開發產品或者履行服務幾乎可以肯定需要數個團隊。比如，在軟體開發中，開發乙個產品可能需要多個團隊。如果在這種體系結構中，只是服務中的個別團隊被「優化」或者敏捷而不是整個服務，那麼如果整體效能寸步難行時你就不應該感到驚訝——儘管已經敏捷並花費不菲。我給你舉個例子：我曾經在乙個公司與他們的軟體開發團隊共事過，他們引入了 scrum。他們確實獲得了成功——他們成功提高了生產量降低了產品特性的交貨時間。團隊完成開發後，將產品移交給員工培訓團隊，員工培訓團隊的任務是給那些在商店使用應用的員工進行培訓。隨著開發團隊提高了效能，員工培訓團隊跟不上步伐，導致培訓質量下降。商店員工在購買流程中使用軟體諮詢終端客戶。但是，因為商店員工沒有獲得正確的有關最新產品和**活動的培訓，他們不能很好地服務客戶，導致客戶投訴的增加，最終導致成本增加。開發團隊的工作完成的很出色，但是這種「敏捷」是乙個大的區域性優化，因為最終沒有使終端客戶滿意。然後我們引入了 kanban的飛行階段3（flight level 3），在飛行階段3中我們優化整個價值鏈，在軟體開發中從產品負責人直到商店員工。其結果是一段使各方共同改進的旅程，從而讓終端客戶滿意。關鍵是不要敏捷或者改進組織結構，比如團隊——提**值創造！
\\ 如果 kanban被正確理解和執行，這些影響就不會發生，因為正如前面問題描述的，公司服務和價值生成成為焦點，而不是整個系統單
一、分離的部分。
\\ 在這點上有必要說一件事：區域性實施 kanban當然是可以的。如果系統被正確建模，那麼區域性優化就能很快被發現，未開發的潛力就能經濟地量化。這通常是初步討論的起始點，討論的結果往往是規模化——因為經濟論證相當有說服力。
\
檢視英文原文：don't optimize team-level performance
不要僅僅優化團隊層面效能
klaus leopold在 goto berlin 2015會議上發表了演講。在演講中他闡述了為什麼專注團隊層面的效能往往會導致區域性次優化 並不能在整個團隊層面提高敏捷。infoq對其進行了採訪，主要關於為什麼安裝 install 敏捷框架並不有助於提高敏捷 如何使用 kanban加強協作 和團...
OKR 不要讓目標僅僅成為口號
很多人都會給自己樹立 的目標，然後選擇一種自認為有效的 方式，或許是跑步，或許是節食，希望通過這種方式來達到實現 的目標。然而現實是真正 成功的人只有很小一部分。總結一下這些成功者的兩大特點 第一點是擁有足夠的自制力，第二是能夠制定詳細的 計畫。自制力和乙個人的人生經歷有關，不是每個人都可以靠著自制...
作團隊感悟 14 不能僅僅靠感情
前記 這又是乙個悖論 我們人人都希望在團隊裡，象在家裡一樣，處處洋溢著親情 友情，但是，很多的時候，在很多的團隊，這只能是一種夢想，而且，也沒有太多的公司能作到這一點。為什麼？這是因為，人，在某種程度上，都是 自私 的，在一定的條件下，都會不同程度的先為自己考慮。所謂的 大公無私 也只是在一定程度上...