第10章 使用BDD的情况 《RSpec手册》
我们所写的大多数软件永远不会投入使用。这不是某个人的错，而是作为一个产业来说，我们经常无法提供人们需要的软件。事实证明，传统的软件开发方法是失败的，并且这种方法就是让我们无法交付可用软件的根本原因。
尽管存在一些成功的个案，但这通常不是传统软件方法的功劳。在本章，我们要看看敏捷软件开发过程需要面临的挑战。
传统项目失败的几种情况
传统项目失败的原因有很多。什么情况下项目会失败，你可以问问你的项目经理，是什么因素让他们夜以继日地加班。他们很可能回答与我们给出的列表相似的答案。
进度逾期或超出预算
我们估算，我们计划，我们尽量采用备选方案，仍然不得不在最后关头对结果失望。第一次的进度延期，没有人会在意。毕竟，只是几个星期的时间。情况仍然会继续，随着一周周、一月月的进度拖延，同时不断有人离开、加入，项目组会越来越感到痛苦。项目延长到一年半到两年是很常见的情况。这就是没有价值的软件。
交付错误的东西
我们使用的软件大多数都是延期并且超出预算——无论是桌面应用，移动应用，还是办公或家庭中的应用。事实上，我们已经习惯了通过服务包、系统更新来获得更新软件的bug和新功能，或者通过网站下载软件的新版本。然而，只有是被提出的问题几乎都是可以解决的。
令人惊讶的是，即使软件开发后期已经能确定很多新功能比现有功能实用得多，我们仍然要花费大量的精力按照原有的计划和预算做项目管理。没有实用价值的软件就这样被生产出来了。
产品不稳定
太好了！项目如期完成，也没有超出预算，用户看过之后也很喜欢，所以我们把它部署上线了。问题是这个东西一天之内崩溃两次。我们猜想可能是内存问题、配置问题或者什么鬼东西在跟我们开玩笑？这个问题花费了我们大量的时间和精力，也造成了客户的经济损失。在崩溃几次之后，用户很快就决定放弃它。这同样是没有价值的软件。
花费太多精力维护
如果所写的是一次性软件，有一些事情我们是不会考虑的。可维护性就是其中之一。然而，当我们期望按照1.0版、2.0版、3.0版甚至超级牛X版来发布软件的时候，我们会因为没有考虑可维护性而付出代价，甚至陷入死角。
随着时间的推移，团队会逐步失去提供新功能的能力，因为不得不把大量时间和精力花在那些回归测试和意大利面条式的代码分析上。这仍然造就了没有价值的软件。
传统项目失败的原因
大多数失败的项目仍然是一群聪明、敬业的人实施的。通常，他们花费了大量的精力、时间和心血，因此项目最后失败时遭遇“问责风暴”时，项目组成员会非常伤心。将责任完全归咎于项目团队，确实不太妥当，这其中必定另有原因。
传统项目的工作模式
大部分软件项目都是按照规划、分析、设计、编码、测试、部署等顺序完成的。你所参与的项目可能对这些过程有不同的叫法，但所指的应该都是对应的那个过程。
我们通常要从规划阶段开始。需要多少人？需要多长时间？需要什么资源？当然，还有最根本的问题，实施这个项目需要多少资金投入？多久之后我们能开始用它？
接着我们进入分析阶段。这里主要落实我们需要解决什么问题，以及怎么去解决。
然后是设计阶段。当我们把解决问题的方式用计算机软件来实现的话，那么就要搞清楚这个软件的内部结构。
现在要进入编码阶段了，我们要根据设计阶段的成果来编写代码。这个阶段虽然是程序设计，但通常被认为是力气活，没什么想象力发挥的空间，按照已有的设计完成任务就是了。因此，一些组织会安排外包的团队或第三方机构进行开发和测试。
紧接着，我们可以测试了，检查所编写的代码是否符合设计要求。通过测试之后，新的软件就可以部署上线了，同生产线上新买的一台机器一样，它应该能帮助用户赚钱了！
所有这些过程都是必须的。你不可能跳过任何一个阶段，无论你有无设置每个过程对应的岗位，还是有无为每个过程配置专属团队。
传统项目的真实情况
人们使用这种传统方式做了很多年软件项目。这个过程中，也积累了不少有用的方法和技巧，例如规范化文档、使用模板等等。
对传统过程讨论最多的是，随着开发过程进入到后半段，人们会发现一些设计缺陷或希望做一些需求变更，但要完成经常要付出高昂的代价。如果是一星半点的问题也就罢了，但事实上，多年的经验告诉我们，这类问题会像滚雪球一样越来越严重。解决这类问题的通常做法是，在前期规划、分析、设计这些阶段，尽量三思而后行，以避免错上加错的悲剧不断发生。
这还不是全部问题。
（介绍敏捷开发与传统项目区别的书籍很多，暂时翻译到这里，就浪费时间了）