将传统软件开发的角色映射到 Scrum 中

许多着手实施敏捷的组织，都不得不把传统软件开发的角色与 Scrum 定义的三种角色 之间的映射处理好。传统的角色如：产品经理、项目经理、业务分析师、设计师、DBA 等等，在 Scrum 中没有清晰的映射关系。 Mike Cottmeyer 在一系列的文章 中尝试着提供一种有效的映射方式。

Mike 认为“ Scrum Master”和“Scrum 团队”这两种角色是很容易匹配的。项目经理可以匹配 Scrum Master 的角色，不过思维方式需要调整。他说：

ScrumMaster 提供过程方面的辅导，为团队提供支持。项目经理通常是负责管理团队，确保时间、成本、范围三者之间的平衡…… ScrumMaster 不具有统治团队的权威。它更像是仆人……项目经理就更像是老板。

同样，“Scrum 团队”应当把承担了构建产品重任的每个人都包含进来。 > 开发团队、负责数据库的家伙、QA 都可以匹配“团队成员”这个角色。这些家伙对设计、构建、测试负有直接责任。

上面这些角色匹配好了以后，还有很多角色剩了下来，例如业务分析师、系统分析师、用户体验专家等等。Mike 认为，这些角色都有可能担任产品负责人。

产品负责人是项目经理，是业务分析师，是系统设计师，是用户体验架构师，是所有的业务团队成员……全部职责系于一身。这个角色无处不在，无所不能。

不过 Mike 也承认这个角色本身太庞大了些，所以他也建议不要让一个人担当所有职责，可以组成一个产品负责人团队，让多人协同工作。这个团队可以包括：

• 产品经理——跟利益相关人协作，识别需求，设定优先级。
• 项目经理——维护所有任务的整体规划。管理资源、资产消耗、外部依赖等等。
• 业务分析师——将验收标准和有关用户故事的沟通交流进行文档记录。他还担起在 sprint 中澄清需求的主要责任。
• 设计师——准备一些屏幕截图、线框等等。

他用绘图的形式表示出了团队结构：

所以，产品负责人不是独立工作，而是跟其他角色协作，用他们丰富的知识和专业技能，做出正确的上下文定义并进行协调。

把角色进行分组以后，传统角色就可以跟 Scrum 的三种角色匹配了。这里的关键点在于，要把他们放到可以为整个团队提供价值的地方去。

查看英文原文 ： Mapping Traditional Software Development Roles to Scrum