读《学习敏捷构建高效团队》笔记7

第8章 精益、消除浪费和着眼全局

精益是一种思维方式，是一种世界观。

——Mary Poppendieck，Tom Poppendieck，The Lean Mindset: Ask the Right Questions

如果你每天参加每日例会，使用冲刺，并与产品所有者和Scrum主管一起工作，那你就是在使用Scrum。对极限编程也是一样：如果你不断重构，使用测试驱动开发，持续集成并且进行增量式设计，你的团队就正在使用极限编程。

如果你不理解集体承诺和自组织，你就没有理解Scrum，而Scrum的价值观正式帮助你理解这两点。同样，在极限编程中：不理解简化和精力充沛的工作这些价值观，你最后不过是把极限编程的实践当做一个清单，你的团队不会真正拥有变化，而你最后得到的还是难以维护的复杂软件。

8.1　精益思维

精益的价值观包括以下这些：

• 消除浪费

  找出那些不能直接帮助你创造出有价值软件的工作，把它们从项目当中去掉。

• 增强学习
  通过项目的反馈来改进你开发软件的方法。

• 尽可能延迟决定
  每一个项目的重要决定都要等到你拥有了最大量信息的时候再做，也就是在最后责任时刻。

• 尽快交付
  理解延期的代价，并且通过拉动式系统和队列来将这种代价最小化。

• 帮助团队成功
  创建一个专注而高效的工作环境，创造一个由精力充沛的人组成的团队。

• 保证产品完善
  软件应该符合用户直觉，并形成一个一致的整体。

• 着眼全局
  全面理解项目中的工作——使用恰当的衡量指标来保证你了解全局，毫无遗漏。

一个组织更加珍视什么，它就最终得到什么。在我们把价值取向从过程转向人、从文档转向代码、从合约转向合作、从计划转向行动的过程中，敏捷宣言起到了很大的促进作用。

——Mary Poppendieck，Tom Poppendieck，《敏捷软件开发工具》

要点回顾：

• 精益或精益思维是一种思维方式，与其他敏捷思维方式一样，它也有一些价值观可以帮助你理解和适应它。

• 精益是一种思维方式，而不是一种方法。这也是为什么它没有可供你用到项目开发中的具体实践。

• 精益思维与更广义的敏捷开发有一些共同的价值观：“尽量推迟决定”（或者在最后责任时刻做决定）和“增强学习”（使用反馈和迭代）。

• 帮助团队成功这一精益价值观与 Scrum 的专注和极限编程的精力充沛的工作十分相似。

• 选择思维的含义是理解选项与承诺的区别，并且尽量给你项目的未来留出尽可能多的选项。

• 使用集合式开发的团队会同时探索多个选项并从中选出最好的一个，像 A/B测试中在一个用户样本上测试多个用户界面选项并选择最佳的那些特性。

8.3 创造英雄与神奇思维

很多现实生活中的敏捷团队反复地看到，改进团队协作和创造健康而放松的工作条件能够帮助开发出更好的软件。

精益试图去除那些虚妄，并帮助团队共同协作，思考如何创造真正的价值，而不会单纯的蛮干。

8.4 消除浪费

如果你习惯于不断“重构”运作项目的方法，你会得到一个更加灵活而能干的团队。

对于开发团队来说，也许看起来并没有花太多的时间等待计划被批准，因为它很可能在等待的过程中正在开发另一个功能。但是需要使用该特性的客户并一定清楚开发团队的优先级安排。而且，说实话，他也根本不关心，他只知道，他要求的功能从开发到交付一共经历了71天。

要点回顾：

• 相信团队能够做到不可能的事情，并且忽略现实世界的限制和项目的实际情况，这种思维就称为神奇思维。

• 精益团队消除浪费的方法是：找出那些对开发一个有价值的产品没有直接贡献的活动，并移除它们。

• 任何不直接为项目创造价值的活动都是浪费，精益团队致力于发现这些浪费，并尽可能将其从项目中消除掉。

• Mary Poppendieck 和 Tom Poppendieck 提出了软件开发的七种浪费：做了一半的工作、多余的过程、多余的功能、任务切换、等待、移动和缺陷。

• 保证产品的完整性是另外一个精益价值观，它包含感知完整性（即产品多大程度上满足了用户的需求）和概念完整性（即产品的各项特性多大程度上能够有机地结合在一起）。

• 精益的思维方式帮助团队着眼全局 ，客观理解团队的工作方式，包括其中的问题；量化指标 能够帮助你对你的项目和团队有一个客观的看法。

• 尽快交付意味着去除那些延迟你的工作和导致瓶颈的无用活动。

怎么才能知道你是否做到了尽快交付呢？

精益思维可以回答这个问题：使用量化指标。一个衡量你的团队是如何交付有价值产品的有效方法是使用工作进度面积图（work-in-progress area chart），简称为 WIP 面积图。这是一个简单的图示，它显示了最小可销售特性是如何在你的价值链条中向前推进的。

如果你创建过一个价值流示意图，那么你就可以创建一个工作进度面积图，后者用于表示特性、产品和其他价值指标是如何经过价值流的每一个环节的。这种方法最适合于使用MMF，因为后者代表了最小的价值单位。

要点回顾：

• 最小可销售特性是指团队可以交付的最小的“一块”价值或功能，比如一个用户故事或一个用户请求，就是最终可能进入产品所有者的积压工作表的东西。

• 价值流示意图是一个可视化工具，它通过展示一个 MMF 的整个生命周期（包括每个阶段工作和等待的时间），来帮助精益团队看到其项目是如何进行的。

• 理解问题的根本原因帮助你着眼全局；在这方面，五个为什么技巧十分有效。

• 一个可以帮助你的团队做到尽快交付的有用工具是工作进度面积图，它是一个可视化工具，可以展示出 MMF 如何经过项目的整个价值流。

• 有三种约束你的工作流的重要浪费：Muda（徒劳无益的事）、Mura（不均衡）和 Muri（不合理或不可能的事）。

现在就可以做的事:

• 找出你项目中的所有 MMF。你们是如何管理它们的？你们是否将用户故事写在卡片或即时贴上，然后把它们贴在任务板上？还是在规格文档中对它们有独立的需求说明？找出一个较大的功能或故事，看你是否能把他分解成小块。

•  在你的项目中寻找浪费。把你发现的 Muda、Mura 和 Muri 的例子写下来。

• 从你的项目中那些已经完成的 MMF 中随便拿出来一个，给它制作一张价值流示意图。试试看能否让你们整个团队一起做这件事。然后为另外一个 MMF 也制作一个价值流示意图。这两个价值流之间有什么相似之处？又有哪些不同？

• 找到你的团队经常碰到的一个瓶颈。（在这里价值流示意图会很有用）跟你的团队讨论一下，看看要在未来避免该瓶颈，你们可以做些什么。

• 看一下你和你的团队目前承诺的交付日期。你们是不是真的作出了承诺？有没有其他的选项，可以交付一些不同的东西，但依然兑现你们的承诺？

教练技巧:

• 软件团队中的大多数人以前没有遇到过给思维方式起名称的。

• 精益思维最为困难的地方之一就是要对谈论浪费感到适应。不过就帮助团队学习发现浪费（尤其是对不合理、不可能这两种浪费）这一点来说，开个“批评会”还是有帮助的。

• 要想让针对浪费的讨论保持一个正面的基调，你可以帮助团队成员找出下面这样一些情形：某一事项从“项目”的角度看是浪费，但对于“公司”来讲却是不可或缺的。

• 作为教练，你工作的一个部分是避免开发团队与公司之间产生摩擦。

• 另外一个保持正面积极氛围的方法是，帮助团队和经理两方把工作流程与该流程中的人区别开来

敏捷系列文章：

读《学习敏捷构建高效团队》笔记1

读《学习敏捷构建高效团队》笔记2

读《学习敏捷构建高效团队》笔记3

读《学习敏捷构建高效团队》笔记4

读《学习敏捷构建高效团队》笔记5

读《学习敏捷构建高效团队》笔记6

 

打造敏捷团队

看板方法-什么是看板方法

实施看板方法

我们怎样实施敏捷？

我们的站立会有问题！！！

谈谈code review