【51CTO专稿】我们都知道敏捷是一套流程和方法的持续改进，它能够通过快速迭代的方式交付产品。而这个抽象的流程形式在不同项目中会根据具体的项目特征进行裁剪，这涉及到了团队在Scrum中实施过程的规划与拆分的问题，下面记者采访了Thomson Reuters公司流程改进部门经理陈斌老师，给网友们分享了敏捷在项目中实施的一些主要问题。
个人简介：陈斌老师目前任职Thomson Reuters公司流程改进部门经理，负责敏捷教练（深入开发团队）与工具环境支持（包括工具开发及方案提供）。
10年产品/软件开发，以及8年质量保证/流程改进经验。经历过无流程，重流程，轻流程的各种风格。近年来的专业领域：参与CMMI评估以全面了解软件组织成熟度，引入敏捷原则及方法以提供应对业务挑战的具体变革方案，应用Six Sigma方法以保证流程改进产出业务价值。
以下是采访实录：
记者：敏捷实践过程中Scrum实施整个过程怎样规划。
陈斌老师：实施Scrum过程的第一件事情就是要明确为什么实施Scrum。目标应该是业务导向的，即解决什么痛点，预期的收益是什么，而不是敏捷转型。通过这样的分析，甚至可能意识到其他选择更为适合。例如产品已进入运维期，Kanban或其他方法更适合快速响应客户反馈。
如果确定了实施目标, 需要把信息明确传递给每个工作人员，作为大家共同的目标，而不仅仅是某个“工作组”的目标。
其他实施过程包括：选择试点产品组，初期培训，框架设立，工具选择，组内教练，总结调整，结果度量，带动更多产品组。选择试点时要小心，如果试点组与其他组依赖关系很强，成功难度很高。
记者：迭代开发过程的一些困难与解决方法。
陈斌老师：最大的难点在于每个迭代都产出最有价值的产品增量，并且是有质量保证的。
前者要求能从重多需求中把握到客户核心价值，并分解到短期可完成的完整的用户故事。产品经理的选择是重点。
后者要求评审，集成与测试基本同步于开发完成。测试不仅是新功能测试，还包括回归功能测试/性能测试等。持续集成与自动化测试由此会成为高优先级任务，而不是在传统开发模式中的“nice to have”。
记者：敏捷实践中团队的拆分是如何进行的？
陈斌老师：首先认清事实，同样是合作，跨组合作远远难于组内合作，无论管理层如何强调。所以拆分的重点在于如何减少不必要的跨部门合作。“一站式”服务团队是目标：从需求到上线，绝大部分环节在组内完成，协调沟通发生在组内。
当产品规模很大时（例如团队超过100人），每个独立团队很难做到“什么都能做”，合理的解耦是关键。能够落实到任一用户功能能由一个团队独立完成（或很少的外部依赖）就可以了。
记者：如何更有效的做好开发流程估算？
陈斌老师：初始估算只能先“拍脑袋”，在迭代中参照实际调整估算，这是迭代开发的优势之一。重点：发布计划不能变，重大功能点不能变，具体需求细节随时调整。
记者：敏捷实践下的程序员工作指标将如何衡量?
陈斌老师：先衡量团队绩效。成熟的指标包括产品发布版本的缺陷数目，上线时间，与竞争对手的比较。
在团队内部360度互评贡献度。
记者： scrum会议，在您们的团队中是如何进行的？
陈斌老师：管理者退一点儿，团队成员进一点儿。
记者：团队中是否有敏捷测试人员？需要哪些技能？
陈斌老师：有。一方面强调团队整体对质量负责，对测试负责；另一方面在团队真正成熟前，专职的测试人员能保证“测试”任务不被功能任务挤掉，同时测试人员的独立视角很有帮助。
全功能团队不是说每个人都作同样的工作，而是没有职能“边界”与灰色地带。
记者： 敏捷教练在Scrum中如何进行角色转换？
陈斌老师：能进而作为角色榜样，而目标在于退出团队角色时团队运转良好并在自我优化。
记者：对于未来几年敏捷开发的发展，您希望看到哪些新方向?有何建议?
陈斌老师：迭代开发，持续集成等已深入人心。难点在两头，也是努力的方向：组织结构（包括文化，部门划分，绩效考评）和深入的工程实践（例如测试开发同步）。
