相信做软件开发的我们，大家都有这样的体会，当我们辛辛苦苦的熬了几个月的通宵、加班后，终于完成了客户提出的V1.0功能需求，当我们大家准备按部就班的进行系统上线时，客户、企业用户突然改变了需求，不想这么做了，提出了新的需求，新的变动，这样对于我们整个团队来说，正如晴天霹雷，很恐怖的事情啊，因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。     需求变更

先来看故事来    故事情节    现在回想起来当初做人事的时候，那是叫一个惨啊，记得有一次是客户那边的需求修改了，加上原来我们对于业务了解的不是很熟悉，又加了三个大将（响、江江、亚光）来参与，我和唐欢完成一些功能算是V1.0版吧，后来客户需求发生变化，功能加多、内容开始复杂起来，通过现有的变更业务需求整体分析，大家一致决定，还是重新做吧，因为如果在V1.0上继续修改，修改的代价远远大

开发要有开发文档（需求文档、数据库设计、概要设计）、开发计划（甘特图、燃尽图）、测试计划（时间、地点、人员、任务模块分配、禅道bug提交管理）都应该有一个时间段，在大家的一起商量之下可以每个人做到心中有数，对任务整体有个全局观，我们每天该干什么？紧急重要的需求？客户迫切需要上线的功能？都有一个好的规划，避免在不必要的文档上（官话、客套话）浪费更多的时间，劲使在刀刃上，提高我们的开发效率，有明确的目标、去按照我们的计划一步步的完成。 各个工作流自有它的价值……努力吧，继续深入理解敏捷开发理念！

首先接触这个词是从师哥的博客中学习到了（看博客的好处啊），由于在人事系统中一直在敏捷开发的思想在指导者，遇到了很多的新的理念、新的开发方法、新的指导思想，都是值得在项目的开发中深刻的去体会和运用的，毕竟这个大公司（特别是外企）都在使用，可见其在项目的管理中起着很重要的作用，今天和大家一起分享一下---结对编程故事情节：前两天我们开发中遇到了一些问题，徒弟在尝试通过调试解决， 结对编程技