如何当好敏捷项目的经理.doc
如何当好敏捷项目的经理 Michele Sliger 是《软件项目经理的敏捷之路》一书的编者和顾问,本文总结了她对如何做好敏捷项目经理的一些观点和建议。 每个敏捷项目都有项目经理吗 ? Michele Sliger 认为,这个问题要看具体情况。 Scrum 开发有 Scrum 经理,这算不算项目经理呢 ?XP 开发有 XP 教练,这算不算 PM 呢 ?在 Michele Sliger 做过顾问的大型企业中,虽然这些企业大都选择使用 XP、 Scrum 或是精益敏捷开发方法,但他们的人事簿上都有 PM 一职。职位还是“项目经理”,只是作用可能并不一样。 敏捷项目经理的职能与以前有何不同 ? Michele Sliger 认为,敏捷项目经理的职能与以前的定义完全不同。传统意义上的项目经理只是一个在项目失败的时候承担责任 的人。因为要承担责任,所以他们通常倾向于使用命令加控制的领导方式。在敏捷开发中,需要的是一个教练、指导、引领者,不是在微观上进行操控,告诉团队的每个人应该干什么,而是要让团队明白我们需要什么,避免走上歧路。 PMI(美国项目管理协会 )说, 90%的项目管理工作是交流与沟通。对于敏捷项目管理来说,同样是这样。这项工作的主要内容就是作为团队成员的交流媒介,帮助他们达到共识,与企业协商让他们明白企业动向将对团队产生怎样的影响。他们的作用就是协助、交流、引导,就像是那种一对一的领导方式。虽然不是要一直从商业的角度 来考虑,不过 PM 还是需要时时通知开发人员项目当前的状态。可以说 PM 几乎就是开发过程的监督人。 敏捷项目经理需要注意自己的领导方式。如果他们以前使用的是命令与控制的方式,那么必须做出改变。现在的首要任务是如何帮助自己的团队。但是,即使团队开始有组织地、高效率地运作起来,也并不意味着 PM 的工作已经结束,他们仍然需要帮助公司采纳敏捷这种方式。相对于以前协助团队的工作而言,也就是转向更有战略意义的工作,比如把精力放在如何帮助公司向敏捷进行调整上。 敏捷项目经理还必须对项目成败负责吗 ? Michele Sliger 指出, Ken Schwaber 曾经说过,在 Scrum 开发中唯一负责的是产品负责人,而不是项目经理。产品负责人是对产品有着决定权。我们可以把责任想像成三元组:产品负责人管理产品的功能需求,开发团队开发实现,而敏捷项目经理负责帮助团队完成任务并避免受到外界干扰。 PM 要保护团队,想办法满足团队需求、为团队争取预算以及其它类似工作。 项目经理是否必须拥有 PMP 资格认证并遵循 PMBOK 体系 (项目管理知识体系指南 )呢 ? Michele Sliger 认为,现在的项目经理甚至都没有正确地使用瀑布模型。我们 在每个新过程所做的都是取出 20%,了解它,然后完成。 PMBOK 也是如此。许多人没有注意到, PMBOK 并不是单单指向软件项目管理,它是针对所有的项目管理。 PMBOK 上的内容都是已被普遍认可的优秀实践,我们要做的只是仔细阅读并把它们作为必须实行的。 PMBOK 是一本指南。如果把它看做是必须做的,那么你就会围绕它建立起一个像瀑布模型的框架,然后会发现大家都在用瀑布模型。而常见的误解是,你必须建立瀑布模型来保持与 PMBOK 的一致,这种做法恰好颠倒了主次。 那么 PMBOK 和敏捷实践之间有哪些相似之处和不同之处呢 ? Michele Sliger 认为, PMBOK 中的一个要点就是渐进细化,而这正是敏捷需求定义的意义所在。渐进细化是从较高的层次上分析需求,在准备开始的时候才进行细节方面的工作。 PMBOK 还有一个要点是使用滚动计划 —— 计划到一个点、进行几个迭代周期、回顾并做下一个计划。这与传统的、在项目开始时就做好计划是不同的。 最主要的不同点是敏捷方法不会使用 PMBOK 中的所有实践。我们只是使用其中的一部分,比如滚动计划。另一个不同点是敏捷方法不做正式的项目文件,而 PMBOK 则建议做正式的项目文件,虽然这一定并不做 要求。另外, PMBOK 强调要做大量的分析,而敏捷方法则不提倡。 敏捷项目经理使用传统的 PM 工具吗 ? Michele Sliger 表示,她已经有十年时间没有碰过甘特图了。这种东西是为那些不使用迭代方法的长期项目准备的。敏捷开发所使用的应该是那些更能满足迭代开发要求的工具。这些工具不会像甘特图那样,认为一个项目可以一次性完成 90%的内容。 Michele Sliger 使用的是时间计划图 —— 要么彻底完成,要么就是失败。通过时间计划图,可以更准确地估计完成项目所需的时间。这种计划图能够比较清晰地展示当前的状态 。 如果团队比较分散,则还需要一些工具以及相关的支持设施。由于工作进展很快,所以需要如 Skype、 IM 等的共享软件,或是 XPlanner 等工具帮助进行敏捷项目管理。所有的敏捷 PM 工具都应该有以下基本特征:有存放待办任务的地方,有表示迭代的地方,可以表示正在开发中的功能、测试结果以及测试本身。 在向敏捷 PM 转型过程中有哪些可避免的常见误区呢 ? Michele Sliger 表示,千万不要把转型简单地看作使用工具的改变。别以为你放下甘特图拿起时间计划图来就嗖地一下完成了敏捷转换。敏捷是一种理念,它是价 值驱动而不是计划驱动的。你必须理解这种范式。经常有人犯各种各样的错误。不管大型公司还是小型公司,他们都以为敏捷是一种新的方法,这种方法有特殊的规则,因此要使用特定的工具。这种想法不会让你的团队变成敏捷团队—— 它只会让你变成一个使用敏捷工具的瀑布团队。