为什么软件项目更容易失败？为什么要敏捷开发？

1986年，Transarc公司主席Alfred Spector写了一篇文章，将建造一座大桥与软件开发进行对比。他得出了一个结论：大桥通常能够按时、在预算内建造起来，而且通常不会倒塌，但是，软件几乎从来不按时，或者不在预算内完成。2008年，Standish又做了一项调查，这一年的数据显示项目成功比率再次下降，按时、在预算内交付，并且完成了应有功能的成功项目只有32%。

为什么软件项目更容易失败？

首要的原因是：软件项目存在一些本质性的困难，例如复杂性：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的；隐匿性：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难；配合性：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难；易变性：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。这种根本性的因素决定了软件项目的高复杂程度。

其次是不现实的计划或者期望。高级管理人员经常为IT项目制定不现实的范围、时间以及成本目标，这更容易导致欲速则不达的结果。有些高管不熟悉软件开发的特点和存在的根本性困难，更容易给出不专业的决定。

最后是研发团队与客户或者终端用户之间糟糕的沟通。在面临更多不确定性的时候，研发团队需要和客户有更紧密的沟通，但很多时候并没有达到需要达到的程度。

为了改善以上问题，应对软件危机，一些软件大师陆续提出了如增量软件开发方法、人月神话、重构等著作和实践。2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。

敏捷宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

我们认为，尽管右项有其价值，但我们更重视和强调左项的价值。

敏捷软件的十二条原则：

1.持续、尽早交付有价值的软件以满足客户，是我们优先要做的首要任务。

2.拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。

3.频繁交付可执行的软件，从几周到几个月，交付时间越短越好。

4在整个项目过程中，业务人员和开发人员必须每天在一起工作。

5.激发每个团队成员的积极性来打造项目。为他们提供所需的环境与支持，并且信任他们可以完成工作。

6.在一个开发团队内部最有效的传递信息的方式是面对面的交流。

7.可执行的软件是进度的首要检验对象。

8.敏捷过程倡导可持续发展。赞助商，开发人员和用户应该尽可能保持一致的步伐。

9.不断地关注优秀的技能和好的设计会增强敏捷能力。

10.尽量用艺术化来简单阐述未完成的工作是很有必要的。

11.最好的架构，需求，和设计出自于自我组织管理的团队。

12.每隔一段时间，回顾反思如何让团队变得更高效，并相应地调整其行为。

敏捷开发是一种软件开发方法，通过自组织的跨职能团队及其客户的协作来满足需求和实现解决方案。它倡导适应性规划，早期交付和持续改进，并鼓励对变化做出快速灵活的反应。敏捷是应对快速变化的需求的一种软件开发能力，能够帮助我们解决或者改善软件项目的问题。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。只要符合这两份文档的开发方法，就能让开发团队拥有应对快速变化需求的能力，这样的开发方法都叫做敏捷开发方法。如果能够遵循敏捷开发的理念，那么就能够更好地应对软件项目存在的复杂性和不确定性，让整个团队的沟通更顺畅、全面，当面临意外和变化时，做出更好的反应。

敏捷需要团队具备反思精神，要不断地审视项目和团队存在的问题，鼓励团队成员一起找到改进方法。团队成员会有参与感、成就感，团队成员之间能进行全方位的频繁沟通，避免矛盾的积累和爆发，维持积极健康的团队气氛；频繁的交付可执行的软件，则可以暴露项目风险，明确产品需求，改进产品质量，提升客户的参与感和满意度；一个具备反思精神的团队，即使发生方向性错误，也能够及时发现并作出调整，避免南辕北辙的后果；一个具备反思精神的个人，能够不断提升自己的能力，不断完善自己的设计和实现方案，交付更好的产品。

作者从事10多年的软件研发，深刻明白做到以上规则非常之难。高山仰止,景行行止,虽不能至,心向往之，即使我们做不到10分，只要我们往这个方向努力，就能够成为更好的自己、更好的团队，实现更伟大的目标！