1. 消除浪费 Eliminate Waster
- 客户不需要的额外文件;
- 不同角色之间的转换，如分析师到开发人员，开发人员到测试人员和测试人员到发布管理团队;
- 代码中不必要的特性和复杂性(缠结、循环、紧密耦合、高圈复杂度;)
- 未测试、构建和集成的代码;
- 审批和签字等流程中的障碍;
- 无效的会议，比如没有明确议程、没有预期结果、没有时间限制的会议
- 缺陷和其他可见的质量问题;
- 管理开销，如状态报告;
- 在多个项目上分配资源，并在它们之间来回切换;
-
2. 强化学习 Amplify Learning
价值流图的概念，强调识别和消除浪费不是一次性的活动。这是团队始终追求的一项持续的活动。在客户需求不断变化且优先级可能发生变化的情况下，一开始就做好的方法可能无法奏效。因此，精益文化体现了一种不断学习和寻求改进机会的实践。软件开发人员的最终目标是发现客户的需求，并设计一个解决方案来交付相同的需求。
- 正如我们在Scrum和XP中看到的，生成代码和测试代码是否符合需求的简短迭代有助于在这个持续学习过程中发挥作用。这不仅有助于获得早期的反馈并相应地进行重构，而且还使团队有机会反映并使他们的过程更加有效和高效。另一种扩大学习的方法是进行简短的实验或峰值，以减少风险或不确定性。
精益管理者避免任何形式的微观管理，比如分配任务和跟踪任务。相反，他们与团队成员一起工作，指导他们，支持他们的学习旅程，鼓励他们自己解决问题。
3. 尽可能晚决策 Decide as late as possible
精益遵循的是所谓的及时计划，因为当需求预计会发生变化，而对最终结果的可视性不足时，详细的项目计划和提前承诺会被认为是浪费时间和精力。
- 精益希望将承诺和决策推迟到最后一个负责任的时刻，这样团队就可以从最大程度的敏捷中获益。这与我们在前一章中提到的敏捷宣言及其原则是完全一致的。
精益思想避免过早地做出不成熟的决定，因为它们将团队限制在技术约束的解决方案中，或者浪费时间来保持计划的更新以适应变化。考虑到SDLC期间变更的不断增加的成本，这是一项工作密集型的工作——其中大部分对客户产生的价值很少或可以忽略不计。相反，它以一种允许变更的方式进行计划和设计，这样团队就可以迭代地适应和重构一个复杂的系统，并响应客户的需求。所采用的一些技术是使用抽象、代码的模块化、避免代码中的重复(也称为DRY—不要重复自己)以及使用广度优先而不是深度优先的方法来解决问题。
4. 尽可能快交付 Deliver as fast as possible
考虑到一个快速变化的环境，概念和消费(生产中的系统价值)之间的延迟越长，就越有可能偏离客户的需求。通常，产品或功能交付的速度(当然还有质量)对获得的收入、竞争优势或客户在市场上的声誉有很大的影响。
- 精益遵循快速灵活流程的原则。通过在小的迭代中交付，精益团队希望将可工作的软件交付给客户，而客户则希望以递增的方式实现价值(而不是在一个很长的项目周期结束时)，并向团队提供反馈。这个反馈扩大了团队对领域和客户更好的需求的了解，并计划在下一次迭代中合并。
- 另一个使交付更快的因素是使用基于拉动系统概念，这意味着系统只在客户需要时才产生。因此不存在等待消费的物品库存。与Scrum不同的是，精益团队不会在“冲刺”开始时就承诺使用一组故事。相反，他们希望在完成前一个任务后再接一个任务。这有助于减少正在进行的工作(正如我们看到的，这被认为是一种浪费)和任务之间的上下文切换。而且，根据利特尔定律，7降低在制品数量有助于最大化整个系统的流量(和吞吐量)。
顺便说一句，当我们使用“快速”这个词时，保持可持续的速度是很重要的，XP中也迭代了这个值。
5. 授权团队 Empower Team
精益是一种以人为中心的哲学，它尊重工作中的人，允许他们采用和适应工作方式，最大化价值并寻求持续改进。与指挥风格在传统的项目管理中,这一原则在精益是基于这样一个前提：一群活力和内在动力的工人,谁有权做出决定,最终问责制的产品是最适合项目的技术决策。这些人积极地交付价值，消除质量问题，重构设计和代码，提出新的想法，并在适应和持续改进的文化中茁壮成长(也称为Kaizen)。现在，领导者的角色转变为设定总体方向，将人们与一个共同的目标联系起来，激发积极性，并给予团队成员选择合适工作的权利。
6. 构建完整性 Build integrity in
这一原则中有两种完整性。
- 一个是感知到的完整性，即客户如何体验系统并平衡诸如可访问性、可靠性、经济性、易用性和适用性等质量。例如，考虑一下程序员常用的一些流行编辑器(如Eclipse)，它们非常容易用于连接到版本控制、启动构建、执行自动样式化，甚至在输入和编译之前通过突出显示和自动纠正错误来提高生产率。最重要的是，这是免费的!
- 另一种是概念上的完整性，即系统的组件如何耦合在一起，从而导致灵活性、可维护性、可扩展性和感知到的完整性方面。例如，今天的智能手机可以作为手机、相机、音乐播放器和GPS导航，这对我们来说是一个很大的满足和方便的问题。所以一个人不需要依赖或携带多个设备。
实践，如短迭代中的增量交付、简单和紧急的设计、设计和代码的重构、测试优先的开发、编码标准、单元测试、自动化测试、持续构建和集成，都是这一原则的推动因素。
7. 全盘检视 Optimize the Whole
如果我们考虑组织环境，精益可以应用到许多层次。这些级别可以从产品、销售、营销、业务社区、技术团队、基础设施和管理——精确地说，企业中为最终用户提供解决方案的任何人。因此，精益鼓励系统思考。它从始至终关注整个系统——它的各个部分如何相互集成，以及如何不断改进。
- 在构建技术组件的同时，要牢记大局和客户焦点。重要的是，每个团队成员都要关注整体系统性能，而不是局限于他们拥有的专业技能，如Java编程、Oracle数据库开发或用户界面设计。同样，在系统的某些部分由不同的团队构建的情况下(让我们考虑一下承包和分包的情况)，重要的是整个团队都要遵守这个原则，相互信任，理解系统的核心目的，并在与系统或其客户的任何形式的交互过程中嵌入这种思维过程。引用Poppendieck的话:“想大，行动小，失败快;“快速学习”是非常重要的。
若有收获，就点个赞吧
0 人点赞
