更重要的是，缺少正式的程式会增加不可预见的更改带来影响的风险。如果缺少文档，后续的开发人员不能很好地理解软件的各个方面，以及如何运转，将会增加犯错误的机会。而且缺少需求和用例，将来的测试人员会更容易漏测一些功能。
对于很多人来说，敏捷给人的感觉是把小心谨慎抛之“九霄云外”，一头扎进混乱中去。毕竟，传统的过程已经被认为是不必要的了 – 从课程上学到的。
扩大包括的范围
尽管瀑布模型和类似的模型有存在的理由，但是其中的很多理由已经不再成立。早期使用计算机的目的是通过把手工过程加速来提高生产率，代码被小心翼翼地通过图表设计，并且从头到尾手工构造出来。软件开发可以 - 并且也确实是 – 花上几年的时间来完成。
然而今天的软件则专注于竞争 – 让过程和产品不能被手工复制，通常通过快速地组装各种组件和服务。不再是为了生产率，而是持续发展。整个市场形势可能在一年中剧烈地改变，因此速度不仅仅是需要的，而是必要的。每人会关注一个在4月16号以后发布的税务软件，即使它是多么的优秀。
那么你如何弥补因为缺乏正式的程式和更短的周期规划带来的风险呢？把所有利益相关方包括进来。
与其使用文档来与用户、分析师、开发人员、测试人员和技术文档编写人员进行信息的交流 – 这些人中的每一位都负责进度表中自己的那一部分任务 – 敏捷方法要求即时的、直接的、面对面的交流。讲和听会比读和写花费更少的时间，通过讨论要比通过编辑文档更容易暴露不确定性。这样，通过上下文来驱动进度，而不是通过其他方式。
但是这种方法的最显著的影响莫过于不再是业务需要IT企业的发布日期，而是业务决定什么时候得到自己的需要。这种责任的转移是关键的，因为IT企业不再负责“按期”发布，更需要防范变更。
这是管理层在考虑敏捷时经常遗漏的。经理们设想敏捷改变了IT操作方式，实际上，敏捷需要整个组织的改变。除非大家接受了这个新的模型中的角色和职责，敏捷开发只是一时的狂热，承诺的比实际得到的少。
文章来源于领测软件测试网 https://www.ltesting.net/
