采用敏捷项目管理的人员通常会担忧以下问题:
▪ 敏捷不适用于大而复杂的项目。
▪ 敏捷太过开放,我们无法预测成本。这是“批准的范围蠕动”。
▪ 敏捷太过关注“技术人员”。
▪ 软件开发人员与客户的交流不在同一频道上。
▪ 客户没有时间参与计划。
▪ 我们不希望客户看到我们的丑事。
▪ 这个“团队合作”的做法听起来不实用。
▪ 日常会议?我们的员工会觉得自己暴露在显微镜之下。
▪ 敏捷过于僵化,抑制个人创造力。
事实是,上述担忧合情合理。无论使用敏捷还是瀑布,项目团队如果没有注意到上述问题并找到解决这些问题的方法,就会面临失败。
需要理解的真正重要的问题是,什么情况下使用敏捷更有利,什么情况下使用传统方法更好。
以下情形应使用敏捷管理项目:
1)团队成员此前没有合作过,或者没有接受充分的培训
从某种意义上说,敏捷方法比任何流行的传统方法更为简单,因为它的规则更简单,规则遵从性也更明确。在这种情形下使用敏捷的原因不是为了节约培训时间,而是为了规避培训失败的高可能性,因为培训失败会导致项目混乱。
2)团队没有可以保护项目数据完整性的、实时交易的项目管理工具
市场上大多数项目管理工具都不是实时交易工具,不能保护项目数据的完整性。如果项目团队甚至没有意识到,需要一个强大的项目管理工具才能使用