当需要我们基于最新的打印技术，来开发一款高速打印机的时候会遇到许多问题；当管理包括来自各个领域的开发人员的大型项目的时候需要找到有效、灵活的解决方案。Océ Printing Systems 决定根据自身背景加以使用 Scrum，通过规模化 Scrum 以实现协作和进展透明。
来自德国慕尼黑 Océ Printing Systems 的软件项目经理 Christian Sack 与 R&D 的部门经理 John Kesseler 在 Software-Centric Systems 大会上共同介绍了如何在涵盖软件开发者、机械工程师、化学家、物理学家和测试人员的大的项目团队，通过规模化 Scrum 方法，开发一款最新技术的打印机。
InfoQ 采访了 Sack 和 Kesseler 以下的一些问题：他们在项目中遇到的主要挑战？他们如何根据真实情况使用 Scrum？电气工程师和机械工程是如何使用敏捷方法工作的？Scrum 对项目进展和 R&D 组织有何推动？目前所遇到的挑战，并打算如何处理它们？
InfoQ：Océ这个项目遇到了哪些主要挑战？
Christian Sack 和 John Kesseler：随着打印技术的发展，我们也必须推出最新的打印机。所以在开发打印机的时候我们需要管理好各种变化。同时，由于有很大的一个团队都在为这个项目服务，因此我们需要协调复杂的组织任务。我们认为最大的挑战是，因为打印机原型上只有有限的测试容量，这给测试工作造成了干扰。
InfoQ：如何根据你们的需求进行使用 Scrum 呢？
Sack 和 Kesseler：我们引入了一种产品负责人层次结构来决定团队中的优先事项。产品负责人与项目经理紧密联系，他们可以设置请求功能的优先次序，帮助解决资源冲突。
开发者必须非常熟悉好的软件架构以及对其他非软件组件和组织接口的依赖。我们决定采用规模化的 Scrum 方法 SAFe（大规模敏捷框架）的实践。新组建的软件架构团队，包括产品负责人和软件专家，需要提前分析好需求，并规划好架构如何进行实施。
需求分析包含两个步骤。首先，需要讨论需求，并在审查环节中确定实现史诗故事的成本。在史诗点需要估算成本。史诗点与用户故事点类似，要根据其他相关的史诗估算工作量。这样就创造了多次发布的路线图。其次，下次发布中实现的史诗要被分解为多个用户故事，并在不同的用户故事审查中讨论。这些审查还需要确定所需的技术。这对于 Scrum 团队有很大的帮助。
强制的检查表可以细化成本估算，确定史诗之间的相互关联，并在分析过程中获得专家验证。当检查表的所有项目都确定是完善的时候，架构团队才会给出 Definition of Read(DoR)。只有满足 DoR 的史诗和用户故事才会在下次发布中出现。这帮助提升了积压工作的质量，并有助于 Scrum 团队预估 sprint 的结果。
很快，我们就能知道平均每个团队在每次发布的时候能实现多少史诗点（即史诗速度）。主产品负责人对史诗点进行估算，排列每个史诗的优先级，然后规划出一个覆盖一年，大约三次发布的路线图。在史诗级别实现这些需求的透明度获得了整体项目负责人的高度赞赏，并成为整个项目的重要依据。
除了以上提到的 Scrum 手段，还有一些其他的改进，比如说：
- 引入支持 Scrum 过程的基于网络的工具，JiraAgile。
- 举办所有 Scrum 管理员以及产品负责人的会议来讨论项目进展，比如说可以讨论早期遇到的资源瓶颈。
- 制定每周一次的“Scrum 再见日”，在这天可以做与现在 sprint 目标无关的工作，比如说可以解决一些技术债务或是进行一些实验。
InfoQ：能否介绍一下，除了平时的训练和辅导，你们还做了一些什么来实践 Scrum 方法吗？
Sack 和 Kesseler：我们决定挑选一些技术人员担任产品负责人，因为他们对于所需完成的功能最了解。我们在 Scrum 团队中培训了 24 名技术人员担任产品负责人。
在一开始的时候，新培训的 Scrum 管理员缺乏处理 Scrum 团队中遇到的问题的经验。比如说，他们很难处理好团队中的纷争。因此我们决定给他们提供另外的培训，教会他们如何平息事端、如何演说、如何与人沟通和如何解决冲突的方法。这个方法很奏效，他们很快地适应了自己的新角色。
InfoQ：你们提到在 Scrum 团队中还有电气和机械工程师。他们是如何看待以敏捷的方式工作的？
Sack 和 Kesseler：在项目的一开始，他们对 Scrum 方法有些抵触，但是在逐步推进之后，这些抵触情绪很快消除了。非软件相关行业的人感觉到 Scrum 方法促使了他们和软件相关行业的人共同合作（反之亦然）。
InfoQ：Scrum 方法给项目带来了什么优势？给 R&D 组织带来了什么好处？
Sack 和 Kesseler： Scrum 提高了技术人员、软件工程师和质量保证人员之间的合作与交流。Scrum 团队中有来自各个领域的代表。整个团队可以相互讨论解决问题，而不是相互指责。
每个 Scrum 团队都有自己的质量保证员，从项目的一开始就有测试的需求。这样大大提升了交付的质量，并避免了开发结束时大规模的质量测试活动。虽然集成测试和系统测试的持续时间缩短了，但是现在的错误情况更可预测。发布时间规划可靠度也提升了不少。
燃尽报告帮助提高进展过程中的透明度。同样，项目的瓶颈以及项目计划偏差也可更好预见。
InfoQ：现在团队遇到的敏捷方面的挑战是什么，你们准备如何解决它们？
Sack 和 Kesseler：由于原型的成本很高，所以我们只有非常有限的一些硬件，这是我们项目中一直存在的一个问题，因此我们团队将持续争取所需的测试硬件。目前我们团队一次又一次的无法在规定时间完成软件测试，为了解决这个问题，我们在模拟和自动化测试上花了很大功夫。在某些情况下我们允许平行工作，所以每个团队的工作不会相互影响。但是这后一种策略仅在同一个 sprint 中两个功能之间没有相互依赖关系的时候适用。
由于规模化 Scrum 的成功，我们也计划会在其他项目中实施 Scrum 方法，当然这完全取决于项目的规模。在需要的地方我们将加一些新的细则以进行具体的调整。我们也会将 Scrum 中的角色与现有团队中的角色进行整合，以尽量减少开支。
评论