|
4.敏捷只是加快速度而已项目管理者联盟
软件开发类的项目，越来越多地被人们冠以“急行军”的名目。爱德华·约顿定义了何为“急行军”项目。项目管理者联盟
“很简单，急行军项目就是项目实际的资源需求超过分配资源的50%以上。在大多数项目中意味着，以下的某个限制被强加给了项目：项目管理者联盟文章
· 项目时间在合理的预算基础上被压缩了一半，如一个预计12个月的项目被要求在6个月内完成……项目管理者联盟
· 项目团队人员跟同等规模的项目相比减少了一半……项目管理者联盟
· 项目预算和其他的资源被减半……pmp.mypm.net
· 对功能和性能的需求或其他技术上的要求翻倍于通常情况……”项目管理者联盟
通常来说，“急行军”项目就是指要求项目团队不改变项目的执行方法，但以更快的速度完成同样的工作。这种粗暴地压缩项目时间的行为非常令人担忧，有很多潜在的风险。项目管理者联盟
约翰·伍登是非常著名的执教加利福尼亚州大学洛杉矶分校的篮球教练。“在约翰·伍登的最后12年执教生涯中，加利福尼亚州大学洛杉矶分校篮球队获得了10次全美大学生体育学会冠军。而在他执教该队的27年中，没有任何失败赛季。他们的88场连胜纪录可能永远无法超越。”约翰·伍登跟他的队员说：“再快点，但是别着急。”加快速度需要更好的纪律和更多的训练，而着急只是粗暴地加快速度，使成功率下降。项目管理者联盟
5.敏捷只适用于开发部门项目管理者联盟
很多人认为变得敏捷只对产品开发部门有好处，这是业务部门中常见的误解：只要使产品开发部门变得更加敏捷、效率更高，就可以解决所有问题。事实是，变得敏捷不只影响产品开发部门，同时也要求业务部门承诺同开发部门非常紧密地合作。同时还要求转变整个组织的文化和思维方式。项目管理培训
如果没有管理层的鼎力支持和长期承诺，走向敏捷之路也许注定失败。在很多时候，业务部门需要在这个转变过程中扮演领导者的角色。项目管理者联盟
“业务部门代表必须真正介入并了解这个过程。是否这样做了差异巨大(如沟通的术语、采用的方法等)。一旦他们了解了，他们将看到介入并主导开发过程的好处。同时业务部门还需要清楚地了解他们必须承受的东西，因为当他们看到每个迭代中暴露出来的问题时，他们可能会变得沮丧，如未完成的工作、团队犯下的错误和其他各种问题，这些问题在其他方法中都被掩盖了，因为业务部门参与很少，参与时间间隔很长。”项目管理者联盟
6.敏捷只是一种开发方法项目管理者联盟
跟前者类似的一种误解认为敏捷只是一种开发方法，而不是项目管理方法和框架。这种认知很可能来自敏捷在早期时主要是开发方法，没有或缺少框架和流程。但从那时起，敏捷已经越来越成熟，Scrum已经成为一种比较完善的方法和流程，并已经建立了相对完备的知识体系。bbs.mypm.net
以下原因解释了为何这种认知依然存在。service.mypm.net
(1)在敏捷项目中，开发方法和项目管理方法直接的分界线有些模糊：项目经理博客
·开发过程并不是同需求管理和其他项目管理完全分开的，通常来说，它们紧密地结合在一起。service.mypm.net
·项目管理方法没有被正式地定义为同开发流程相独立的流程，在很多时候，敏捷方法中根本就不用“项目经理”这个词。bbs.mypm.net
(2)敏捷方法作为组成部分之一，通过整合和扩展，构建了一个完整的项目管理框架。敏捷并没有详细地定义大型的和复杂的项目所需要的高层次的计划制定和项目管理，但将其描述为仅仅是开发方法是不准确的。项目管理培训
1.7 敏捷不是万能的项目管理者联盟
关于敏捷的误区有多个原因。项目管理者联盟
(1)敏捷方法设计时不是规定式的：它们没有告诉你需要做什么或如何去实施。总体来说，敏捷方法定义了一些基本原理而在具体情况下需要具体的解释。例如，敏捷宣言中定义了4个价值观和12个原则。“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下4个价值观：club.mypm.net
· 个体和互动高于流程和工具。项目管理者联盟文章
· 工作的软件高于详尽的文档。项目管理者联盟
|
