一、前言
精益工程定义了一套高速率且低风险地创建和部署软件产品的指导原则。使用精益工程，可以降低验证新技术、在流程中实现增量变更、向市场推出新产品的风险，并且能够以一个更快的速率达到一个高质量的结果。
每个学科都建立在一套原则和主张之上。作为软件工程实践的门徒，我们有必要定义出一套清晰且永恒的原则，用来指导我们创造产品的流程、方法和架构。
二、起源
精益不是新概念，精益的 DNA 可以追溯到上世纪五六十年代，丰田公司优化其著名的精益制造流程时。精益制造的许多指导原则都是归功于丰田汽车公司副社长大野耐一和新乡重夫，他们一起创造了丰田生产系统(Toyota Production system,TPS)。
大野耐一着手在他所负责的生产过程中根除效率低下和消灭浪费，他引入了几个概念，比如：小批量，准时制，持续改进。
三、小批量
作为工程师，当我们面临大量的工作时，我们的第一想法就是设计出最系统化的方法，以便我们可以通过围绕重复任务来组织工作，实现批量处理。
想象一下要准备1000封信。
大野耐一着手在他所负责的生产过程中根除效率低下和消灭浪费，他引入了几个概念，比如：小批量，准时制，持续改进。
三、小批量
作为工程师，当我们面临大量的工作时，我们的第一想法就是设计出最系统化的方法，以便我们可以通过围绕重复任务来组织工作，实现批量处理。
想象一下要准备1000封信。
作为工程师，我们的第一想法很可能是要尽可能的以最高效的方式处理这项工作。使用大批量处理方法流水线化生产。
Tri-Fold all the letters（将所有信纸折叠三次）
Place the Stamp, Delivery and Return address stickers on the envelopes（在信封上贴邮票、收信地址和退信地址）
Place the letters in the envelopes（将信纸装进信封）
Seal the envelopes（密封信封）
这样看起来很简单且高效，因为重复，我们非常高速率地处理单个任务。但是我们错了。
如果信封和信纸的尺寸不合适呢？如果贴纸没有胶水了吗？如果信封有问题不能密封呢？
为了了解制造过程中是有缺陷的，小批量的做会更好。在这个案例中，一个完整的循环流程是：
（1）折叠
（2）塞信纸
（3）贴邮票和地址
（4）密封
由此我们可以在大规模处理之前，识别出流程中可能失败位置。
Small Batches = Fail Fast!
小批量=快速失败！
四、持续改进
无论何时，流水线上的任何工人在丰田制造流程中发现了问题，都可以停止流程，所有人都会帮助修复问题，直到问题修复才能继续进行流程。
我们鼓励工人找到问题的根本原因并立即修复。流水线上的工人也都被鼓励在自己的岗位上进行改进，而无须征得管理者的同意。这个流程就是持续改进。持续改进的一些好处：
这个领域的先驱者爱德华兹·戴明将持续改进视为根据组织目标对来自过程和来自客户的反馈进行评估的系统的一部分。
最广泛使用的持续改进工具是一个四步质量模型 PDCA 循环——plan(计划)-do(执行)-check(检查)-act(纠正) ，也被称为戴明环：
Continuous Improvement = High Quality!
持续改进 = 高质量！
五、精益创业（LEAN STARTUP）
埃里克·莱斯将精益制造中的概念应用到了他所参与的许多在互联网泡沫时期和之后的创业项目。他发展出软件产品开发流程的两个指导原则：快速失败和持续改进。
埃里克·莱斯的整体主张是如果创业是投资自己的时间去迭代式地构建产品或服务以满足早起采用者的需求。他们可以降低市场风险并避免需要大量的初始项目资金和昂贵的产品发布和失败。
埃里克·莱斯定义了一个将新产品成功推向市场的科学方法。你可以在构建-度量-学习的生命周期中持续地进行小的调整以保持高速进步，而不是制定需要建立在非常多假设基础上的复杂计划 。
构建 – 度量 – 学习 是一个反馈环，它的目标是在循环中尽快验证你的想法。
你首先定义出最小可行产品（MVP），这个版本的产品允许团队以最小的付出进行最大程度的验证性学习。
构建 MVP 并发布到生产环境（持续交付）并度量运行时健康状态和产品的可用性（持续分析）
然后你可以使用对比测试和调查的方法让你的客户参与产品反馈中来。这为下一个循环提供了学习（持续反馈）的输入。
六、最小可行产品（MINIMAL VIABLE PRODUCT）
最小可行产品（MVP）的定义是这个版本的产品允许团队以最小的付出进行最大程度的验证性学习。
在整个周期中的每个迭代中，准确定义出MVP是团队想要成功实践这个方法必须要掌握的重要技能。范围太广会拖慢速率，范围太小又不足以在验证此次发布的周期中充分学习。
至少有一件事是肯定的，我们想要避免以激进的方式从上到下设计和实现一个大系统的方法。这种方法会导致巨石架构、延期、缺少对最终用户真实需求和期望的充分沟通以及因为大量的任务和向遗落战境不可避免的死亡行军丧失了开发生产力。
通过掌握定义最小可行产品的技能，我们可以实现有用且简单的产品，以便我们尽快让用户参与进来，获取反馈、验证我们的想法并且在撞到南墙之后快速失败。
比如，比想要验证微服务架构是未来项目的正确方向。不是每个人都相信并正在学习一个传统的巨石架构，但他们有兴趣看看这种方法是否有效。最小可行产品就可能是以一个或几个 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）
本文作者:龙井 来源:运维派
CIO之家 www.ciozj.com 微信公众号:imciow