推荐阅读 | Jeff Sutherland论文：Scrum + CMMI —— 从优秀到卓越Scrum and CMMI 作者：Jeff Sutherland, Ph.D. ，Carsten Ruseng Jakobsen 编译：郭玲，王蕾 审校：高山，任甲林 原文： https://www.computer.org/csdl/proceedings-article/agile/2009/3768a333/12OmNx8wTpG 译者序： “当CMMI与Scrum相遇时，CMMI可以变得很敏捷，Scrum也可以流程制度化。合理的度量元加上优秀的敏捷实践让Scrum和CMMI双剑合璧，所向披靡。 ” ——敏捷实践者，郭玲 ““Are you ready-ready to be done-done？" 控制好Sprint的入口和出口，能使生产率翻倍！希望这句话能作为我们相见的暗号。 ” ——敏捷教练，ScrumInc官方认证 中文讲师，王蕾 前言
敏捷和CMMI结合的项目包含了适应性和可预测性，可以更好地满足大型客户的需求。 CMMI 5级公司Systematic在引进Scrum之后，通过关注前期测试和修复时间，相较2006年使用瀑布模型的项目，生产率提升到原来的四倍，并把缺陷降低了40%。Systematic在所有项目中把Scrum制度化，并使用数据驱动工具，比如用故事流程效率（Story Process Efficiency），来展现产品Backlog的障碍。两个团队达成了可持续的4倍于瀑布项目的生产率。此文我们将介绍让整个公司都达到这个水平的策略。 我们的经验显示，在项目缺陷发现的当天立即修复时，他们的生产率翻了一倍；当他们使用数据驱动工具可视化展示待办列表中的障碍，并定义完善的检查单时，他们的生产率又翻了一倍。 经验表明，Scrum和CMMI结合在一起，带来了比单独使用任何一种方法更强大的适应性和可预测性。 介绍
通过对Systematic公司Scrum实施的观察与分析， 研究者发现在执行Sprint和维护待办列表之间找到一个正确的平衡点对于团队的成功至关重要。 Scrum是一个迭代的，或者说是经验型的开发模式，也就是说它的计划是一个与开发活动同步的并且是一个持续的过程。所以，通常意义上，我们可以把Scrum看做是同时执行两个过程：“执行Sprint”过程和“准备待办列表”过程。随着团队在“执行Sprint”过程中越来越成熟，它们的速度就会增加，从而也促使“准备待办列表”过程也必须得越来越快。 背景
Systematic公司成立于1985年，在全球拥有500多名员工，在丹麦、芬兰、美国和英国设有办事处。它是一家独立的软件系统公司，专注于信息和通信系统内复杂的IT解决方案。通常，他们负责的项目都举足轻重，并且在可靠性、安全性、准确性和可用性上都有非常高的要求。 Systematic于2005年11月11日使用SCAMPI方法进行评估符合CMMI 5级。在2006年Systematic公司采用了Scrum和基于故事的软件开发方法，取得了非常积极的效果。从而也证明了Scrum可以跟CMMI的过程很好地融合。 在大约六个月的时间里，Scrum在Systematic公司得到了制度化的实施。第一次Scrum试点于2006年6月结束，到2006年底，大多数项目都采用了Scrum。在此期间，Jeff Sutherland参与了Systematic公司的管理研讨会，并培训了首批32位Scrum master。 从CMMI的角度来看，Scrum是用于执行项目的一系列过程中的一个过程。在CMMI体系中，为了了解效果和效率，要监控所有的开发过程。因此，也建立了关于Scrum的度量元。 度量元的选择
度量元的选择受到了精益思想和致力于建立稳定工作流程的启发。 度量元的选择
基于以上考虑设定的度量元
这些度量元在2007年初在一个业务部门内得到了实施。为了能很好地采集缺陷修复时间的数据，他们为所有的项目统一了编译环境架构，让这些数据能够自动地获得。关于故事的流程效率度量元，他们设定了一系列标准的检查表，让所有的完成故事的开发人员都能按照它来执行。 Systematic公司在其所有的项目中设定了以下目标：
所有项目最初都没有达到这两项目标，但都承诺继续朝着这些目标改进。2008年8月，将其中两个项目的生产效率与其他项目进行系统比较，结果显示两个项目的生产效率分别比平均水平高出140%和360%。 这两个试点项目均使用COSMIC方法来度量规模，通过对这两个项目的分析和访谈，我们发现：
其中一个项目是固定价格固定范围合同，另一个是时间材料合同。 这两个项目数据显示了修复缺陷的平均时间是1.9小时，最多7小时。并且故事的流程效率从2008年初的32%提升至2008年底的59%。 数据驱动的障碍识别
这两个项目利用这两个度量元来系统性地识别妨碍团队每个月向客户交付高质量的可工作软件的障碍。他们采用CMMI的原则并且用统计过程控制技术来分析这两个度量元， 这些技术能帮助我们理解度量元自然的波动，并帮助他们专注在影响最大或者是由特殊原因造成的偏差。在系统性地逐步解决了造成偏差的原因之后，这两个项目都拥有了能在每个月的的最后两个工作日内完成测试和发布的能力。 从这些项目中得到的经验是，建立什么样的心态来消除缺陷是非常关键的。精益的思维方式建议在缺陷被识别之后立即处理它，而不是将缺陷滞留起来以后再修复。如果一个缺陷或问题在被识别之后没有立即被处理，那么返工就会累积，并且很难交付一个高质量的Sprint并保持一个高速度。在2006年引入的故事流程效率检查表，可确保在开发故事时，兼顾故事的可测试性。该检查表促进了个人自查，提高了故事质量。 修复缺陷的时间
管理部门会定期收集修复时间数据并进行统计过程控制分析，与项目经理一起进行月度项目评审。通过系统的数据分析，帮助项目识别了异常情况并进行异常分析，建立对策，从而避免异常再次发生。下图显示了在一个项目上修复缺陷的时间，平均时间为1.6小时，上限为7小时。
该图显示了一个数据点超过了上限时间7.5小时的控制限制。对于超过上限控制线的每个数据点，将询问是否存在特殊原因。判断原因是否特殊，是否可以消除，或者原因是否应该预先预料到。如何对原因进行分类并不是最重要的部分。真正重要的是系统地处理这些数据点，并帮助解决障碍和思考如何消除这些障碍。 例如：通过分析识别到的一些障碍可能是：
这些障碍在被识别之后都被项目组或者管理层处理掉了。
一般的经验是，异常值通常是由问题引起的，如果不解决这些问题，就会给未来的Sprint带来障碍。“缺陷修复时间”这个度量元能很好地保证障碍可以被及时识别和解决。 故事的流程效率
这两个项目在2008年一直关注于流程的度量，并且他们明白为了在sprint中建立良好的流程，产品待办事项列表必须持续地维护，并在Sprint交付的同时进行。 这两个项目都有过这样的经历：当速度提高时，对于产品待办事项列表的关注也需要相应提高，以便为即将到来的sprint做好准备。当项目被问及如何将其项目的高绩效转移到其他项目时，他们建议使用以下检查列表来巩固和完善产品待办事项列表。
Systematic公司使用一个故事完成清单来定义故事的完成准则。从完成准则得到启发，Systematic公司又引入了就绪准则，来表示产品待办事项列表中的工作已经得到了充分地描述，可以分配到Sprint中。就绪准则和完成准则都支持产品负责人和开发人员分别使用的检查表。 确保产品待办事项列表被持续地维护，并在分配给Sprint之前充分地描述，当在此期间度量故事流程效率时，其效果是明显的。假设一个故事估计需要3个工作日的工作。然而，由于各种原因，实现这个故事实际花费了9个工作日。这个故事的流程效率为3/9或33%。当我们开始度量流程效率时，它大约是30%，从2007年到2008年第四季度增加到59%。高效的流程消除了与上下文转移和移交相关的浪费。此外，团队成员认为更令人满意的是，Sprint中的任务被充分地澄清并顺利实现。
结论
确保产品待办事项列表被持续地维护，并在分配给Sprint之前充分地描述，当在此期间度量故事流程效率时，其效果是明显的。假设一个故事估计需要3个工作日的工作。然而，由于各种原因，实现这个故事实际花费了9个工作日。这个故事的流程效率为3/9或33%。当我们开始度量流程效率时，它大约是30%，从2007年到2008年第四季度增加到59%。高效的流程消除了与上下文转移和移交相关的浪费。此外，团队成员认为更令人满意的是，Sprint中的任务被充分地澄清并顺利实现。同时使用CMMI和Scrum可以在保持在符合CMMI遵从性的同时，显著提高性能。Scrum将每一类工作(缺陷、返工、所需的总工作和过程开销)减少了近50%。Systematic公司目前的战略是将所有类别的工作减少75%，并且已经通过少数团队实现了这个目标。这种成功需要在公司制度化。 当精益文化辅以纪律严明的方法、技能精通的员工以及优秀的领导力时，可以通过使用以统计数据分析为基础的CMMI 5级技术，系统化地提升敏捷速率和质量。系统是可以被度量的，数据可以让学习的效果加倍。但是得小心在这个过程中要注意人的因素，因为如果不能很好地利用这些数据，反而会带来效率的降低。 在系统提升的道路上是没有尽头的！我们下一步的目标会专注在培养跨职能的团队和找寻团队的动力上面。在一些实施了Scrum模式的世界级的公司里，很多Scrum团队已经实现了超出在瀑布模式下8倍的生产力。作者正在参加一个有很多Scrum公司加入的模式研究项目，这些研究成果会让Systematic公司继续从优秀走向卓越。、
|
