All-Green联合系统：大规模Scrum
All-Green联合系统在整个企业实施Scrum。All-Green不是一个软件公司，但是组织内部有一个大型的全球IT小组，开发和管理着大量关键的业务应用程序。开发人员、分析人员和测试人员组成全功能的Scrum团队，同时有一个独立的QA团队测试应用集成并协调发布工程师进行发布管理。
在企业持续集成之前，All-Green的Scrum团队发布报告是一个瓶颈：发布流程是之前的传统开发流程中的缓慢并需要仔细处理的发布流程。应用之间的sprints不同步，并且发布团队有一个来源于上一个sprints的未部署变化的backlong。
如果一个有5～10人的Scrum团队去管理All-Green内使用的大系统是力不从心的。在All-Green内，他们使用“scrum of scrums”的方式来进行大系统开发，虽然每个Scrum团队都在同一地点，但是整个项目是做分布式管理的。这些分布式的团队发现保持代码库的有效是很困难的，因为一个团队的改变往往会破坏另一个团队。另外，每个团队拥有自己的度量，但是在Sprint中却难以获得进度反馈，而且很难更好的决策出哪些故事应该在Sprint中完成。
通过评估企业持续集成，All-Green确定了两个主要的优先级，第一，改进Scrum团队之间的协作；第二，加快发布流程以便于每个Sprint都可以发布变更，同时更快的完成新功能。
在谈到构建时，All-Green中的每个Scrum团队首先进行团队级别的持续集成，再进行企业级别的集成，这个变化使得从构建角度来看，将所有团队的构建系统进行了统一以便共享。虽然有些团队仍然运行他们本地的持续集成系统，但是企业通过进行生产和协调团队活动来系统的生产软件。
如果Scrum团队之间存在二进制依赖，就在构建系统中集成一个官方的工件配置库，这样的组件共享机制比临时方法（如通过邮件进行）更平稳的、更透明。对于All-Green而言，像他们的“scrum of scrums”实践一样，他们在大系统中实施“build of builds”巧妙的构建了一个依赖树。现在变更仅在通过本地测试后才在团队之间共享，这样使得整个系统很少出现构建失败。更进一步的，如果出现了构建失败，他们能够快速的找到引入错误的团队以便他们更快的修正错误。通过如此多的团队和构建，All-Green拥有了一个分布式的构建网格。大量的机器集群使得团队在维护他们的系统时能够享受更快速的反馈。从构建角度来看，这样的系统使得All-Green的团队稳稳的处于成熟度等级中级。
All-Green中的测试成熟度是不同的，所有的团队随时间的推移不断的开发自动化的回归测试套件。他们更关注于开发新功能的功能测试，因此原有的遗留应用相对很少被测试，最新的应用有综合的自动化功能测试。遗留应用一般都是重要而经常变化，在All-Green中，更加快速的发布周期需要在“鲁棒”自动化测试上进行附加投资，对于“scrum of scrums”团队来说是通过单元测试对跨团队的边界进行额外的增强测试。
另外一个在Scrum团队间进行协调的关键元素是报告。在企业持续集成之前，即使在Scrum团队中数据都是停留在开发、测试和产品支持等各工具领域。All-Green使用他们的企业持续集成系统来打破这些阻碍，以便于他们能够在Sprint内或者跨Sprint进行端到端的数据相关性和趋势分析。这种改进报告满足了“scrum of scrums”，减少了协调开销。甚至单一的团队也通过相关的故事更了解他们的进度，并对他们的测试结果进行承诺。All-Green关于报告成熟度的另一方面是提供了全流程的包括发布团队的统一视图。
为了加快发布过程，All-Green开始在各种测试环境中自动部署。标准化团队之间的流程是我们的第一步，然后在所有的环境中遵循它；在完成所有的测试环境之后，产品的一键部署使得All-Green消除了他们的发布bakclog。在All-Green中的一些新应用具有广泛的自动化测试，并同其他的产品系统是非耦合的。这些应用都达到了持续部署的资深等级，实现了产品发布的完全自动化部署。
对于All-Green，企业持续集成通过小规模Scrum团队共同的有效工作提升了效率。不同的开发团队可以在大型系统的自动化构建中进行协作，构建、测试和开发团队能够使用共有的系统来深入了解其他人的活动。
原文：www.urbancode.com Enterprise Continuous Integration Maturity Model（ECIMM）
翻译：OscarYang（原始发表于http://hi.baidu.com/cmmi/），转载请注明
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
