?

精益開發是一種文化；減少浪費就是該文化的一個結果。減少浪費可以提高工作效率，但是比這更重要的是，它可以縮短開發周期，為客戶提供更高的使用價值。同時，更短的開發周期提高了市場的創新、完整性和響應性。并且，它們還為開發團隊的學習和不斷改進提供了一種有價值的機會。

我們關注的是如何使用精益化思想幫助團隊降低成本和縮短周期，可以讓團隊成員的工作更有效率。

一般來講，團隊和組織通常浪費了?40%?或更多的資源。浪費的形式有以下幾種：

不必要的開銷

不必要的返工

不必要的特性

構建了錯誤的東西

不必要的流程

在思考以上各種浪費時，您可能會考慮軟件的哪些部分是可見的，工作流程如何在系統中工作的，一個團隊的工作如何影響另一個團隊的工作，坦誠溝通如何促進創新。

如下所示，減少浪費可以讓開發團隊有更多的時間做卓有成效的工作，并提供以下改進：縮短周期時間，增加設定時間內提供的代碼數量。使用這些解決方案和持續交付，IBM開發團隊將周期時間從一年縮短至三個月。?

?Mary?和?Tom Poppendieck?定義了不同類型的浪費，探討一些關于常見的浪費時間、不創造價值的工作和不必要返工的問題。精益思想可以幫助減少這些問題，這樣人們就可以專注于需要快速高效地提供有效軟件的最重要的任務。

等待：

人們花時間等待別人做完一件事，這種等待通常是因為沒有明確的團隊之間的工作交接。以及工作進度和流程管控的不合理，導致人力資源的浪費。

任務切換和交接：

當人們經常切換任務時，時間會浪費在切換背景和重置環境上。經常留下部分任務沒有完成。將一個人指派到多個項目上工作可能會浪費時間。

移動：

在必須從座位上離開時，就會產生時間浪費。一些關鍵專家和客戶是否容易訪問？開發人員能否找到測試的結果，而不用從一個辦公室走到另一個辦公室？相關文檔存儲在哪里？交接是如何管理的？

額外進程：

不必要的流程、重復的任務和不必要的文書工作可能會浪費時間。這項文書工作會實際向客戶提供價值嗎？

額外特性：

實現一個不是解決業務問題所必需的解決方案所浪費的時間。

部分完成的工作：

如果用例場景尚未完成，而且沒有缺陷，那么該場景擁有少量的價值，或者沒有價值。您不可能知道該場景在產品環境之中是否起作用，或者它是否為企業提供了價值。

缺陷：

缺陷會阻止工作的完成。如果有很多缺陷，或者該項目有大量的技術未能達標，就會造成時間浪費。越早發現和修復缺陷，浪費就會越少。

如何在團隊工作中盡可能的減少浪費，讓開發團隊有更多的時間做卓有成效的工作？

?

價值流圖的存在有兩個目的：幫助公司找到并結束無用的活動。找到問題并創建一個更有效率的過程并不容易；就算是那些頂尖的公司也可以變得更有效率，存在改進的空間。但是對公司進行實質性的改變以消除那些沒有效率不高的活動，并不是那么容易的。相對而言，識別無效率活動就容易多了，但是將這些無效率的活動終結就另當別論了。價值流圖在增強公司競爭力的同時，還能產生一些需要的更改。但是首先，您得嘗試描繪項目的價值流圖。

評估浪費和價值流

價值流是一種技術，可以幫助團隊和組織了解任務花費了多長時間和有多少浪費。價值流可以幫助團隊了解工作項目何時沒有積極發揮作用，通過消除空閑時間，團隊可以明顯縮短周期時間。?

對大多數軟件研發團隊而言，關鍵的價值流是一個想法要花多長時間才能融入到生產環境中。下圖顯示了一個得到許多個人或團隊通過的想法，直到該想法得到部署。每一個想法都在等待被實現，或者已經采取了某些行動來將這個想法付諸于實現。

?

為了防止浪費，您需要管理和度量從一個想法到項目交付會在隊列中呆多久。對于您自己的價值流，可以考慮從只需要更改一行代碼的想法開始。要花多長時間才能交付這個想法？

使用價值流來查看組織中的工作的任何方面。通常，以下價值流有明顯的浪費：

確保新想法進入開發階段

確認需求和設計

搜索和查找相關的項目信息

復制和修復缺陷

獲取和設置一個測試基礎架構

將應用程序部署到測試環境

將應用程序部署到生產環境

除了價值流的長度之外，還需要考慮以下這些測量：

進程效率是通過總體工作量與消耗時間之間的比例來計算的

總周期時間

一些更改（比如自動化某個手動任務）可以減少周期時間，但也有可能會降低效率，因為它們不能減少所有浪費。考慮周期時間和效率的另一種方法是以下公式：

周期時間?=?工作量?+?浪費量

效率?=?工作量?/?周期時間

為了更好地理解這些指標，讓我們來看下圖所示的一個示例，圖中顯示了一個價值流，在發現該價值流的一個缺陷后，對該缺陷進行了修復。

?

在使用價值流時，測量工作量和浪費量（所耗費的時間減去工作量）是一個很好的實踐。在這個示例中，平均需要?4.25??個小時的工作量來修復一個缺陷，但該缺陷耗用了?16.25?個小時的時間，導致了?12?小時的浪費。

通過關注于降低某個價值流上的平均浪費量和工作量（例如，缺陷修復周期、實例或用例場景），您就可以開始讓進程變得更加簡潔，并向企業或客戶更快更多地提供價值。更短的周期可以提供更快的反饋，從而可以幫助您引導項目向意想不到、但有益的方向發展。

如何正確地畫出當前軟件項目團隊的價值流圖？

?

關于等待的浪費

許多浪費都可以歸因于等待，特別是以下這些常見的等待形式：

等待基礎架構

等待應用程序部署

等待其他團隊/任務

等待審查完成

前兩個等待時間源于將代碼從開發環境移動到測試環境，再移動到生產環境。

等待基礎架構

團隊需要花時間等待配置機器和部署軟件（部署到測試環境或部署到生產環境），這通常會導致長時間的等待。使用云來實現開發和測試，可以讓團隊在需要的時候快速配備基礎設施，用這些設施來測試他們的應用程序。這種方法可以讓等待時間從幾天或幾周縮短到幾分鐘。團隊可以在開發和測試階段的更早時間按訪問類似生產環境的環境。這種訪問可以及早地發現缺陷，最終減少部署風險。

等待應用程序部署

浪費的另一個來源是在部署應用程序期間花費的時間。手動部署可能非常耗時。如果專家資源（比如應用服務器管理員或安全專家）被使用，那么這個過程可能會花費額外的時間，因為該團隊必須等待另一個團隊完成部署。

DevOps?使團隊能夠自動化部署應用程序，管理哪些東西應該部署到每個環境，并促進環境之間的編碼。而不是等待部署，然后可以自動完成部署。

最終我們獲得了兩項功能：自動部署和云，它們可以顯著減少團隊花在等待基礎架構和部署上的時間。在按下一個按鈕或代碼檢查時，提供基礎架構，部署應用程序并重新運行測試。如果應用程序獲得通過，那么它可以輕松地通過各種測試環境得到晉升，還可以部署到生產環境。

實現這些更改是一個不斷發展的過程。一些組織選擇加速這個周期的某一部分，或者最初只是為了某些環境而實現這些更改。自動化部署或者使用云，這些使得團隊和組織能夠顯著縮短周期時間，提高他們的創新能力和反應。

等待其他團隊/任務

浪費的第三個主要來源是團隊的失敗，他們受他人的影響優先完成了某些工作。通常，沒有一個簡單的方法讓團隊或個人了解他們的工作的哪些方面影響到了他人。scrum?方法試圖通過關注這些障礙的日常會議解決這個問題。部分任務管理工具通過DashBoard提高其他團隊和個人任務的可見性。

在許多開發場景中，某個任務被阻塞，導致團隊無法取得進展。在這種情況下，可以暫停某項任務，釋放和存儲與該任務相關的所有代碼更改。在任務暫停后，開發人員就可以開始處理另一個任務。當最初的任務變得暢通時，開發人員可以恢復原來的工作，合并來自原來任務的更改（如果需要的話）。

開發人員可能有大量暫停的更改或變更集。一個變更集，是一個存儲庫對象，收集了一組相關文檔、組件變更，以便可以將它們應用于單個操作中的某個流程目標，比如工作區或工作流程。每一個暫停的變更集都代表了未完成工作形式的浪費，但是，只要開發人員仍在正致力于有價值的工作，這種形式的浪費就不值得太多的關注。有時，浪費在短期內是必需的。臨時浪費的來源可以采用回顧的方式進行分析。

等待審核完成

審查工件也可能導致等待浪費，因為作者常常需要等待審查結束才能進行后續操作。追蹤人們是否完成了審查通常會浪費很多時間。通過第三方工具提供集中和自動完成審查，可以將需要審查的工件（需求、設計、代碼和軟件資產）以電子方式分配給審查者，而且可以采用一種簡單的方式獲得并實現他們的審查。審查者和被審查者會獲得關于評論的自動通知和提醒。團隊成員可以隨時查看任何審查狀態。這種方法可以減少工件審查過程中的浪費。

?

任務切換和交接會導致相似類型的浪費。由于任務切換造成的浪費發生在團隊成員將部分工作轉交給另一個人時（例如，開發人員修復了一個缺陷，并將它轉交給測試員，以驗證該修改）。任務交接發生在不同任務之間進行切換時。

理想情況下，在一個小型的敏捷項目中，很少進行任務交接，因為團隊成員傾向于承擔所有項目角色（編寫實例、開發代碼、測試和執行其他類似任務）。然而，在更大的項目中，或者在很少有全能人才的項目中，任務交接是必需的。任務交接會引入大量的浪費，原因如下：

由于需要在工具或團隊之間重新設置密鑰信息而導致的返工；

由于團隊成員沒有意識到等待的東西已經準備就緒而導致的等待時間

缺乏足夠的細節；

過時的工件；

沒能成功地將更改傳達給團隊；

跬步進化論能夠協助客戶通過以下方式減少開發和操作之間的交接浪費：

部署持續化和自動化；

促進環境之間的應用的能力；

提升組織和管理大量版本的能力；

這些功能可以有效消除與部署軟件相關的手動活動和容易出錯的活動，并幫助管理版本，以及最終會顯著減少浪費和風險的更改。團隊可以更頻繁地發布他們的軟件，以便可以更早地提供價值，這樣團隊和組織就可以更快地獲得反饋，簡化開發和操作之間的任務交接。

借助于研發流程的改進，來自任何團隊的團隊成員都可以通過看板、即時通訊工具、電子郵件列表或?Web?中的視圖來查看信息和關注其他團隊中的變化：

需求團隊可以查看他們的哪些需求已經轉換成正在運行的或已經測試的代碼；

設計團隊可以跟蹤可能會影響他們的不斷變化的需求，從而減少設計錯誤需求方面的精力浪費；

開發團隊可以跟蹤測試團隊報告的新缺陷和不斷變化的需求，還可以很輕松地規劃實現新需求和修復缺陷的工作；

測試團隊可以查看哪些需求已經發生變化，哪些需求已準備好測試，以前中斷的哪些測試現在已經準備好重新測試，而且可以很輕松地計劃測試活動；

運維團隊可以查看構建的狀態，查看應用程序可以部署到哪些環境中，在每個構建中有哪些缺陷修復和新特性。

可見的和易于訪問的信息可以極大地減少交接過程、額外流程和運動中的浪費，因為團隊成員擁有一些他們可以輕而易舉地獲得的信息。他們可以訪問這些信息，不必打擾其他團隊成員就可以實現狀態更新。

不必要的流程，重復的任務和不必要的文檔工作可能會浪費時間。這個文檔會給最終用戶提供應有的價值嗎？

額外進程是不會向用戶提供價值的多余進程。例如：生成沒人閱讀的文檔，更新計劃，手動收集指標和進度信息，組織沒人響應的評審，以及其他類似的不必要任務。使用前面描述的價值鏈分析或類似的技術，在上下文中評估每個進程步驟，了解其重要性。

確定進程是否向客戶提供了價值，或者是否延誤了客戶獲得價值的時間。手動部署進程就是進程浪費的一個很好的示例。有人編寫很長的、詳細的和完整的文檔，描述如何部署應用程序，還編寫了一些隨后手動執行的指令，以便將每個應用程序部署到測試環境或生產環境。在某些情況下，組織會執行雙重部署，以確保正確遵循指令。大量的持續交付解決方案（例如TeamCity / Cloud Flow）都提供了一個圖形化的進程編輯器簡化了應用程序部署，以便創建自動化部署。Jenkins 2.0新引入的PipeLine（圖1）功能有助于減少構建或部署過程中造成的缺陷，顯著降低失敗部署的風險。

?圖1: Jenkine PipeLine樣例

而且，團隊還可以配置持續交付工具來制定一個組織的進程，有一些功能可以在整個過程中為團隊提供無縫引導。有時團隊成員或許會跳過某個進程。但是，與團隊成員不遵循進程相比，持續交付工具更容易引導團隊遵循進程。例如，如果一個團隊決定，他們需要在其單元測試中檢測?70%?的代碼覆蓋率，如果代碼覆蓋率不符合這個標準，那么持續集成可以觸發Andon操作，禁止代碼交付。

如果團隊想以某種方式進行工作，或者發現進程的某些元素沒有為他們工作，持續集成工具還為團隊在覆蓋進程方面提供了靈活性。某個團隊可能決定他們想要某些組件的更高層次的覆蓋率，或者他們想要有選擇地強制執行代碼覆蓋率要求。例如：集成需求進度的跟蹤后，團隊成員可以等待已定義特性的細節，直到實現他們所在的迭代。

持續發布能夠通過消除手動進程，實現更小更頻繁的發布、持續集成、集成測試、測試虛擬化和自動化測試。這些實踐還可以減少浪費，因為它們不僅能夠縮短周期時間，還可以更頻繁地接收反饋。能夠通過查看價值鏈來評估整個進程的上下文中的自動化改進（圖2）。

圖2: 持續發布樣例

讓團隊使用他們的回顧性調查來分析進程并確定可以通過調整哪些地方來實現不斷改進，是一個很好的實踐。通過在所有任務中收集數據，并提供分析數據的能力，有助于確定是否存在不增加價值的進程或任務。

缺陷會造成兩種浪費：修復缺陷所產生的浪費，以及軟件不能正常發揮作用而產生的浪費。

通過提高需求的質量，有助于降低缺陷的產生率。它還有助于減少解決缺陷所需的時間，這樣就可以盡可能少地產生浪費。搜索、修復和解決缺陷的過程又叫做缺陷價值鏈。通常，這會產生大量的成本，因為它需要若干個團隊或組織進行親密無間的協作。

跬步進化論可以通過提升缺陷價值鏈的效率和減少缺陷價值鏈來支持精益軟件開發。對于敏捷團隊來說，這一點很重要，因為他們不應該聲明擁有重大缺陷的實例點（實例點?是估算用戶實例復雜性的混合單元）。缺陷意味著代碼尚未完成，仍在進行中，在精益軟件開發之中，人們不愿意看到這種狀態。缺陷必須在一個沖刺階段中快速被找到和解決。對于確保軟件開發期間技術能力達標來說，有效的缺陷解決過程十分關鍵。

例如，在豐田公司，人們并不是僅僅為快速修復缺陷而努力，而是理解問題產生的根源，這樣就可以避免將來產生同樣的錯誤。在其著名的?“Andon”?實踐中，當發現一個缺陷時，可以立即停止整個生產線來修復它。該實踐的目標是減少后續工作的工作量。在軟件開發過程中，如果構建終止了，那么就應該快速盡全力修復缺陷。

后來他們發現，缺陷成本高于修復成本。上下文切換需要額外的資源，如果后來發現缺陷，則必須重復額外的進程，這些都會帶來額外的成本。為了及早發現缺陷，減少與缺陷相關的浪費，必須盡早在生命周期的早期進行測試。使用合理的持續交付配合自動化測試有助于降低整體研發成本。同時，確保相關的團隊或組織及時收到缺陷信息，小批次地在短周期內處理缺陷，也有利于降低修復成本。

在持續交付中增加恰當的自動化測試及修復流程，并及時通知相關干系人進行Andon操作，可以有效減少缺陷價值鏈數量，提升修復缺陷價值鏈效率。

總結

以上是生活随笔為你收集整理的软件开发中的精益思想解读︱精益软件开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。