陈斌：Scrum实施规划与团队拆分

个人简介：陈斌老师目前任职Thomson Reuters公司流程改进部门经理，负责敏捷教练（深入开发团队）与工具环境支持（包括工具开发及方案提供）。

10年产品/软件开发，以及8年质量保证/流程改进经验。经历过无流程，重流程，轻流程的各种风格。近年来的专业领域：参与CMMI评估以全面了解软件组织成熟度，引入敏捷原则及方法以提供应对业务挑战的具体变革方案，应用Six Sigma方法以保证流程改进产出业务价值。

以下是采访实录：

记者：敏捷实践过程中Scrum实施整个过程怎样规划。

陈斌老师：实施Scrum过程的第一件事情就是要明确为什么实施Scrum。目标应该是业务导向的，即解决什么痛点，预期的收益是什么，而不是敏捷转型。通过这样的分析，甚至可能意识到其他选择更为适合。例如产品已进入运维期，Kanban或其他方法更适合快速响应客户反馈。

如果确定了实施目标, 需要把信息明确传递给每个工作人员，作为大家共同的目标，而不仅仅是某个“工作组”的目标。

其他实施过程包括：选择试点产品组，初期培训，框架设立，工具选择，组内教练，总结调整，结果度量，带动更多产品组。选择试点时要小心，如果试点组与其他组依赖关系很强，成功难度很高。

记者：迭代开发过程的一些困难与解决方法。

陈斌老师：最大的难点在于每个迭代都产出最有价值的产品增量，并且是有质量保证的。

前者要求能从重多需求中把握到客户核心价值，并分解到短期可完成的完整的用户故事。产品经理的选择是重点。

后者要求评审，集成与测试基本同步于开发完成。测试不仅是新功能测试，还包括回归功能测试/性能测试等。持续集成与自动化测试由此会成为高优先级任务，而不是在传统开发模式中的“nice to have”。

记者：敏捷实践中团队的拆分是如何进行的？

陈斌老师：首先认清事实，同样是合作，跨组合作远远难于组内合作，无论管理层如何强调。所以拆分的重点在于如何减少不必要的跨部门合作。“一站式”服务团队是目标：从需求到上线，绝大部分环节在组内完成，协调沟通发生在组内。

当产品规模很大时（例如团队超过100人），每个独立团队很难做到“什么都能做”，合理的解耦是关键。能够落实到任一用户功能能由一个团队独立完成（或很少的外部依赖）就可以了。

记者：如何更有效的做好开发流程估算？

陈斌老师：初始估算只能先“拍脑袋”，在迭代中参照实际调整估算，这是迭代开发的优势之一。重点：发布计划不能变，重大功能点不能变，具体需求细节随时调整。

记者：敏捷实践下的程序员工作指标将如何衡量?

陈斌老师：先衡量团队绩效。成熟的指标包括产品发布版本的缺陷数目，上线时间，与竞争对手的比较。

在团队内部360度互评贡献度。

记者： scrum会议，在您们的团队中是如何进行的？

陈斌老师：管理者退一点儿，团队成员进一点儿。

记者：团队中是否有敏捷测试人员？需要哪些技能？

陈斌老师：有。一方面强调团队整体对质量负责，对测试负责；另一方面在团队真正成熟前，专职的测试人员能保证“测试”任务不被功能任务挤掉，同时测试人员的独立视角很有帮助。

全功能团队不是说每个人都作同样的工作，而是没有职能“边界”与灰色地带。

记者： 敏捷教练在Scrum中如何进行角色转换？

陈斌老师：能进而作为角色榜样，而目标在于退出团队角色时团队运转良好并在自我优化。