（4）寻求快速反馈和持续改进
改善最大的敌人是人类行为：没有人喜欢被批评，我们指的就是没有任何一个！
这就是为什么每当我们在做某件事，我们不愿意展示给别人，除非我们认为它已经完成了，我们的观众能够“完全”理解我们所做的。
但正如你可能已经明白，这是反作用于编程的，因为如果我们等太久才得到反馈，我们不可能实现任何变更而不错过我们的交付目标。
那么，你能做些什么呢？
基本上，克服害怕被批评的心理，作为一种政策要求，在工作中每个人展示给其他团队成员以及产品行销人员他的工作过程。
营造一种企业文化让人都知道如何给予和接受反馈。你通过确保反馈针对的是工作，而不是人，同时让人反馈产品的好和坏的方面（而不是只集中在需要修复的部分）来可以实现这一目标。
起初，这可能不是一件简单的事，但它会随着时间的推移会变得容易，从中获得的价值简直是不可思议的。
（5）拥抱变化和有序工作
这可能是敏捷实现的基石，无论你如何努力工作规划你的项目，无论你有多擅长，最终事物会改变，你需要调整你的计划。
但是，除去口号，你该怎么拥抱变化呢？
首先，计划要少，不要深入但是要有，减少长期的，因为你无法准确地预见现实到底是几个月。
寻求反馈宜早不宜迟，确保，如果你不得不改变功能和计划，你在2.4周时知道，而不是6至9个月。
为改变做计划，并确保你的团队知道，变化确实会来，而且它会被接受，这使得他们当他们面临着这一现实和需要时，更容易应付它。
小的变化应该是你工作方法的一部分
你可以从敏捷的理解中获取最好的原则之一，正如产品和需求是不断变化的，所以你的工作流程应该是动态的，自适应。
能接受被提问关于你是否工作在最好的和最有效的方式，或者是是否你能在过程有或大或小的改进？
能接受反馈，寻求它，甚至奖励给出反馈的人。一旦你能够引入接受反馈的企业文化，你将看到如何真正开始改善，甚至是他们自身。
注：
1、Jenkins，之前叫做Hudson，是基于Java 开发的一种持续集成工具，用于监控秩序重复的工作，包括：
I、持续的软件版本发布/测试项目。
II、监控外部调用执行的工作。
2、Atlassian Bamboo是一款持续集成构建服务器软件（Build Server）（非开源软件）。Bamboo 的特点： 简单的用户界面容易安装-顺利的话，5 分钟内就可以让运行起来！自动检测你的设置 - 如果你的Server 上使用了Maven，Ant 或者Java 设置， Bamboo 会自动检测他们； 连续的日志 - 监测你的build 的colour coded 日志；容易显示所有项目。
3、TeamCity是一款功能强大的持续集成（Continue Integration）工具，包括服务器端和客户端，目前支持Java，.NET项目开发。
TeamCity 提供一系列特性可以让团队快速实现持续继承：IDE 工具集成、各种消息通知、各种报表、项目的管理、分布式的编译等等，所有的这些，都是让你的团队快速享有持续集成带来的效率提升、高质量的软件保障。
使用 TeamCity，你能够在几分钟之内为你的项目配置一个构建服务器，它内建了持续单元测试，代码质量分析和早期的构建问题分析报告，你甚至可以在IDE 进行。
TeamCity提供平滑的学习曲线，你可以逐步的学习经它的高级特性和功能，你很快就能加强你发布管理实践。本次发布，在可用性作了大量的改进，更新的IDE 插件支持 CVS 和SVN，另外还包括一些之前版本不具备的企业级的特性。一些专业顾问可能不希望你知道的东西：
你并不需要在你的开发过程中作出重大改变就可以从敏捷原则得到很多好处
如果你花时间去真正了解敏捷（而并不只是在网络上重复的徘徊于支持和反对中），你就会认识到事实上敏捷开发并不是一种方法论，而是一种可以应用于每个软件开发的方法。当然，像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 集成到实践测试中。最后，你也将确保你的程序员遵守“你把它弄坏了，立刻你修复它！”的黄金规则。