项目时间linkedin  项目时间推特  项目时间rss  项目时间rss

2010年10月19日,星期二16:12

采用敏捷实践时避免速度颠簸

Written by

敏捷方法论已经在许多不同类型的项目中获得了大众市场的地位,这表明它们在技术的根源之外还可以应用。 会议,课程和在线内容的大量报道巩固了其作为最佳实践的声誉。 这并不意味着希望将自己从传统方法转变为敏捷方法的组织可以这样做,而不会遇到一些障碍。 关于与过渡相关的组织变更管理挑战的文章很多,但是这是实现敏捷方法的好处的其他一些障碍。

 1.反复执行,但传递瀑布

 敏捷方法的一个属性是项目范围在项目生命周期内定期交付。 一些组织可能将其项目构造为一组迭代,但不会由于这些迭代而交付客户可用的产品(通常不将文档视为可交付的真实商业价值)。 如果项目团队继续增强客户可能认为足够好的某些“进行中”的交付成果,那么这将限制客户改进或重新安排剩余工作项目的优先级的能力,并且可能招致机会成本。 这个问题的一个变种是项目团队经常交付,但是客户坚持等到项目结束,而不是评估他们的业务需求是否得到了充分满足。

 2.客户参与不足

 当缩短客户与项目团队之间的距离时,敏捷方法最有效,从而可以及时进行细化和确定工作项目的待办事项,决策和可交付成果的审查的优先级。 这可能需要客户付出大量的努力,但是出售这种参与的必要性要比接受与妥协相关的风险(例如让项目团队成员充当真实客户的代理人)更为可取。

 3.多任务同时影响速度和团队凝聚力

 过多的多任务处理会伤害项目, 而不管 他们的交付方式。 但是,对于敏捷项目而言,这可能是致命的,因为上下文切换和导致的知识鸿沟将降低生产率,引入质量问题,并使难以预测地计算或使用交付速度。 这些结果可能会导致组织对他们的敏捷计划失去信心,并在不了解问题不是方法论之一的情况下,转向更传统的方法

4.敏捷并不意味着“做到这一点”

 这本迪尔伯特漫画与经理的学说相矛盾(http://www.dilbert.com/fast/2007-11-26/),在敏捷项目中执行并不能完全取代计划。 尽管计划的深度与活动或决策的“近距离”成反比,但缺乏务实,正确尺寸的计划会导致任何项目混乱。 这是敏捷过渡变更管理过程的一部分-学习在过多和过少的计划之间取得适当的平衡。

采用敏捷方法可能是提高业务价值实现和项目吞吐量的积极一步,但是忽略了整个过程中的障碍将使您的转型计划陷入困境!

别忘了在下面留下您的评论


基隆·邦德尔

Kiron D.Bondale,PMP,PMI-RMP 在项目管理领域工作了十三年,专注于技术和变更管理。他建立并管理了项目管理办公室(PMO),并为多个行业的客户提供了PPM咨询服务。

欲了解更多Kiron对项目的看法&变更管理,请访问他的 博客 或直接通过kiron_bondale @ yahoo.ca与他联系。

©ProjectTimes.com 2021

麦格雷戈徽标白色网站