从管理人员了解敏捷项目管理（三）

前言：前面我们已经了解了敏捷项目管理如何在实践中使用，并也了解了逐渐接受敏捷项目管理的缘由，那么这一篇我们来看看敏捷项目管理中有哪些角色并且职责是什么？话不多说，我们开始进入角色的了解

目录

角色

项目经理

Scrum队长

业务分析师

产品所有者

项目团队

责任

清除障碍

制定迭代计划

回顾

评估

报告

每日例会

领导

 

---

角色
 

在敏捷项目管理中主要有两个角色：项目经理和主任业务分析师。Scrum 为许多敏捷项目经理规定了事实上的标准。

• 项目经理

在我们的职场中，项目经理这个词想必大家都不陌生。在敏捷世界中把项目经理描述成项目领导者，而经理和领导者之间还是存在区别的，因此定义敏捷项目经理的角色仍旧是有必要的。项目领导者为项目团队掌舵并且不停地塑造想象，而不是管理项目。
成为项目经理经常被错误地认为是一种职位提升。具有特殊技能的人才会被任命担当这个角色，我们将更详细地对此进行讨论。而且其他团队成员所承担的角色和这个角色一样都是专门化的。在传统项目中，团队经常将项目经理视为控制团队进展并指派工作的局外人。遵循敏捷项目管理方法的好项目经理是团队的一部分，而且位于团队的社会边界内。敏捷项目经理与团队一起协作组成一个整体，而不是扮演命令-控制的角色。
经理和领导者的区别看起来似乎很微妙，但对团队的士气而言有显著的影响。因此，最好将敏捷项目经理的角色描述为服务者和调和者。
在 Scrum 中，Scrum 队长（scrum master）确保 Scrum 规则得到正确解释。在这种情况下，Scrum 队长执行日常的 Scrum 会议、引导回顾并使用项目待办事宜来计划与其他角色的迭代。在后面的博客中我会谈到 Scrum 以及在投资组合管理中实现 Scrum 原则的方法，这里我们先了解下。

• Scrum队长

在 Scrum 中，项目经理的角色不再存在。Scrum 队长在项目中实现 Scrum 规则并且确保团队所走的路清晰明朗以便团队能保持生产力，而不是管理并带领项目的开发工作。在 Scrum所称的“冲刺待办事宜计划”中，这里对“带领”的强调变得明确，在这个计划中项目团队被赋予计划并调度其自己的工作力量。冲刺待办事宜包含即将到来的冲刺中所要解决的任务列表，这在 Scrum 中表示为一个 30 天固定长度的迭代。待办事宜包含要进行的活动和可交付成果列表，这些都是团队需要解决的。一旦团队进入这次冲刺，Scrum 队长就需要促进每日Scrum 会议的进行并为团队扫清障碍，比如环境上的、管理的或其他与团队相关的障碍。尤其在较大项目需要跨越组织层次的大型机构中，Scrum 队长必须是个有影响力的斡旋者，并且有将项目跨越部门界限的决心。在这样的项目中，Scrum 队长也必须为团队而站出来，让团队的需要得到满足。一个折中的解决方案通常是最不合乎理想的结果。将 Scrum 队长的角色解释为一个为团队工作的变更代理或仆人领导者可能更为合适，他能让团队随着时间的行进更具生产力、更有效率。在 Scrum 中，传统项目管理的职责被分为三种不同的角色：产品所有者、Scrum 队长以及团队。

• 业务分析师

业务分析师在敏捷项目管理中是不可或缺的一部分，敏捷项目对他们是非常依赖的。业务分析师经常是扑在团队的项目中，充当着顾客的喉舌，他们是除了顾客，最为了解项目需求的直接人，想想当开发人员需要澄清需求上的一个小问题时在时间和金钱上的花费的不同。对比一下询问桌子另一侧的那个人和写电子邮件并等待地球另一端的那个人有时间回答的情况。通常情况下，电子邮件线索会带来比一开始的时候所存在的更多的混淆。这就是业务分析师不可或缺的原因。

• 产品所有者

需求由产品所有者编写而不是由团队成员编写并阐明。产品所有者是一个在 Scrum 项目中和机构中都高度可见的人物，他主要为项目的成功负责。产品所有者也负责制定每个发布版的计划，并且制定功能规范与功能精炼要求以便团队进行开发。

产品所有者掌管着权力和功能优先级。从项目投资组合的角度看这个角色是主要的派遣人，如果当前的冲刺中有与功能有关的问题出现时，他也是整个项目团队的联系点。

• 项目团队

团队自身接管了我们所知的传统项目中的许多项目管理活动，Scrum 项目尤其如此。自我组织并且自我赋予力量的项目团队对工作进行计划并且为自己指派工作。

从报告的角度看，项目团队成员从他们的日常活动继承了项目的衡量标准，他们会在团队、产品所有者、Scrum 队长和其他项目涉众中传播这种衡量标准。这种机制让衡量标准和报告保持原样，不会被过滤和篡改。

责任

通常由敏捷项目经理在迭代过程中或在两个迭代之间执行，它们也可能由项目经理和其他项目团队成员（比如业务分析师、开发人员或主办者）协同执行。最常见的情况是团队和业务分析师与敏捷项目经理一起携手工作。

• 清除障碍

通常，每个项目都会遇到大量阻碍—零星分散的、无法预见的问题以及主要的大问题和组织上的障碍。更糟糕的是，它们可能在任意时间不请自来，尤其是在最糟糕的时刻跳出来。这样的问题屡见不鲜如不知道密码、没有足够的服务器权限、缺乏软件授权、无法使用工作室以及其他内部管理上的过程问题而无法开展工作。正式的升级程序通常用于解决这些问题，但即使是这些程序也可能需要好几周甚至有时候好几个月才能清除这些问题。

除了管理上的问题以外，与技术和需求有关的挑战也会产生。在敏捷项目中有两种机制用于处理这些阻碍。第一个是每日例会，在这里人们将问题表达出来并寻求解决方案；第二个是项目经理（Scrum 队长）的角色，他负责处理那些阻碍团队工作进展的问题。所以，敏捷项目经理必须愿意在机构中多承担一些工作并为团队服务。你在这里可以看到，项目经理的角色与开发角色颇有不同。一位优秀但性格内向的测试工程师不太适合成为敏捷项目经理。

在每日例会中，团队重复表达一个问题直到解决它。反过来，项目经理向团队汇报解决该阻碍的进展情况。于是每个人或多或少都有一些进展可以报告—团队报告开发活动，项目经理报告与阻碍有关的事宜。如果其他涉众偶尔参加一次每日例会，那么每个人都可以觉察到某个开放问题的紧急性和重要性。事先声明，为项目铺路并且清除阻碍本身就可以是一项全职工作。

• 制定迭代计划

迭代的时间长度通常为 2～6 周，越短越好，这个在第一篇已经说明了，需要的话可以翻看第一篇文章。经常有人问及迭代的长度是否可以有所不同这个问题。根据我的经验，在整个项目中采用固定长度的迭代最好。我见到过这样的项目：项目经理以两个 4 周迭代作为开始，而后把节拍切换成 2 周。有许多很好的原因支持这种做法。其中一个原因是可以减少新敏捷团队 2 周一次迭代的压力。一旦团队对迭代-增量开发更为熟悉，那么缩短迭代的周期就会更为有益。但我们不推荐按照所计划的密度来变更迭代长度（比如：2、3、4、2，然后 5 周），这样做也是没有必要的。有很多伟大的书可帮助你将需求（故事、用例和非功能性需求）指派成迭代，而不是相反而行。在索引卡片上记录成文档的故事对敏捷开发人员来说很常见，它们是制定迭代计划时所用的技巧。

如果敏捷项目使用用例而不是流水式的描述，迭代计划的制定过程还是相似的。用例表示一组从头到尾的业务场景。场景中有一些较为常见、较为典型，其他的场景可能是待选的或例外的案例，很少执行到。用例的挑战在于，有些用例又长又复杂，而另外一些则较为简单。另外，用例之间存在依赖关系。如果仔细研究用例，不难注意到它们通常由许多冗余的场景组成。所以，团队必须把焦点放在各个场景之上而不是直接解决整个用例。通过使用这种方法，即使是场景之间的依赖关系也可以得到解决。以这种格式来标识场景并编写这些场景的文档，自然就与业务分析师通常执行的工作一致。这是使用用例来编写需求文档的好处。

• 回顾

回顾（retrospective）并不是学习教训。它们所代表的意义比学习教训更多。传统的“学习教训总结”（lessons-learnedsessions）安排在项目的末尾进行。这个时间就显得有点太迟了，而且要在项目结束时招集所有人坐在会议桌前本身就是一个挑战。敏捷团队在迭代与迭代之间执行回顾。项目经理主持进行回顾，它包括迭代回顾以及制定迭代计划（前瞻）。从心理上说，“学到的教训”这个术语也意味着需要学些东西，但实际上并不完全是这样，也不应该给人负面的印象认为需要改变项目和过程来完成一些不一样的工作。

• 评估

有两个问题是顾客询问项目经理的经典问题：“这个项目要花多长时间”和“这个项目要花多少钱”。尤其在项目开始的时候，这些问题极难回答。如果要求一个团队根据几个索引卡片或者用例场景来估算答案，那么就有可能得到更可靠一些的评估结果。如果要求一个团队在几次迭代之后，估算完成几个新卡片上的任务所需的时间和花费，那么估算的精确度将越来越高。这是因为随着每次回顾，团队都会反省过去的迭代。有些需求可能被低估了，有些则被高估了。团队估算即将到来的需求会把以前的估算经验纳入考虑中。

传统的项目经理通常是从工程师角色转变成项目经理角色的，他们倾向于自己进行估算或影响他人的估算结果。这种“我两天就干完了，不用四天”般的英雄主义态度，在团队成员两天内无法完成工作的时候并不会为团队带来任何帮助。而且，经理自己能否完成也没有定数。这种类型的帮助不会为团队增加任何价值。有时候项目经理通过暗示的方法来影响团队，比如：“你同意吗，这个任务只要两天就够？”难道像这样的估算方法真的能对你的项目、顾客以及他们的期望有所帮助吗？

为了防止出现这个问题，敏捷项目经理不应该插手估算过程，除非他们在团队中扮演双重角色。在敏捷项目中，开发团队—只有开发团队，才能估算结果。敏捷项目经理要获取并跟踪估算结果，而且当然也要获得、跟踪实际结果。要记住，项目经理应该“带领”项目进行并将项目与顾客和主办者连接起来，而不是对人员进行微管理。选择哪种评估技巧要以易用以及能快速采用为准—比如宽带德尔菲法（Wide-Band-Delphi，这个我们在后面文章进行讨论）。另外一种有效的方法是让团队成员分别估算出自己的值然后将结果进行平均处理。例如，一个项目团队集合在一起并公开估算工作。每个人的输入都会得到倾听，而后会快速得到一个平均值，然后继续进行下一个估算过程。即使有一个故事被低估或高估，随着时间流逝也会得到平衡，就如棒球赛中的裁判员的裁定那样。还有一种比较费时的备选方法：匿名收集来自团队成员的估算结果，这样可以减少团队成员过度受到其同事影响的机会，尤其是在早期的评估任务中。

• 报告

和评估一样，报告的质量随着迭代进行将变得越来越高。一位敏捷项目经理有极为强大的工具，几乎能实时地报告状态。但为了让团队的注意力能集中在可交付成果上，对这些指标的交换只建议在迭代之间进行。考虑到迭代的长度只有 2～6 周时间，对可靠信息的交换仍旧会非常频繁。在敏捷项目中，报告的力量是极为强大的，因为团队可以分享内部和外部所完成的需求（故事）、项目的进展（故事的大小）以及系统的质量（瑕疵）。如果问项目经理，他可以精确地回答以下问题：“已经完成的有哪些？”、“我们做得怎么样？”以及“这个系统有多好？”这些信息足够用来判断以往的迭代成功与否。请记住，所有的数据都自然而然地由敏捷开发人员和业务分析师的工作所创建。无需额外的工作来生成这些数据。

• 每日例会

敏捷项目经理主持召开每日例会，应该确保会议准时开始并且速战速决，通常不超过 15分钟。如果团队在地理上是分散的，那么就需要对会议时间、资源进行同步并准备。主持会议包括确保团队成员以同事的方式互相报告状态并消除无关的讨论。在会议上提出的可能阻碍问题需要进行记录，列入项目经理需要做的工作列表中。这项活动的挑战在于让团队按部就班地进行会议并让会议准时召开。为了简化管理这种会议的流程，会议通常应该在每天相同的时间在团队工作室中召开。因为每日例会对公众开放，所以旁听者可以从项目团队那里接收到额外的、及时的状态更新信息。

• 领导

在迭代中，需要发挥领导技能让团队前进。团队中典型的问题都是这样的：琐碎的或者非常具有挑战的未被解决的瑕疵、没有开发人员主动去解决生成的崩溃这个问题、两个开发人员结对的时间太长而需要与团队中的其他人员更多地融合以及需要对需求进行协商等。敏捷项目经理提醒团队成员把工作做好、随时了解关键条目的最新状态并且记录已完成事项。敏捷项目经理既把团队呈现给外部世界也保护团队免受外界干扰。太多的干扰都可能使团队从其目标上分心。

了解了上面的角色以及职责，那么恭喜各位，离成功的项目经理又进了一步。