一些专业顾问可能不希望你知道的东西：

　　你并不需要在你的开发过程中作出重大改变就可以从敏捷原则得到很多好处

　　如果你花时间去真正了解敏捷（而并不只是在网络上重复的徘徊于支持和反对中），你就会认识到事实上敏捷开发并不是一种方法论，而是一种可以应用于每个软件开发的方法。当然，像SCRUM（Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发）和 XP（Extreme Programming 极限编程）的方法都旨在制定敏捷原则的具体使用，但这并不意味着你可以通过这些工作方式来获得的敏捷开发的全部或大部分好处。

　　一些工作中使用到了敏捷可能你没有注意到

　　几个月前我们在与客户交谈的过程中，客户告诉我们，想要在工作中使用敏捷方法，但是在他们的团队中没有足够的时间实施SCRUM。该团队的经理提及曾经与一个SCRUM 顾问谈及敏捷开发的的实施，但是在进一步的考虑之后，他决定最好等待，直到当前产品发布，要在接下来6 到9 个月的时间实现所有必要过程的变动。

　　顾问的建议给经理留下了非常深刻印象，他要求团队做出小的变化同时开始实施的一些顾问建议的想法。因此，每天早晨在喝咖啡和吃点心之后开15 到20 分钟小会议以及他们开始组织2或3人的程序员团队并使其尽可能在短周期内完成任务，而不是让每个程序员单独完成这样可能需要长达6 到8 周的时间才能完成的任务。

　　他们所做的另一件事是让测试人员更早的介入工作，更紧密地与开发人员合作，在编码阶段开始，测试人员将对尚未完成的产品执行初步测试，也告诉程序员一些他们如何改善单元测试和集成测试的想法。作为这个过程的一部分，程序员也学到如何在提交修改之前自己进行部分的手工测试作为内部健全检查的一部分。

　　最后，经理要求整个团队在每个月的月底与产品营销人员安排一个正式的会议，并将演示相关特性功能的开发进展。在这些营销会议提供的反馈仍然可以实现当前版本发布而不延迟版本发布。经理告诉我们，自从他们开始用这种方式工作，大大提高了团队的生产力和工作气氛，他真的很期待他们的团队实现SCRUM。

　　他不理解的是，他们的工作方式并没有做任何革命性的改变，他们就已经实施了部分的敏捷开发并且从中体验到敏捷的好处。

　　小的变化和改进之路

　　这个经理的故事是一个很好的例子。如何在你的整个工程中使用小的改变来实现敏捷就能实现很多你想获得的结果并不需要开展一场彻底的革命。

　　以下是一些想法，可以从上面的故事得到证明，我们相信，无论你的团队目前正在使用哪种开发方法都可以快速实现敏捷。

　　（1）小/更小块的工作

　　把工作分解成更小的，更易于管理的块，而不是少量的非常大的需求或任务，可以在更短的时间间隔内（数天或数周）完成。通过这种方式确保任务不比你原先分配的占用更多的资源（因为如果你的计划设想开始在工作中出错，你会在2周内而不是2-3个月才发现它），最重要的是，你会更快地交付功能给测试人员和产品营销人员，并得到及时反馈，进行必要的修正和调整，而不会影响你的发布日期。

　　（2）增加程序员和测试人员之间的协作和沟通

　　如果这个想法是为了使开发人员尽快得到功能的反馈，那么最好的办法是更早开始测试，很多时候，即使是在平行开发时也是如此。

　　你可以通过多种方式实现这一目标，例如通过一准备好部分功能就邀请测试人员直接在开发环境运行其测试，（而不是等到所有部分都完成的时候）。

　　另一种方法是测试人员与开发人员合作来计划和写单元和集成测试的方式，这将有助于测试人员更迅速地捕捉到更多的错误。最后，如何能让我们开始教程序员怎样运行少部分的由测试人员编写的手动和自动测试程序，作为他们在提交代码之前的健全性测试的一部分？我们看到很多的团队，在开发人员提交代码的主要分支之前他们需要运行开发自己的测试集进行测试。

　　（3）有更多的自动化测试以及更多经常运行它们

　　这是应用敏捷的团队的首要原则之一，事实上，也是符合每一种类型的项目逻辑。作出承诺，有意识地投资自动化。

　　首先，指导你的开发人员为每一个新功能或重要的错误修复，创建单元测试和集成测试。

　　你也可以让你的测试团队创建自动测试，以覆盖尽可能多的产品，并指导你的开发人员使用这个功能的自动化更简单，更强大（例如，通过使用GUI 元素中正确的仪器）编码方法。

　　但是，创造你的测试是远远不够的。你需要有一个框架，尽可能多地运行这些测试，并在测试发现缺陷时即时反馈给程序员。

　　现在，有很多很好的持续集成框架（如 Jenkins1，Bamboo2 或TeamCity3），所有这些都可以利用我们强大的API 集成到实践测试中。最后，你也将确保你的程序员遵守“你把它弄坏了，立刻你修复它！”的黄金规则。