许多组织面临采取敏捷的挑战，特别是当他们试图完全取代一个熟悉的传统方法时。为了缓解调整，管理者可以考虑采用敏捷的原则，可以无缝集成现有方法。

    软件开发的瀑布模型和其他非敏捷方法工作得很好，因为在写一行代码前，他们强制创建部分或全部要求，功能规范，技术规范和技术架构文档。然而，他们不能很好的工作，因为往往在软件交付之前你需要等待几个星期或几个月，并从最终用户那里发现自己一直偏离航向。敏捷方法将结束这种闭塞的通信缺口。

    敏捷开发者做了一个发布版本和演示，让最终用户可以操作使用，并且在开发周期的早期需要做的航向修正方面提供反馈。你并不需要等待数周或数月来发现，开发的软件是偏离航线的。最终用户能够更早的使用软件并且在你是否处于正确方向上提供反馈。

    在软件开发工作中，最终用户和开发团队之间的沟通是最大的问题。如果你早日解决通信问题，那么开发工作将更加顺利。敏捷背后的主要原则之一是杜绝任何程序后面的浪费。浪费可以有许多形式--比如说不必要的和浪费的人力资源，软件代码的延误和返工方面的时间浪费。

    你可以用下面的方法把敏捷方法背后的基本原则融入到其他方法中：

    消除一切不必要的和表面文章的文档：功能规范，技术规范和技术结构文档都应该是可选的，要根据具体情况选择性使用。如果是一个持续时间短的项目，所有这些文件应该全部消除。其中的每一个文件都应该考虑其效用，在我们开始编码之前，组合成一个或者全部消除。

    尽快创建一个临时凑合的（水平不高的）的文件来阐明设计：一旦我们过了规范阶段，每一个项目的开发团队创建一个高层次的设计文件，即使它仅仅只有几页。这只是用户界面的功能模型设计。究其原因，是为了最终用户能够尽早得到一个用户界面的预览。开发团队得到一个问问题的机会，并在进行编码之前把所有事情阐明清楚。

    增加定期构建和发布以供交流和提高代码质量：不要在版本发布之前等待几个月，做一个项目计划，把开发和测试划分到周，10天，或最多每两周建立一个发行周期。在这些日子里，如果没有失败，就是一个发行版本。这样做的原因是灌输生成和发行的纪律。每一个版本只有正式测试，本地化才能发布。这也保证了软件测试比在一个纯粹的瀑布模型次数多，并间接的提高了软件的质量。

    使用在线，自动化的问题/缺陷跟踪系统以便更好更快地沟通：沟通速度是敏捷方法的最大好处之一。问题，争议和缺陷能够更早的得到沟通和解决。一个自动化，网络问题/缺陷跟踪系统，很好的与电子邮件系统集成，当和其他方法整合时，实现相同的益处还有很长的路要走。

    把项目状态会议改成半站立会议：敏捷站立会议有助于在开发周期的早期阶段识别问题和障碍，解决这些问题并扫除障碍。开发团队甚至可以每天做敏捷站立会议。当使用其他方法时，每日站立会议是没有必要的，但是把项目状态会议周期从每月或每季度到每一个或两个星期，同样可以达到目标。

    通过跟踪发布完成的功能衡量项目速度：当敏捷项目经理通过跟踪构建和发布完成的故事来衡量项目速度时，他们对开发进度快慢会有一个认识。团队使用其他方法可能也需要对每一个版本他们完成了多少功能有一个认识。增加发本的频率比以前更能帮助跟踪项目速度。

    总结

    敏捷方法帮助弥合交流缺口，更早的识别技术困难和用户界面问题。他们还消除了很多不必要的文件浪费，不必要的，浪费的设计和编码的努力。频繁的发布和项目管理会议，确保更早的确认和确定航线修正。通过识别什么与敏捷方法一起工作，和为什么一起工作，当使用其他方法时同样可以逐渐的融合。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。