上文我们具体举例了几个开发的实践，那今天我想说下这些开发的实践对团队的 影响。尤其是那些远程团队的影响。
首先让我们说说：测试驱动开发，这个是Beck先生在XP在3C中曾经使用的一种实践。具体的实施方法可以参考这里。
它其实打破了以前在功能团队（Function Team）中的开发扔过墙的问题。根据80/20原则（二八原则），如果开发使用了更多的精力来做“完” - 这里不得不又提及DoD，自己的事情，那么可以节省测试人员大量的精力。
这种做法的好处不仅大大提高了产品（增量）的质量，另一个方面更可以使测试自动化测试的覆盖率达到一个新的高度。以减少代码的缺陷率和不稳定性，不过其制约也是相当明显的尤其是在某些方面（例如前端代码），可能无法实现很高的覆盖率。而且即使很高的单元测试的覆盖率也无法替代功能测试、系统测试等在外部依赖等在复杂情况下全部情况。无论如何，它还是质量体系中不可或缺的一道环为敏捷的高频率交付打下坚实的基础。
在多团队中，测试驱动开发能一样能帮助团队提高代码的质量。减少因自己的修改失误而导致的缺陷或者强依赖的产生。作为质量门的一部分存在于持续集成之中，帮助团队更快的得到反馈及调整，即使在不同的时区。另一个方面，这个也是知识传递的另一种方法。
另一个大家耳熟能详的工程实践就是结对编程（Pair Programming）了：
其详情，大家可以参考这里。
结对编程是一种合作的、反直觉的工作方式。它可以提高代码的质量、提高团队内知识的传播率、有助于团队成员的交流、提高了工作的效率。以前结对编程仅仅存在于单一团队之中，而现在随着通信工具的发展，其也开始慢慢出了变体，如远程结对也和单一团队中的结对编程一样发挥着作用。
最后我不得不提及持续集成（CI）和持续交付（CD）：
CI也是XP中用到的实践，根据马丁福勒的建议。持续集成应当在一天中至少一次或者多次的进行。现在，随着云的大量使用。很多公司已经不满足于每天的个位数集成了。他们的集成和发布速度可能以小时、分钟设置秒来计算。这不仅是单一团队，更使多团队从中获益。团队可以更加频繁来做验证，以防错误的发生。反过来说，持续集成和交付又依靠自动化测试包括自动化单元和系统测试等。
测试驱动开发、结对编程、持续集成等等都是经过相当长时间积淀而出的卓越工程实践技术。可以帮助团队大大提高开发效率和质量。
网友评论