《硝烟中的Scrum和XP》第13章 我们怎样结合使用Scrum和XP

第13章 我们怎样结合使用Scrum和XP

• Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题，可以互为补充，相得益彰

结对编辑

1. 结对编程可以提高代码质量
2. 结对编程可以让团队的精力更加集中。（比如坐在你后面的那个人会提醒你，“嘿，这个东西真的是这个sprint必需的吗？”）
3. 令人惊奇的是，很多强烈掏结对编程的开发人员根本就没有尝试过，而一旦尝试之后就会迅速喜欢上它
4. 结对编程令人精疲力竭，不能全天都这样做
5. 常常更换结对是有好处的
6. 结对编程可以增进团队间的知识传播，速度快到令人难以想象
7. 有些人就是不习惯结对编程。不要因为一个优秀的开发人员不习惯结对编程就把他置之不理
8. 可以把代码审查作为结对编程的替代方案
9. “领航员”（不用键盘的家伙）应该自己也有一台机器。不是用来开发，而是在需要的时候稍稍做一些探索尝试、当“司机”（使用键盘的家伙）、遇到难题的时候查看文档，等等
10. 不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试

测试驱动开发（TDD）

• 测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续
• 人们对测试驱动开发有着各种看法

1. TDD很难：开发人员需要花上一定时间才能掌握。实际上，往往问题并不在于你用了多少精力去教学、辅导和演示——大多数情况下，开发人员掌握它的唯一方式就是跟一个熟悉TDD的人一起结对编程，一旦掌握以后，他就会受到彻底的影响，从此再也不想使用其他方式工作
2. TDD对系统设计的正面影响特别大
3. 在新产品中，需要过上一段时间，TDD才能开始应用并有效运行，尤其是黑盒集成测试。但是回报来得非常快
4. 投入足够的时间，来保证大家可以很容易地编写测试。这意味着要有合适的工具、有经验的人、提供合适的工具类或基类，等等

在新代码上进行TDD

• 我们在所有 的全新开发过程中都使用TDD，即便这会在开始时延长项目配置时间

在旧代码上进行TDD

• TDD是很难，但是在一开始没有用TDD进行构建的代码库上实施TDD……则是难上加难！
• 吸取的教训：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行

增量设计

• 这表示一开始就应该保持 设计简单化，然后不断进行改进；而不是一开始努力保证它的正确性，然后就冻结它，不再改变
• 持续的设计改进，这在很大程度上是TDD自动带来的成果

持续集成

• 如果出现问题，它就会向整个团队发送邮件告知大家构建失败，在邮件中会包括有哪些代码的变化导致构建失败的精确细节，指向测试报告的链接等
• 每天晚上，持续构建服务器都会从头构建产品，并且向我们的内部文档门户上发布二进制文件、文档、测试报告、测试覆盖率报告和依赖性分析报告等等。有些产品也会被自动部署到测试环境中。
• 把这一切找寻起来需要大量工作，但付出的每一分钟都物有所值

代码集体所有权

• 在结对编程中频繁交换结对，会自动把代码集体所有权提到一个很高的级别。我们已经证实，如果团队拥有高度的代码集体所有权，这个团队就会非常健壮，比如某些关键人物生病了，当前的sprint也不会因此有问题

充满信息的工作空间

• 所有团队都可以有效利用白板和墙壁空间。很多房间的墙上都贴满了各种各样关于产品和项目的信息。这样做最大的问题，就是那些旧的作废信息也堆在墙上，也许我们应该在每个团队中引入一个“管家”的角色

代码标准

• 只需要写下不是所有人都了如指掌的事情，并尽可能加上对外边资料的链接
• 代码标准中一些例子

1. 可以打破这里的任一规则，不过一定要有个好理由，并且记录下来
2. 永远不要在没有记录堆栈跟踪信息或是重新招聘异常的情况下捕获异常。只要别丢失堆栈跟踪信息就行
3. 避免缩写。为人熟知的缩写则可以，例如DAO
4. 需要返回Collections或者数组的方法不应该返回null。应该返回空的容器或数组，而不是null

可持续的开发速度、精力充沛地工作

• 很多有关敏捷软件开发的书都声称：加班工作在软件开发中会降低生产率
• 经过几次不情愿的试验之后，我完全拥挤这种说法！
• 当然，减少工作时长绝不是带来改进的唯一因素，但我们都确信它的影响很大