为什么敏捷项目管理只适用于IT项目

敏捷开发其实是对由于在长期的软件开发的实践中形成的一种方法论体系，现在的敏捷开发的理论体系包括了很多种方法论的。到目前为止最常用的方法有Scrum，Kanban，XP和Crystal 等等。

在很多时候，有些朋友会问敏捷的概念是不是能够用在其他类型的项目上面。我觉得敏捷理论其实是为了解决在软件开发项目项目遇到的特殊问题而产生的方法论体系。并不适合推广到更加宽泛的其他工程项目的领域，当然的确也有某些人在鼓吹把敏捷方法用到其他行业，我觉得这个是不负责任的说法。即使是经过一定调整的敏捷项目管理方法，也只适合于知识产品生产领域的项目。更广范围的项目管理还是遵循PMP或者Prince2这样的通用方法论再加上行业相关的实践比较好。

我们可以对比一下传统的工程项目（如建筑，机械，化工类项目），在建筑领域，通常会有设计师设计需要施工的设计图；制造类项目会有工程师设计好要生产相应产品的生产线的设计图，并计划和设计每个工位的功能，机械和控制结构。然后再交给项目经理安排团队或者供应商进行施工和搭建。在整个过程中，每个环节和角色都有明确的功能和职责，而且也有明确的先后顺序和责任范围。在设计和制造的过程中通常也要遵循一定的行业标准。实施单位或者项目组通常不需要对设计和需求进行讨论，具体执行的人员只需要围绕他个人的工作完成即可，也不需要过多的交流。而且通常交流也是由上级到下级的单向指令为多，从下到上的反馈和沟通渠道在精益生产的实践的持续改进中虽然是需要的，但并绝对不要求过于频繁。只有工作内容有交集的工作单位之间才需要项目沟通，比如说挖掘隧道，两队人马从两个方向施工，最后需要在中间汇合，那在快要汇合的那个时间段，这需要沟通隧道挖掘的位置和进度需要相互了解的。而具体的进度和决策都是有项目的管理者来决定。

敏捷方法的一些基本概念包括 - 迭代，最小交付物，及时沟通，持续交付，去流程...这些概念如果用到传统的工程项目上一定会让整个项目成为一场灾难。如果某公司盖房子先弄一个没有厕所和阳台的，没有楼梯的最小可验证交付，然后再在后面的迭代中慢慢设计楼梯，窗户，厕所，然后添加上去...只能说这家建筑公司的项目离失败不远了。而在工程类项目中过多的沟通和交流，甚至将一些技术上的决策权下放，只会造成整个项目的混乱和无序。

那为什么软件和IT开发可以采用敏捷方法？而且经过实践下来，这是一个可行而且高效的方法论呢？我觉得其实主要有以下几个特点：

1. 软件产品总体上是知识产品，几乎所有成本是知识工作者本身的成本。提高开发人员的单位效率才能够提高整体项目的生产力

2. 软件类项目和其他研发类项目相同，有高度的不确定性，不能保证在项目设计阶段一次性完成所有需求设计并考虑到所有的技术难点和解决方案。随时都要准备设计，需求，资源和技术等方面的变更。

3. 无法用流程和制度来确保知识工作避免人为的错误发生（非设计错误），必须及时进行测试和验证才能确保减少错误。

4. 团队成员之间，团队与客户之间必须要保持及时和通畅的沟通渠道，以确保交付的产品符合用户的预期，同时确定工作的进度也是符合整体的要求的。

5. 软件开发人员通常受过一定的高等教育，掌握了一定的分析和研究方法，能够从不同角度提出问题或者解决方法。