為了改進研發效能，首先要知道從**開始。讓我們將從乙個故事講起。
\n\n
\n酒吧門前的路燈下，乙個醉漢踉踉蹌蹌地找著什麼，警察遠遠地看著，十多分鐘過去了，終於忍不住走上前去。
\n
\n\n「你在找什麼？」警察問到。
\n「我的鑰匙」 醉漢說。
\n警察快速掃視了一下：「沒有啊，是丟在這嗎？」
\n「不是！」醉漢回答。
\n「那幹嘛在這找？」警察不解地問。
\n「只有這能看見啊！」醉漢不耐煩地說。
\n
鑰匙的英文是\u0026quot;key\u0026quot;，也有「關鍵」和「答案」的意思。路燈照亮的地方，並非「關鍵」所在。在路燈下尋找不存在的鑰匙，當然是愚蠢的。然而，在產品開發中類似情境卻一再發生。
\n在產品開發中，光照亮的是各個區域性，比如：各環節的產出怎麼樣，工程師是否在忙。然而，整體並不是區域性的簡單疊加。如果缺乏全域性的協調，即使各個區域性都很繁忙，整體的效率卻不一定高。
\n\n上圖列舉了部分長期困擾我們的問題，如：團隊協作問題、目標和進度對齊問題、環境穩定性問題、整合問題等。這些都是系統性的問題，根源不在區域性，否則，以阿里工程師的能力和責任心，它們早就被解決了。
\n在錯誤的地方尋找不存在的鑰匙，注定無功而返，甚至適得其反——區域性優化損害整體效能，這是研發過程改進最大的坑。研發效能提公升的關鍵究竟在**呢？
\n\n
在《the principles of product development flow》一書中，作者don reinertsen指出：
\n
\n\n產品開發的核心問題從來不是停滯的資源（工程師），而是停滯的價值項（使用者需求）。
\n
如下圖所示，產品交付中的各類問題，都會導致需求停滯。比如常見的協作、環境、工程方法、質量等問題，都會表現為需求停滯，停滯的需求又從根本上損害研發效能，圖中列出了其中的一些影響。
\n\n如果僅僅關注「停滯的工程師」，我們總有辦法讓各個資源環節忙起來，至少看上去忙起來，但它往往只是掩蓋了問題。解決「停滯的需求」才是根本，為了讓需求順暢流動，我們必須解決各類根本問題，需求的順暢流動又直接促進了效率、響應能力、靈活性、質量、創新以及士氣的提公升。
\n然而，停滯的需求是影響研發效能的關鍵所在，但是卻很少被關注。因為它很難看見，是光未能照亮的地方。
\n\n
為改進研發效能，我們不能做路燈下的醉漢。而是要讓光照亮關鍵所在，讓需求的停滯以及停滯的原因即時顯現，視覺化需求端到端的流動過程是做到這一點的基礎。
\n在產品開發中，視覺化實踐並不新鮮。很多號稱應用敏捷開發的團隊，都在做，比如：在白板上貼上不同顏色的即時貼，或者應用看板展示工作任務。然而，它們中的大多數只不過是展示團隊工作的任務牆，並沒有照亮產品交付的關鍵，對效能改進的作用有限。
\n什麼才是有效的視覺化呢？我們先看乙個實體看板的例子。下圖中，天貓新零售某產品技術團隊的看板，它視覺化了需求端到端的流動過程。
\n\n看板的中藍色卡片是需求，對應可交付的使用者價值。讓光照亮關鍵所在，就是要視覺化使用者價值端到端流動和交付的過程。
\n需求在看板上從左至右流動，經過看板上的每個階段，直至交付。從最左的「選擇」列，決定做乙個需求開始，直到上線結束。這是乙個端到端的過程，拉通了產品、開發、測試、運維等各個前後環節。
\n單獨看\u0026quot;開發中\u0026quot;這個階段，需求被分解成為任務——圖中黃色紙條。任務與其所屬的需求處於同一行，我們稱之為泳道。泳道的首列（藍色紙條）是需求，下屬任務（黃色卡片)按模組不同放在各自的列內，如前端、後端、以及外部依賴任務等。執行過程中，同一需求下屬的任務盡量對齊進度，快速完成需求。所屬的任務全部完成後，需求進入待測試，泳道清空，可以讓下一需求進入。
\n以端到端的價值流動過程為基礎，團隊就能即時看到問題，如：需求是否順暢流動，在**發生了停滯和積壓，是否存在瓶頸。這就是所謂：光照亮了問題所在。
\n在這個案例中，我們看到有效的視覺化要做到四點：
\n\n
使用者價值驅動——需求反映使用者價值，是流動的主線索；\n
前後職能拉通——以端到端的需求交付為線索，連線各個職能和環節；\n
左右模組對齊——保證任務向需求對齊，快速交付需求；\n
瓶頸問題即時可見。\n
\n其中，第四點是前三點的結果。它們共同作用，讓團隊看到需求流動（也是價值交付）的端到端的過程，看到需求在流動過程中的狀態、問題和瓶頸，奠定持續快速的交付價值，以及持續改進的基礎。這就是讓光照亮了關鍵所在。
\n接下來，我們按這四點，分別介紹視覺化價值流動的操作實踐。
\n\n
為了視覺化端到端的需求流動，我們首先要明確流動的是什麼。它大致可以分為兩類：
\n\n
\n業務需求。它們直接體現業務價值、貢獻業務能力，如：使用者對產品的需求、業務規劃的需求，體驗提公升需求等。
\n\n
\n支援性的需求。它們不直接體現業務價值，但幫助更快、更高質量和持續的交付價值，如：基礎設施的建設和改進，持續交付管道和自動化測試的建設，技術架構的公升級和重構，新的技術框架或演算法庫的引入等。
\n\n
\n\n不同的產品和組織，對流動單元的分類不同。上表是某個產品交付團隊的需求分類，它區分了需求的類別，其輸入的規律及處理的規則等。
\n重點是：需求是價值的載體，是端到端流動和交付的基本單元，視覺化的主體應該是從使用者出發的需求，而不是組織內部的任務。
\n\n
識別了流動的基本單元——需求，接下來要做的是：展現需求端到端的流動過程。
\n\n所謂「端到端」，必須從業務視角定義——從業務出發，到業務結束，形成閉環，上圖表示了端到端流動過程中的標誌性階段。
\n前乙個「端」是輸入。典型的是從需求的選擇開始，市場的潛在機會總是無窮的，團隊從中選擇某些機會，並決定投入，這是價值流的起點。「被選擇」的價值項並不能直接進入開發階段，它需要被分析和澄清，才可以輸入給開發。我們稱達到這一狀態為「就緒」。\u0026quot;就緒\u0026quot;是乙個重要的階段，它決定開發團隊的輸入質量。
\n這四個階段設定了端到端價值流動的框架。以此為基礎，團隊還要設定流動的具體流程步驟，下一節中將展示具體的例項。
\n\n
視覺化應該體現團隊協作和交付價值的過程，下圖中的看板再現了團隊的前後職能，以及平行模組間協作交付價值的過程。
\n\n首先，它反映了環節間的協作。看板上的各個列，代表需求交付的環節。價值項沿各個列順序流動，體現上下游之間的協作。它們中有些是工作列，如：分析、實現、測試等，價值項在工作列被處理；有些則是等待列，如待評審、就緒、待測試、待發布等。
\n其次，這一價值流也反映了環節內相關方的協作，如：前、後端的協作，內部團隊與外部依賴方的協作等。圖中，在實現階段，乙個需求被分解成不同模組以及外部依賴方的任務。需求及其分解出的任務被放在同一橫向泳道之中，體現了它們的關聯關係。所有下屬任務完成了，需求才能移入下一環節——待測試列，它占用的泳道也被清空，等待下乙個需求進入。
\n看板中的每個泳道容納乙個需求，團隊的目標是盡快完成需求，而不是每個人手上有任務在做，它確保了任務向需求的對齊，這就是我們所說的「左右部門（模組）對齊」，對齊的物件是需求、是價值。
\n\n
價值驅動、前後拉通、左右對齊，這三條原則讓價值流動和交付的過程清晰可見。基於這一基礎，團隊就可以清晰的暴露需求交付過程中的問題和瓶頸。
\n\n上圖中的看板展示了價值流動中最常見的問題，它們是：
\n\n
通常，團隊會在每日的站會上，檢視需求流動的狀態，以及流動過程中的問題，關注並即時解決這些問題，讓需求更順暢和快速的流動並交付。
\n\n
雲效的看板服務，貫徹了上文提到的理念和方法，互動上也針對主要使用場景做了優化。我們來看幾個實際使用的案例。
\n\n上圖是優酷的乙個專案團隊看板的截圖，它反映了端到端的價值流動過程，起到了拉通產品、設計、開發、測試等職能的作用。它支援對需求下屬任務分組，並展開顯示在同一泳道中，實踐上很好的促進了平行功能團隊（如：前後端、以及演算法及相關依賴方）的任務向需求的對齊。
\n同時團隊基於它形成了順暢的協作和交付模式，做到了有效協作、順暢交付和質量內建（在每個過程環節保證質量），通過它以及相關配套實踐，團隊的協作、交付質量和時效都有了本質提公升。
\n\n上圖是某中颱技術團隊的例子，他們基於團隊看板暴露了需求的嚴重停滯，團隊清楚看到了停滯帶來的影響，分析了造成停滯的原因。前後四個迭代，每個迭代都發現並聚焦不同的問題，通過協作、需求、工程等方面的實踐解決了這些問題，讓需求的流動順暢起來了，團隊交付質量和效率以及團隊對外的響應靈活性都顯著提公升。
\n在這個例子中，視覺化讓團隊看到了問題和影響，並採取管理和技術的手段去解決這些問題，團隊的持續發布和交付效率和質量都得到了明顯改善。
\n雲效的看板的功能是提公升團隊協作、改善研發效能的有力工具，值得大家去探索和使用。
\n\n
「視覺化端到端價值流動」是基礎實踐，它照亮研發過程改進的關鍵所在，為持續快速交付價值，為研發效能改進奠定基礎。
\n總結:
\n\n
\n作者簡介
\n何勉，阿里巴巴資深技術專家，國內最早的精益產品開發實踐者之一，暢銷書《精益產品開發：原則、方法與實施》作者。專注於精益產品交付、精益創業創新及精益產品設計等領域，幫助組織提公升研發效能。
\n
需求，還是需求
所有軟體開發都是構建在需求的基礎上的，脫離需求，與現實需求脫軌的開發都不具有商業意義。許多成熟的軟體開發過程學都非常重視需求，傳統開發模型比如瀑布模型會要求編寫非常規格化的軟體需求說明文件 敏捷開發過程比如xp則更注重在開發過程中，通過高質量的溝通，在客戶及開發方之間形成資訊的良性迴圈，以漸進發展的...
都2020了 ,YUM和DNF還是要區別下的了
dnf dandified yum yum yellowdog updater,modified dnf依賴解決方案採用用由 suse 開發的高效能 libsolv 庫 yum依賴解決方案為公共 api api 介面文件完備 api 介面文件較完備 由 c c 和 python 編寫 由 pytho...
還是想你了
又想你了，怎麼辦？人有的時候真的很賤，是不是？也有不少人說過很欣賞我，關於我的種種優點，但那些都是可有可無的，我最期待的還是你的一句認可。我知道自己在你的眼裡什麼都不是，充其量是 好朋友 誰知道呢。可我偏偏就是認定你了，呵呵，受孽傾向，對，就是這樣。其實真的很想給你打 但害怕打擾你，影響你學習。回想...