书评与访谈:the Scrumban [R]Evolution

在“The Scrumban [R]Evolution:Getting the Most Out of Agile, Scrum, and Lean Kanban”一书中，Ajay Reddy描述了什么是Scrumban，探索了其所依据的原则和理论，并展示了Scrumban是如何部署在组织内的。

你可以下载一份“the Scrumban [R]evolution”样本，对本书有个大概的印象。这些页面都是摘自这本新书，‘The Scrumban [R]Evolution:Getting the Most Out of Agile, Scrum, and Lean Kanban’作者是Ajay Reddy，由Pearson/Addison-Wesley Professional于2015年7月出版，ISBN 978-0-13-408621-7。欲了解更多信息，请访问出版社网站。

InfoQ有幸采访了Reddy，主要关于Scrumban的起源，如何使用Scrumban提高Scrum的能力以及如何使用Scrumban支持敏捷实施，Scrumban的每日站立会议与Scrum中有何不同，时间盒和连续流，如何使用Scrumban规划和跟踪工作，度量质量，和从Scrumban角度看管理和领导。

InfoQ：什么使您决定写这本书？

Reddy：企业启动敏捷转型计划，以解决各种需求——对不断变化的市场有更快的响应，围绕着开发计划可以获得更大的可预测性，等等。
通常他们聘请顾问，引导他们走上一条激进的，大的变迁路径。首先他们会试点几个“敏捷团队”，展示一些初步成果，但是，试点之后要想获得更广泛的成功通常并不容易。

从这则故事中，我看到了自相矛盾的地方。成功的敏捷转型，其主要目标之一是创造专注于小批量交付价值的文化。然而，因为企业本身从事的是大型的批量任务，所以在寻求成果的过程中，会攻击转型的努力。他们为自己做了失败的打算，然后不断地攻击由此产生的不信任，这种不信任给所需的变革带来了相当大的阻力。所有的这些组织最终实现的都是短暂的‘成功’，并意识到cargo cult实施很注重敏捷术语。反过来，这又成了精益、敏捷和Kanban社区部落和狂热信徒兴起的催化剂。

我见过可持续的成功曾经发生在这种组织内，它们强调正确的价值观，正确的原则，系统思考，企业家思维和经验，保证思想与行动的一致性，并推动了一系列并行的渐进性变革。Scrumba是一种框架，帮助团队和组织把重点放在成功准则上面，但是很少有人能够认识到这种框架的本质。事实上，我认为人们对它的误解比理解要多得多。我写这本书，旨在帮助人们扭转这种状况。

InfoQ：这本书的受众是哪些，他们能够从中学到什么？

Reddy：这本书受众广泛。精益-敏捷顾问和教练将会发现本书内容丰富，横跨各种各样的问题，从理解Scrumban所依据的基础科学和原则到扩充他们的知识，如何帮助团队和组织获取和应用度量指标，在工作和持续改进努力中做出更好的精明的决策。

同样，IT工作者，管理者和高层领导将会学到，为了在市场上获得实际的成果和真正的敏捷，为什么它比简单的学习和采用特定的实践需求更多。在书中我已经指出了在哪些特定的领域，有效的管理和领导对实现高性能和改进成果至关重要。更重要的是，我试图为开发和培养不同级别的有效的管理/领导技能提供了实用主义的指导。

最后，然而本书的一个根本目的是提供对环境全面、整体的理解——理解“为什么”和提高选择意识，这样人们都可以领会简单地将某种实践落实到位并不一定能够提高性能。

InfoQ：您是如何定义Scrumban的，能够详细解释一下它的起源吗？

Reddy：Scrumba既是一种理念体系，又是一种管理框架。

虽然Scrumban大多起源于Scrum和Kanban方法，但是它并不是这两种框架的混合（对此声明更多的了解，请查阅Agile，Scrum and kanban 101）。

Scrum的根源告诉我们，如何构建自组织团队，揭露组织的功能障碍，并管理复杂的任务。Kanban的根源使我们能够获取和综合信息，从根本上为我们的产品和服务，以及为生产这些产品和服务的流程做出更明智的决策。附加原则来自对其它管理科学根深蒂固的理解。

自从Scrumban被杜撰出来发展至今，它在3个基本面证明了其价值：

1. 作为将Scrum引入团队和组织的框架；
2. 作为在企业内大规模实施Scrum的框架；和
3. 作为采用Scrum更好地识别、理解和克服组织内不能很快或轻易改变的功能障碍的框架。

InfoQ：您能给出了一些例子，Scrumban是如何提高Scrum的性能的吗？

Reddy：作为一个敏捷框架，Scrum旨在帮助人们在做出承诺和可靠地履行承诺时充满自信。有时间限制的Sprint机制和团队评估技术都支持这些成果，但是往往不能在企业环境中很好地扩展（因为相互依赖项不能很快消除，并且很难以有意义的方式来综合主观评估技术）。

我们在Scrumban框架内构建的流系统支持同样的成果，但是在所承担的工作范围内，通过在多个团队之间提供了统一的度量指标这种实现方式，可以带来了额外的好处,对固有的变化范围更深入的理解。  

举例来说，考虑这样一个场景，多个Scrum团队都投入到一个重点任务的开发工作中。在评估过程中，无论团队变得如何能干，评估技术仍然是一个主观的、前瞻性的方法，只与自己的团队相关和有意义。所以当五个Scrum团队使用同样的评估技术为同样的故事分配五个不同的评估值时，一点都不需要惊讶。尽管每个评估值都能够正确形容每个团队的目标，但是，实际上这些独立的评估值最终是否包含了同样的时间和同等程度的工作量，对于外面的任何人而言不是那么的显而易见。

在Scrumban中，团队仍然可以使用同样的评估技术，但是他们可以根据他们的历史性能，增强对他们工作的认识。交付时间——工作从开始到完成所需的时间量——可以绘制成图，反映团队的分布格局。将这些额外视图纳入团队工作,提供了许多的优势。  

从团队的角度来看，他们对他们历史交付变化的程度开始有了更好的认识。他们可以探索其中的某些变化是否与其它因素有关（工作类型、与工作相关的风险属性，等等），可以在对他们历史性能有一个出众认识的基础上管理他们的评估值和Sprint规划过程。

从组织的角度来看，通过使用时间单位，你可以跨团队拥有统一的性能度量指标。并且这些度量指标能够轻易地被敏捷实践者和非技术人员理解。在与客户或者利益相关者，围绕设定预期值或者权衡得失做出明智决定进行有意义的交流时，可以用更可靠的概率预测和规划技术更好地支持你的观点（实际上，预测和规划技术可以相当的复杂，例如参见#noestimates Project Planning Using Monte Carlo Simulation）。

InfoQ：已经有许多不同的方法可供组织实施敏捷。Scrumban是如何支持实施敏捷的？

Reddy：正如我前面提到的，Scrumban的独特表现之一就是帮助团队和组织实施Scrum。一般这种能力可以延伸到精益和敏捷思维的实施。

探索和实施新的工作方法的行为通常是一次难以忘怀的经历。在这个过程中需要掌握很多新的信息，并且新的方法常常需要克服多年来形成的体制制度上的惯性，比如事情应该如何做，和人们如何看待事情应该如何做。另外,请不要在意情感和心理上变化的影响。因为所有这些原因，发现大量正确的信息和实践，按部就班地引进，往往是全面成功的关键。

作为一个框架，Scrumban简化了形成新习惯和思维方式的挑战。与立即引入新的角色、事件和实践相比，我们更加专注于发现和明确组织和团队不满的来源。我们引入非常有限的新实践（比如可视化工作和构建稳定流系统），这种方式增强我们这么做的目的,帮助团队深入地理解他们目前工作的方式。从这些理解中，团队将会提出Scrum原则和实践,作为解决他们共同希望解决的具体挑战的方案。与被某种方法训练和被告知如何实施敏捷相比，在过程中以这种方式实施敏捷，提升了团队更强烈的主人翁意识。  

InfoQ：您能否解释一下，Scrumban中的每日站立会议于Scrum中有什么不同？

Reddy：传统的Scrum站立会议往往专注于状态。
团队的每个成员陈述他们最近工作的内容，打算工作的内容，和识别任何已知的障碍，从而完成工作。

在Scrumban中，工作的状态应该由可视化的Scrumban看板明确展示出来，所以团队成员没必要叙述他们的工作。团队成员仍然可以负责完成工作，但是这种责任是通过参与集体关注工作流程而执行的。谈话围绕着项目几乎完成时，我们如何完成交付，或者这个项目没有任何进展，什么阻止或者妨碍了项目的进展。描述不同的另一种说法是关注工作流程，而不是关注个别员工或者关注他们正在做什么。

InfoQ：Scrum建议固定sprint时间，而Kanban则重视连续流。在Scrumban里是如何对待时间盒和交付流的？

Reddy：首先，我要强调一下，虽然在使用Kanban和流系统管理他们的工作的团队中间，持续流已经成为一个普遍的结果和实践，但是这种框架本身并没有将持续流规定成一个结果或者实践。它强调的是促进和管理工作的顺利进行，并且这种结果可以在类似Sprint时间盒的环境中实现。

也就是说，在许多环境中使用固定时间方法（time-boxed approach）必须解决几个独特的难题。有时，一个团队承担的工作性质导致不能简单地将其切割，使其满足给定的时间盒的限制。这时你就会看到团队会人为地将工作切割成不合适的组块，仅仅是为了使切割后的工作块适合方法论，而不是按照业务需求交付价值。有时，在一个同步的节奏上将验收工作与交付工作紧密结合是没有意义的。例如，如果你在一个快速变化的市场中运行，即使是两周一次的交付和反馈节奏对真正的敏捷而言也是嫌长的。

Scrumban同时支持时间盒和持续流。更重要的是，它迫使团队遵循规范性的方法，在数据驱动洞察的基础上决定那种方法是最好的。

案例演变

(点击图片放大)

(点击图片放大)

(点击图片放大)

InfoQ：您能举一些例子，如何使用Scrumban规划和跟踪工作？

Reddy：在我回答你的问题Scrumban如何提高Scrum的能力时，我已经提到了一些。概率预测技术是我最青睐的，通过流系统的使用有可能实现这种技术。

最近我正在使用一种叫做随机分支抽样（Randomized Branch Sampling）的技术实现相关的功能（参见Project Sizing Using Randomized Branch Sampling (RBS)和Improving Sizing）。简单地说，这种方法采用了某种技术，而这种技术起源于园艺（一语双关）。这种方法在预测大型项目范围时更加可靠，并且无需投入大量的时间和精力，分析所有的预期工作。如果你有兴趣参与RBS这项研究，你可以在www.CodeGenesys.com和www.ScrumDo.com呼唤我的团队。

InfoQ：在您看来，度量质量重要吗？您能否解释一下，它是如何实现的？

Reddy：质量定义为：从客户立场出发，看产品或者服务是否符合客户的目的。

但是，我们经常看到花哨的仪表板，用来跟踪深奥的度量指标，而这些度量指标只是从客户的角度略微地度量了是否符合客户的要求。

作为一个框架，Scrumban强调用科学的方法和在数据驱动的基础上进行决策，它没有规定度量内容。团队做的每个决策——可视化哪些工作，如何可视化这些工作，采集哪些度量指标——应该由解决利益相关者或者团队不满来源这种团队的需求驱动。

所以，如果质量已经成为利益相关者（或者甚至是团队）需要解决的问题，那么采集和评估质量度量指标肯定有意义。

分别确定、可视化和度量团队承担的所有的返工这些方法可以做到度量质量。相对于通过系统的其它工作，返工率是多少？另外一项措施是识别缺陷或者返工的原因，找出这些原因的总体趋势。度量指标的总类有很多种，在集中解决不满来源期间，团队可能在不同的时期将其从不同的度量指标中隔离出来，解决不满来源才是他们改进工作关注的焦点。

因此，只有我们度量的内容或者何时度量违背了顾客明确或者期望的参考时，它才重要。

InfoQ：您能简要介绍一下，Scrumban对管理和领导力的看法？

Reddy：如果我不得不将其浓缩成一句话，领导和管理有效的参与为组织内的人们提供了一个明确的概念，未来组织将往哪个方向发展（一个清晰的愿景），并设置了明确的界限，在其中人们可以自由发挥他们集体的主动性。  

为了这个目的，有效的领导就是确保正确的事情能够完成——不管它是正确的工作，还是为前后一致的决策培养所需的对齐的价值观。有效的管理是通过培养或者开发有效的实践加强这些东西。

关于作者

Ajay Reddy已经花费了十多年的时间帮助团队和组织提高他们的工作方式。他的研究强调一种亲身实践的方法、协作试验、证实业务成果，提高团队满意度。作为一名软件工程师，发现了敏捷方法之后，他转向指导组织机构。Reddy在2009年成立了CodeGenesys，是一家小型Lean-Agile咨询公司。在2010年，他参与创办了ScrumDo.com，提供基于云计算的项目管理工具，以便更好地促进Scrum和Kanban的实现。作为管理负责人和产品owner，他帮助了145个国家的团队发现了Scrum的效益。他还参与创建了GetScrumban.com游戏，帮助人们发现Scrumban的功能。他在the United States， India和Europe讲授Scrumban，并且是Scrum and Kanban meetups events的定期演讲者。Ajay Reddy已婚并育有四个孩子。它的Twitter： @ajrdy。

查看英文原文：Q&A on the Scrumban [R]Evolution