《如何將精益方法應用于企業IT？》要點：
本文介紹了如何將精益方法應用于企業IT？，希望對您有用。如果有疑問，可以聯系我們。

精益工程

將精益方法應用于企業IT

LEAN ENGINEERING
LEAN METHODOLOGY APPLIED TO ENTERPRISE IT

譯者：龍井
校對：胥峰
原文出處為?http://t.cn/RMIVZvX

一、前言

精益工程定義了一套高速率且低風險地創建和部署軟件產品的指導原則.使用精益工程,可以降低驗證新技術、在流程中實現增量變更、向市場推出新產品的風險,并且能夠以一個更快的速率達到一個高質量的結果.

每個學科都建立在一套原則和主張之上.作為軟件工程實踐的門徒,我們有必要定義出一套清晰且永恒的原則,用來指導我們創造產品的流程、方法和架構.

二、起源

精益不是新概念,精益的 DNA 可以追溯到上世紀五六十年代,豐田公司優化其著名的精益制造流程時.精益制造的許多指導原則都是歸功于豐田汽車公司副社長大野耐一和新鄉重夫,他們一起創造了豐田生產系統(Toyota Production system,TPS).

大野耐一著手在他所負責的生產過程中根除效率低下和消滅浪費,他引入了幾個概念,比如：小批量,準時制,持續改進.

三、小批量

作為工程師,當我們面臨大量的工作時,我們的第一想法就是設計出最系統化的方法,以便我們可以通過圍繞重復任務來組織工作,實現批量處理.

想象一下要準備1000封信.

作為工程師,我們的第一想法很可能是要盡可能的以最高效的方式處理這項工作.使用大批量處理方法流水線化生產.

1. Tri-Fold all the letters(將所有信紙折疊三次)
2. Place the Stamp, Delivery and Return address stickers on the envelopes(在信封上貼郵票、收信地址和退信地址)
3. Place the letters in the envelopes(將信紙裝進信封)
4. Seal the envelopes(密封信封)

這樣看起來很簡單且高效,因為重復,我們非常高速率地處理單個任務.但是我們錯了.

如果信封和信紙的尺寸不合適呢?如果貼紙沒有膠水了嗎?如果信封有問題不能密封呢?

為了了解制造過程中是有缺陷的,小批量的做會更好.在這個案例中,一個完整的循環流程是：

(1)折疊

(2)塞信紙

(3)貼郵票和地址

(4)密封

由此我們可以在大規模處理之前,識別出流程中可能失敗位置.

Small Batches = Fail Fast!

小批量=快速失敗!

四、持續改進

無論何時,流水線上的任何工人在豐田制造流程中發現了問題,都可以停止流程,所有人都會幫助修復問題,直到問題修復才能繼續進行流程.

我們鼓勵工人找到問題的根本原因并立即修復.流水線上的工人也都被鼓勵在自己的崗位上進行改進,而無須征得管理者的同意.這個流程就是持續改進.持續改進的一些好處：

• 改進是基于許多小的變化,而不是完全顛覆
• 由于改進點子都來自工人,所以不會有特別大的變化,因此也更容易落實
• 小的改進不會像主要流程改變那樣需要大筆的資本投資
• 持續改進鼓勵工人們對自己的工作負責,有助于加強團隊合作,從而提高員工的積極性

這個領域的先驅者愛德華茲·戴明將持續改進視為根據組織目標對來自過程和來自客戶的反饋進行評估的系統的一部分.

最廣泛使用的持續改進工具是一個四步質量模型 PDCA 循環——plan(計劃)-do(執行)-check(檢查)-act(糾正) ,也被稱為戴明環：

• Plan: 識別改變的機會和計劃
• Do: 小規模的實現改變
• Check: 使用數據分析改變的結果以確定行動是否帶來不同的效果
• Act: 如果改變成功,則在更大規模范圍內落地并持續評估結果,如果改變無效,繼續循環

Continuous Improvement = High Quality!
持續改進 = 高質量!

五、精益創業(LEAN STARTUP)

埃里克·萊斯將精益制造中的概念應用到了他所參與的許多在互聯網泡沫時期和之后的創業項目.他發展出軟件產品開發流程的兩個指導原則：快速失敗和持續改進.

埃里克·萊斯的整體主張是如果創業是投資自己的時間去迭代式地構建產品或服務以滿足早起采用者的需求.他們可以降低市場風險并避免需要大量的初始項目資金和昂貴的產品發布和失敗.

埃里克·萊斯定義了一個將新產品成功推向市場的科學方法.你可以在構建-度量-學習的生命周期中持續地進行小的調整以保持高速進步,而不是制定需要建立在非常多假設基礎上的復雜計劃 .

構建 – 度量 – 學習?是一個反饋環,它的目標是在循環中盡快驗證你的想法.

你首先定義出最小可行產品(MVP),這個版本的產品允許團隊以最小的付出進行最大程度的驗證性學習.

構建 MVP 并發布到生產環境(持續交付)并度量運行時健康狀態和產品的可用性(持續分析)

然后你可以使用對比測試和調查的方法讓你的客戶參與產品反饋中來.這為下一個循環提供了學習(持續反饋)的輸入.

六、最小可行產品(MINIMAL VIABLE PRODUCT)

最小可行產品(MVP)的定義是這個版本的產品允許團隊以最小的付出進行最大程度的驗證性學習.

在整個周期中的每個迭代中,準確定義出MVP是團隊想要成功實踐這個方法必須要掌握的重要技能.范圍太廣會拖慢速率,范圍太小又不足以在驗證此次發布的周期中充分學習.

至少有一件事是肯定的,我們想要避免以激進的方式從上到下設計和實現一個大系統的方法.這種方法會導致巨石架構、延期、缺少對最終用戶真實需求和期望的充分溝通以及因為大量的任務和向遺落戰境不可避免的死亡行軍喪失了開發生產力.

通過掌握定義最小可行產品的技能,我們可以實現有用且簡單的產品,以便我們盡快讓用戶參與進來,獲取反饋、驗證我們的想法并且在撞到南墻之后快速失敗.

比如,比想要驗證微服務架構是未來項目的正確方向.不是每個人都相信并正在學習一個傳統的巨石架構,但他們有興趣看看這種方法是否有效.最小可行產品就可能是以一個或幾個 API 定義一個微服務并基于如下的公共能力實現它

• Logging and Error Handling(日志記錄和錯誤處理)
• Run-time Analytics(運行時分析)
• In-memory Caching(內存緩存)
• Data Persistence(數據持久化)
• API Design(API設計)
• API Management(API管理)

一旦你構建成功之后就部署到生產環境,讓團隊(客戶)去玩一玩 API,如果使用了?API 管理,可以獲得實時的分析.

API管理(http://theundocumentedapi.com/2014/08/18/api-management-made-easy/)

第一眼看起來好像有很多事,但是通過分切關注點和不考慮太多服務業務邏輯方面的因素,你可以進行微服務良好的 API 設計和常見的錯誤處理,日志記錄和報告能力等等將是整個項目的可行方向,而不僅僅是這一個服務的驗證學習.

七、精益工程(LEAN ENGINEERING)

精益工程利用精益創業中的持續創新的構建-度量-學習循環并應用在企業級產品開發中.注意術語“產品”的使用,這是一個重要的差別.作為工程師,我們習慣于根據項目進行思考,項目擁有起始日期,任務,里程碑,而且往往不是永久持續下去的.

簡單改變一下我的思維,“我們在創造產品“,我們可以超越我們的條件并且成為快速地為市場帶來高質量產品的專家級企業家.

我的市場是我們支持的企業的員工和伙伴.我們的基礎設施和應用產品提供了運轉一個公司的基石 .我們是企業級的企業家.

1. 持續交付(CONTINUOUS DELIVERY)

為了實現高效率高質量的目標,我們有必要頻繁地自動化發布.在構建階段,我們定義了最小可行產品,這個版本的產品允許團隊以最小的努力收集大量的經證實的認知(Validated Learning).我們通過定義部署流水線自動化我們的軟件開發生命周期(SDLC).

部署流水線包括持續集成,開發者使用自動化源代碼控制、構建和單元測試.部署流水線是將代碼從代碼庫交付到測試人員手中的自動化過程,包括從測試環境到預發布環境,再到生產環境.

更廣泛的是自動化從創意到最終用戶手中可使用的服務的全過程,以驅動反饋環.

部署流水線既定義了部署計劃又定義了發布計劃.這兩者的區別在于：

• 部署是一個工程決策,關于以何種頻率部署到預發布環境以驗證構建內容.
• 發布是一個業務決策,當團隊準備好期待反饋過程時進行.

自動化的主要優點是它創造一個可重復的、可靠的、可預期的過程.自動化可以防止混亂,如果結合一個完善的反饋機制,可以洞察團隊的績效.

2. 持續分析(CONTINUOUS ANALYTICS)

為了給持續學習試驗提供輸入,無論是通過自動化部署流水線還是生產環境.我們想要利用每一個優勢去收集數據.我們的目標是將分析結合到流程的每個部分,以便生成可以合成為信息并作為學習過程的一部分的數據.

為了從代碼庫中獲取實時數據,在代碼、日志和異常處理的級別引入度量是非常重要的.我們也會使用已有的運維工具度量負載、服務和進程健康狀態,數據庫指標等等.如果有必要,團隊可以考慮構建一個面板將所有信息合并到一個視圖中便于展示和閱讀

3. 持續反饋(CONTINUOUS FEEDBACK)

我們經常地發布并讓我們的客戶參與到反饋中來,這些反饋可以幫助我們定義下一階段的 MVP 開發.

隨著 MVP 產品的功能增長,產品從早期采用階段成長為你可以從之收獲利潤的產品.由于你在最開始就已經將產品發布到生產環境,你無須擔心產品會在發布的時候失敗,因為你從第一天開始就已經將產品發布了.

4. 精益工程和云計算(LEAN ENGINEERING AND THE CLOUD)

精益工程在小且機動性高的跨職能團隊中效果最好.精益工程的目標是通過自動化和頻繁地發布以實現快速且可靠的方式高效率地交付高質量的、有價值的軟件.

使用商業云平臺可以創建高度自動化的按需提供流程并基于構建-度量-反饋循環快速迭代.引入云平臺的持續集成和部署流水線并使用構建于云平臺中的分析工具.

商業云平臺提供一鍵式基礎設施和通用應用和數據服務.通過利用這些服務的優勢,開發者可以專注于為他們的客戶創造真正的價值.

八、總結(SUMMARY)

精益工程是精益方法在低風險地交付高質量軟件方面的應用.它吸收了精益制造、精益創業、持續交付的思想.特別感謝 Jez Humble(http://jezhumble.net/),他在這個領域里非常有影響力并且一直處在宣傳這些思想的最前沿.

推薦學習(RECOMMENDED LEARNING)

1. The Lean Startup, Eric Reis(?http://www.amazon.com/The-Lean-Startup-Entrepreneurs-Continuous/dp/0307887898?)
2. Lean Enterprise, Jez Humble, Barry O’Reilly, Joanne Molesky(http://shop.oreilly.com/product/0636920030355.do)
3. Continuous Delivery, Jez Humble, David Farley(http://www.amazon.com/gp/product/0321601912?tag=contindelive-20)

中英文對照版PDF下載鏈接：https://pan.baidu.com/s/1hsBOcni?

密碼: a65q

胥峰

盛大游戲高級研究員

《Linux?運維最佳實踐》作者、《DevOps: A Software Architect’sPerspective》譯者.擁有10年運維經驗,目前關注運維自動化、DevOps以及Docker在游戲中的應用等相關技術主題.運營公眾號“運維技術實踐”.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4366.html