新闻与资讯
项目管理什么时候用敏捷，什么时候用传统方法？
采用敏捷项目管理的人员通常会担忧以下问题：▪ 敏捷不适用于大而复杂的项目。
▪ 敏捷太过开放，我们无法预测成本。这是“批准的范围蠕动”。
▪ 敏捷太过关注“技术人员”。
▪ 软件开发人员与客户的交流不在同一频道上。
▪ 客户没有时间参与计划。
▪ 我们不希望客户看到我们的丑事。
▪ 这个“团队合作”的做法听起来不实用。
▪ 日常会议？我们的员工会觉得自己暴露在显微镜之下。
▪ 敏捷过于僵化，抑制个人创造力。
事实是，上述担忧合情合理。无论使用敏捷还是瀑布，项目团队如果没有注意到上述问题并找到解决这些问题的方法，就会面临失败。
以下情形应使用敏捷管理项目：
1）团队成员此前没有合作过，或者没有接受充分的培训
从某种意义上说，敏捷方法比任何流行的传统方法更为简单，因为它的规则更简单，规则遵从性也更明确。在这种情形下使用敏捷的原因不是为了节约培训时间，而是为了规避培训失败的高可能性，因为培训失败会导致项目混乱。
2）团队没有可以保护项目数据完整性的、实时交易的项目管理工具
市场上大多数项目管理工具都不是实时交易工具，不能保护项目数据的完整性。如果项目团队甚至没有意识到，需要一个强大的项目管理工具才能使用其中一种传统方法，那么最好使用敏捷，因为它对强大工具的依赖性要小得多。
以下情形应使用传统方法管理项目：
1）需要预先定义需求的项目
某些方案，特别是政府的方案，可能需要项目研究和提前定义需求，在需求定义后一段时间内进行大量审批，最后是独立的项目（通常是与需求项目团队不同的团队），开发和交付需求中所说的内容。
如果是这种情况，请避免使用敏捷方法，因为它依赖不断的交互作用和不断变化的适应，而没有清晰的开发过程文档。
2）客户或用户组无法参与
项目成功的最大因素是坚定的执行发起人或产品所有者。当客户在整个项目过程中参与制定需求时，例如审查工作和确定优先级，这意味着他们不太可能突然抛出难以实现的需求。他们不断将业务和用户需求纳入流程。
若客户参与度不高，没有将他们的要求正确地输入到过程中，也没有参与构思的演变，这样就需要经常回溯项目并浪费了项目的时间，因此不适合使用敏捷方法。
3）团队太大（200人或更多），无法进行跨部门沟通
敏捷过程要求团队成员在项目期间做出很多关键的决定。如果你的团队成员没有足够的经验和责任心，则可能会破坏整个项目。
敏捷方法需要所有利益相关者（开发团队，测试部门，管理层和客户）之间不断的互动。如果其中一支队伍表现不佳、跨部门沟通不畅，那肯定会影响整体成绩。如果这时使用敏捷，可能会适得其反。
如何选择正确的项目管理方法？
实际上，没有适合所有项目或组织的“千篇一律”的方法论。实施方法的选择很大程度上取决于诸如项目性质、规模、涉及的资源等因素。
在大多数情况下，聪明的项目经理会考虑所有方面，然后决定采用哪种方法是针对特定项目实施的最佳方法。无论选择哪种方法，确保能够完成工作的正确项目管理工具到位是重要的因素。
8Manage 敏捷项目管理软件支持增量式产品开发的短迭代管理和满足竞争格局和产品需求动态变化的管理需求。你也可以灵活扩展8Manage系统以满足传统项目监控的管理需求（如时间管理，成本管理等）。
1、同时拥有敏捷递增和交易型 WBS 的优点
▪ 同时支持传统的大型项目和敏捷项目
▪ 面向实时交易，拥有单一事实版本的当前计划和状态
▪ 自动准确计算最终目标的完成率
▪ 不能催毁的自动化审计跟踪
2、当前敏捷项目与最终目标对齐
8Manage敏捷管理为最终目标建立基线，在每个较小的敏捷项目完成时，系统自动计算最终目标的完成率，让团队的子目标和最终目标一直保持一致。
结论
尽管敏捷方法在软件开发人员中广受欢迎，并且具有许多优势，但它并不是灵丹妙药，不是都适用于你的每个项目。对于项目管理而言，最重要的一点是你的团队要尽可能高效地完成任务。成功的企业不会只执行特定的单一策略，相反，它们会结合所有项目管理方法来解决不同的问题并实现不同的目标。
