敏捷项目中如何做好进度管理及其步骤方法(敏捷项目中如何做好进度管理及其步骤方法研究)

敏捷项目中如何做好进度管理及其步骤方法(敏捷项目中如何做好进度管理及其步骤方法研究)

项目经理经常会被一些不了解的人问,“项目经理不就是管进度的么?”,可见管理进度是项目经理多么重要的一个职责,当然这样问的小伙伴多少对项目经理的职责缺乏理解,但不妨碍进度管理是项目经理重要职责这一事实。接下来我们就来看看怎么做好进度管理,要如何一步步做好项目的进度管理。

一、制定计划

互联网软件项目,唯快不破的文化氛围下,造成程序员对于计划往往不屑一顾,经常会有这样的反对声音,“计划赶不上变化,做计划有什么意义”,那是不是制定计划真的不重要呢?那必然不是,那计划的价值究竟是什么呢?

1.1 为什么需要计划

其实,无论是在传统项目管理中,还是敏捷迭代中,计划都是完成目标的第一步。

美国质量管理专家沃特·阿曼德·休哈特(Walter A. Shewhart)首先提出的,由戴明采纳、宣传的著名的管理理论“PDCA环”,也称为戴明环,其中P(Plan)计划就是第一步,然后才是行动D(Do),C(Check)检查,A(Action)改进(行动,跟前面的行动有点重叠,我更愿意将它解释为改进。

敏捷项目中如何做好进度管理及其步骤方法(敏捷项目中如何做好进度管理及其步骤方法研究)

图1.PDCA循环

高效能人士的七个习惯》这本书提到一个概念,可以帮助大家重新理解计划的价值。

任何事情都是先在头脑中构思,也就是智力上的第一次创造,然后再付诸实践,也就是体力上的第二次创造

头脑中的第一次创造,就是计划,也是头脑中对于未来的一种正向的预想,有助于我们实现计划。所以如果你想让你的项目顺利交付,就好好的做计划,制定计划的过程也可以帮助我们发现问题和风险。

1.2 那么如何做计划呢

提到制定计划,大家应该都听过WBS(Work Breakdown Structure),什么是WBS,又该如何来制定WBS。学习过PMP的人应该对这个词不会陌生,WBS就是工作分解结构,把项目工作拆解为具体的,易于管理的子任务。

这里需要遵循的原则就是不漏不重,以及适度,不漏就是需要考虑把与项目范围相关的所有事项都包括在内,不重就是避免任务和任务之间交叉,WBS分解后的最小工作包都需要分别对应到人,明确交付的时间节点,如果出现重叠就会造成职责不清。

拆分的颗粒度是越细越好吗?如果每个任务都拆分到1个小时以内,是不是会更加好管理,但实际上这是不可能的,因为任务拆得太细,会使管理成本急剧上升。我们的2周一个迭代的管理中,一般任务颗粒度在4~16小时,大部分任务控制在1天以内,这样我们每天在晨会跟进任务的时候,就可以看出是否存在延期,及时发现问题并作出调整。

原则解释起来简单,但是在实际操作中,却非常容易犯错。尤其是不漏,项目中就经常会出现这样的情况,项目临近尾声,才发现按照产品要求,此需求需要完成另一套环境上进行测试验证,而实际在评估的过程中根本没有把此项工作考虑在内。

另外,开发同学评估工作时,往往容易忽视研发以外的工作评估,例如,环境部署、数据验证(一些数据统计类的需求,由于测试环境数据不足或者无法真实模拟真实数据,还需要考虑在预发环境中进行数据验证工作量)等等。那么如何来避免呢?

我们在实践过程中积累了一套创建任务的规范,此规范除了建立统一的管理规范以外,也起到了提醒和检视的作用。这份规范包括两部分:任务的标题规范、任务内容规范

敏捷项目中如何做好进度管理及其步骤方法(敏捷项目中如何做好进度管理及其步骤方法研究)

图2.任务创建方法

1、任务的标题规范,分为三个部分

1)标明角色,是前端、后端、还是测试

2)需求内容,把此任务对应的需求名称简要描述作为任务的一部分

3)具体内容,是完成开发任务,还是完成前后端联调,亦或是测试任务。

简单来说,标题中的这三部分就是2W1H(Who、What、How)

2、任务中具体内容部分

1) 预计工时,任务的颗粒度需要控制在4~16个小时之间

2) 截止日期,这部分表示完成这个任务的时间W(When)

这个规范一个任务需要包括3W1H这四个方面展开的。

任务是作为计划的一部分,有了任务,还需要做一个重要的动作就是核对任务,识别好相互之间的依赖关系,定义好任务的前后顺序,最后在团队中同步(邮件或者即时聊天工具)。

二、设置检查点

检查属于项目管理中的监控过程组,没有检查的计划无法真正得到落实,因为计划是建立在假设的基础上的,而检查就是将假设与实际情况进行比较,及时发现问题,作出调整,以确保项目目标的达成。

Scrum的特点就是及时检查,及时反馈,具体的检查点有哪些呢?除了前面Daily Scrum(每日站会),还有Sprint Review(评审会)。

瀑布型项目中也同样有检查点,他的检查点一般在阶段交付的检查上,称为交付的验收,也有一些方法是公用的,瀑布模式中也同样可以安排日会,在项目前期需求比较模糊的阶段,或者项目冲刺阶段,都可以安排日会来每日同步进展和风险。

Scrum中的Daily Scrum通常在同一时间统一地点举行,一般会回答三个问题:昨天完成了什么?今天计划完成什么?有没有什么问题或者风险?可以帮助大家很好的同步团队进展,及时发现和解决项目问题。

这里要特别注意在同步进展的时候,经常出现的一个词,就是“差不多”,这个功能是否已经完成了,团队成员回答“差不多吧”,或者“完成80%”。这个时候项目经理就要注意了,在这个“差不多”中间其实“暗藏玄机”,可能就是一个风险信号。听到这个词你需要停下来,要求对方把详细的信息量化的表达出来,然后重新进行评估,分析具体的问题,再有针对性的提出解决方案。量化的表达出来,是问题被解决的基础。举个具体的例子:

项目团队来了一个新成员N,一天早会的时候,跟进到他对应负责的需求时,他回答是"差不多吧,加加班应该可以完成的",这句话的潜台词其实是“按期完成存在风险”,因为当前他处于接口开发过程中,于是我接着往下问,”具体有哪些接口,每个接口的进展情况分别是怎么样的呢?”于是这位同学回答说,“我需要回去整理一下”。

早会后,这位同学把所有接口的进展情况整理发到群里,可以看出其他接口都已经完成处于待自测状态,还有一个复杂接口还未完成,由于刚来项目组不久这个接口对他来说需要花费更多的时间去熟悉,团队其中一个组员看到他发出来的接口完成情况清单,随即自告奋勇决定帮助N同学完成待开发的接口功能,及时解除了风险。

三、适时调整

适时调整的方式有很多,快速可以处理的问题,我们会直接在Daily Scrum中就做出调整,如果Daily Scrum中无法及时解决的,我们会在会后组织小会展开讨论。一般会从范围、进度、成本三个角度考虑做出调整,以满足交付要求。

1)、范围的角度,需求、项目范围是否可调整

需求范围一样遵循2/8原则,可以根据需要交付内容的优先顺序,优先完成对客户重要的需求,或者计划时是否有备选方案可供调整,比如简版的实现方案,出现延期时立即启用备选方案。

2)、成本的角度,是否需要安排加班,或者外包出去

加班或者外包出去,都会导致成本的增加,但是在面对团队人员有限,或者短期工作量增加的情况,短期加班或者将功能外包也是不错的选择。

3)、进度的角度,及时汇报或者升级风险

如果以上几个方面全部做出考虑,依然无法解决延期问题,那么及时汇报也是进度管理中非常关键的一个方面,哪怕计划做得再好,项目中总是会出现这样那样的意外情况。

当意外情况发生的时候,项目经理要做的要把项目进度及时的同步出来,不要让项目进度成为你一个人知道的秘密。有些情况下,团队内部无法做出调整时,可以在跟业务方、其他重要项目干系人沟通的过程中得到支持,以帮助解决问题。

作者介绍:傅益利

PMP/Prince2/CSM;

现任国内500强公司PMO,项目管理经验超过10年。

近期热文:敏捷项目中如何做好进度管理及其步骤方法【管理有度1】

  • 百万年薪PMO&项目经理职场影响力是如何炼成的?【精华笔记】
  • PMO&项目经理如何高效解决问题看这篇文章就够了
  • 一图掌握项目管理的核心工具WBS工作分解结构,PM必备技能!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2024年4月26日 上午9:00
下一篇 2024年4月26日 上午9:12

相关推荐