精益软件开发连载（二）
原则
精益软件和系统社区似乎同意一些支撑精益软件开发过程的原则。
• 遵循系统思考和设计方法
• 突现的结果可以通过构建一个复杂的自适应系统的环境影响
• 尊重人（作为系统的一部分）
• 使用科学方法（推动改进）
• 鼓励领导
• 产生可见性（进入工作，工作流和系统操作）
• 减少流动时间
• 减少浪费提高效率
遵循系统思考和设计方法
这通常被称为精益文献中的“整体优化”，这意味着它是从整个系统（或过程），我们希望优化的输出，我们不应该错误地优化部分。大多数从业者认为推论是正确的，优化部分（局部优化）将导致一个次优的结果。
一个精益系统的思想和设计方法，我们需要考虑外部利益相关者，如客户所需的系统，以及这些利益相关者所需的结果。我们必须研究需求的性质，并与我们的系统交付能力进行比较。需求将包括所谓的客户愿意付钱的“价值需求”和通常是由于返工或额外的需求所造成的“失败的需求”。失败的需求通常有两种表现形式：先前交付的价值需求需要返工和额外服务，或者是由于未能提供价值需求而产生的失败。在软件开发中，失败的需求通常是要求修复缺陷和客户关心的或帮助功能的要求。
系统设计方法要求我们也按照计划-执行-学习-反应（PDSA）的方法来进行过程设计和过程改善。W•爱德华兹•戴明博士（W. Edwards Deming）用“学习”和“能力”这个词来说明我们研究系统行为的自然哲学。该系统包括我们的软件开发过程和人们的操作过程。它将对开发过程、质量、功能的数量或交付的功能数（参考敏捷方法中的字面意思“速率”）等方面进行观察。这些度量指标表现出的可变性，通过研究的均值和扩散的变化，我们可以形成一个我们的生产率。如果这些与需求和客户的期望不一致，那么系统将需要重新设计以缩小差距。
戴明还教导说生产率的影响因素中系统设计占到了95%，而个人效率的影响仅有5%。换句话说，我们需要尊重人，要想使他们能够成功，比起责备他们的能力差距还不如重新明确需求和重新设计系统。
要了解系统的设计，我们必须对系统内在功能，以及所受到的影响有一个科学的认识。模型的创建是用来预测系统内部的功能。虽然有很多可能的模型，但是几个比较流行的模型包括：经济成本的理解；与客户价值的产品或服务生产所谓的交易和协调成本；约束–瓶颈的理解理论；理论和渊博的知识–识别一般的系统设计或特殊项以及系统外在的设计的变化。
通过复杂适应性系统来影响不可预计的结果
复合的系统具有的启动条件和简单的规则是在迭代过程中产生一个不被预期而紧急的结果。这种不能够被预期的紧急的结果在启动条件中是很难被预估的。计算机科学实验“生命游戏”就是一个复杂系统的例子。一个复杂的自适应系统在它的一些自我意识和内部的反射方法中，使这个系统能够考虑如何以及使用其目前的规则而产生预期的结果。复杂的自适应系统可能会选择自我调整—改变其简单的规则—消除目前的结果和期望的结果之间的差距。生命游戏适应这样一个过程的变化，这样导致规则可能在玩游戏过程中被重写，这就是一个复杂的自适应系统。
在软件开发过程中，复杂自适应系统的“简单规则”是构成过程定义的策略。这里的核心原则是建立在相信开发软件产品和服务不是一个确定的活动，因此一个定义的过程，不能适应自己将不足以应对不可预见的事件。因此，过程定义为我们系统思维和设计方法的一部分，设计的过程必须是适应性强的。它通过修改策略来适应。
精益软件开发的看板方法利用这一概念，即把看板“拉动生产”的策越作为“简单规则”，利用系统动力学的理解将工作和工作流程可视化作为启动条件，组织管理使用科学的方法来理解、倡议和实施对过程的改善。
尊重一线人员
精益社区接受Peter Drucker对知识工作的定义，指出工人是知识工作者，他们比他们的老板更了解他们的工作。这就产生了一种暗示，即工人能做出如何执行工作以及如何改善流程以提高工作执行效率的决定。所以工人的声音应该得到尊重。工人应被授权通过自我组织完成工作并达到预期的效果。在精益文献中指出他们也应该被授权并给与参与过程改善或“改善事件”的机会。使过程政策明确，以使得工人知道约束他们的规则是尊重他们的另一种方式。自我组织需要通过明确定义的规则，鼓励通过消除恐惧和需要勇气来得以实现。尊重人并赋予权力，通过制定一套明确定义并符合核心价值观
政策来达到对人的遵守。
使用科学的方法
寻求使用模型来理解工作是如何完成的，以及精益软件开发系统是如何运行的。观察和研究系统及其性能，并开发和应用模型预测其行为。收集研究中的定量数据，并使用这些数据来了解系统是如何执行的，并预测在过程改变时它会如何变化。
精益软件和系统社区使用统计方法，如统计过程控制图和消耗时间和速率的元数据直方图分析了解系统的能力。他们还利用其它模型，例如：约束理论来了解瓶颈；使用深入的知识体系了解系统设计对其外部影响和内部影响；并分析了在提供对客户有价值产品或服务之后，通过协调、交付或者后续服务的完成所建立的经济成本形式。而且也使用一些其他的模型，如实物期权理论，旨在将金融风险管理的理论应用到现实世界的决策。
我们的研究表明：科学的方法；我们假设基于模型的结果；我们首先基于预测的系统；我们再观察看看干扰产生的结果的预测模型。如果不这样做，那么我们检查我们的数据，并重新考虑我们的模型是否准确。使用模型来推动过程的改进将它转移到科学活动中，并将其从基于直觉的迷信活动中提升出来。
鼓励领导力
领导力和管理不同的。管理是设计流程、创建、修改和删除策略与这个流程的相关活动，这些活动包括制定战略和业务决策、整合资源、提供财务和设施支援，并在上下文环境中传达战略信息、目标和预期成果。领导力是具有多种属性的，如愿景、战略、实践、勇气、创新、调整、宣传以及更多的属性。领导可以而且应该来自组织内的任何人。从工人对领导力细小的执行行为将创建一个级联的改善，这些改善将提供建立一个精益软件开发过程的变化过程。
产生可视化
知识工作是无形的。如果你看不见东西，那几乎是不可能去管理它的。有必要通过个人、技能和部门的网络，对正在进行的工作和工作流程产生可见性，直到工作完成。创造可视性的过程设计，通过寻找流程可视化的流程和政策的过程明确为大家看到和考虑是非常有必要的。当所有这些事情都是可见的，使得关于协作和客观改善的话题和采用科学方法管理成为可能。如果工作流和工作流是不可见的，并且如果流程策略不明确，那么协同进程改进几乎是不可能的。
减少工作流程时间
软件开发业内和研究软件工程的学者历来专注于测量在活动上花费的时间。精益软件开发社区发现，测量那些需要处理的活动所消耗的日历时间更有用处。这通常被称为循环时间，通常由活动的边界限定。例如，通过分析准备就绪的循环时间将测量工作项（如用户故事）的完成的时间，这些时间包括分析、设计、开发和用多种方式测试，并将任务队列中的任务项部署到生产环境中活动所花费的时间。
用不同的方式关注在过程中的工作项所花费的时间是非常重要的。较长的生命周期时间已被证明与非线性增长的错误率相关。因此更短的生命周期时间将获得更高的质量。因为当这些看似荒谬的代码在程序中时，没有人实际上检验过它们，这些代码极有可能导致缺陷。传统上，软件工程业内和研究它的学者忽略了这个空闲时间。然而，经验证据表明，生命周期时间对初始质量的质量是非常重要的。
Alan Shalloway还谈到了“诱导工作”的概念。根据他的观察，执行任务的滞后将导致比正常完成任务花费更多的时间和努力。例如，一个缺陷被发现并立即修复可能只需要花20分钟的时间来解决，但如果这个bug被修复，排队和等待修复的时间需要花费几天或者几周，但是修复缺陷本身仅需要花费几个小时。因此，生命周期时间延迟有“诱导”产生额外的工作。由于这项工作是可以避免的，在精益方面，这种情况必须被视为“浪费”。
关注生命周期时间的第三个原因是与业务相关的原因。每个功能或用户故事都有价值。这个价值可能是不确定的，但是都是有价值的。这种价值的概念可能随时间而发生变化。随着时间的推移，随时间变化的价值概念可以用市场回报函数来表示。当一个工作项的市场回报函数被人们理解，即使该函数表现出的价值模型具有不确定性，但是它可能被评估为一个“延迟成本。这种延迟成本使我们能够减少价值的周期时间。
随着一些工作项目的实施，直到一个已知未来日期到来之前市场回报函数还没有发挥作用。例如，一个被设计用于美国七月四日假期时使用的功能在这个日期到来之前是没有价值的。但是在这个例子中，缩短周期时间，和能够预测周期时间的一些确定性仍然是有用的。理想情况下，我们有必要启动工作，使这个功能能够及时交付；而不是在这个日期之前提交交付，但也不是延迟交付，因为延迟交付需要承担延期交付的成本。准时交付可以确保最佳的利用所需的资源。提前交付意味着我们可能已经做了其他的事情，并隐式的承担了可能导致延迟而产生的机会成本。
由于这三个原因，精益软件开发的目的是尽量减少工作流程的时间，并记录在工作流程中进行估算的时间。目的是减少因为缺陷导致需求失败、在修复缺陷上过分延迟而浪费的时间，以避免延迟成本和机会成本价值最大化延迟交付。
减少浪费提高效率
对于每一个具有附加值的活动，像启动、收尾和交付活动，但不增加其自身的价值。例如，一个项目中可工作的软件的增量需要计划活动（启动活动），一个环境，或者一个代码分支的版本控制（统称为配置管理和启动活动），一个发布计划和执行实际的发布（交付活动），一个给客户的演示活动（交付活动），也许一个环境清理或重新配置（清理活动。）在经济方面，安装，清理和交付活动的交易成本进行增值的工作。这些成本（或间接费用）被认为是浪费在精益。
任何形式的过度沟通都被认为是浪费。在经济学语言中通过会议确定项目状态、项目计划或为团队成员分配工作将被认为是协调成本。在精益思想中所有的协调成本都是浪费。精益软件开发方法通过团队成员托管的使用设法消除或降低协调成本，这些方法有短的面对面会议如每日站会和视觉控制如卡墙。
精益软件开发的第三种常见的浪费形式是错误需求。错误的需求是软件系统开发的一个负担。失败的需求通常会要求返工或重新组织工作形式而解决其导致的质量差的副作用。在软件开发中最典型的错误的需求形式是缺陷、产品缺陷和客户支持活动，而这些客户支持活动是由于未能使用期望的软件功能而造成的。与错误需求向关的增值工作的百分比，即错误需求通常被称为故障负载。用错误需求而导致的增值工作的百分比来衡量系统的效率。
增值工作相对于总工作的比例，包括所有非增值交易和协调成本，决定了效率水平。一个没有交易、协调成本和没有故障负载的系统，他的效率将被认为是100%。传统上，西方管理科学已经指出，增加工作的批量规模可以提高效率。通常情况下，随着作业批量大小的增加，交易和协调成本是固定的或略有上升。因此，批量工作更高效。
这一概念被称为“规模经济”，然而，在知识工作问题中，协调成本往往随批量大小呈非线性上升，而交易成本往往呈线性增长。因此，传统的第二十世纪效率的方法是不适合的知识工作问题，如软件开发。
这要求能够更好地专注于减少的开销，同时保持工作任务规模小以满足能够提高效率。因此，精益的方式是有效的，以减少浪费。精益软件开发方法侧重于快速、低成本和迅速计划方法，减少过度沟通，和有效的减少过度协调的机制，例如使用看板系统实现可视化控制。他们还鼓励自动化测试和自动化部署，以减少业务成本。为最大限度地减少环境的安装和拆卸成本的现代工具，如现代版本控制系统和使用虚拟化技术，也有助于提高软件开发中小规模任务的开发效率。
（连载二）