|
总体来说，很多团队都会过高评价同时实现多个用户故事的效果。这样做从开发速度上说感觉好像不错，但却只是一个幻象;因为它将有风险和消耗实践的编码工作推到了最后——包括合并、集成与测试等工作。项目管理者联盟
这就是Scrum团队应该保持小规模的原因(少于9个人)——这样他们就可以紧密协作而且将注意力集中于自己的工作成果之上。如果任何人都在独立开发自己负责的用户故事，那大概就不会有多少协作的情形发生了。当然可以有人为将来做计划，为下一个故事做准备并做一些实现工作。但是在任何时候，团队的主要工作努力都要放在优先级最高的故事上。项目管理者联盟
多个团队就是不同的情况了。如果很想并行实现多个故事，那就不妨创建多个团队。我们不久后就会看到如何具体操作。首先我想讨论下关于回归测试，以及分叉代码的相关话题。项目管理者联盟
完成包括回归测试在内的工作项目管理者联盟
当一个故事“完成”后，我们会把它移入到“完成”一栏中，并将相关内容从工作分支拷贝到主干中。主干必须一直保持可发布状态。此处有一个重要的暗示。项目管理者联盟
规则：任何接触到主干的人，必须保证整个主干保持可发布状态——包括之前的全部功能!项目管理者联盟
实际上，这条规则意味着：对故事A的测试，同样包括运行之前实现的故事的全部相关回归测试。如果上传代码后，故事A没有问题，但是之前故事的测试却通不过了，这是不行的。项目管理者联盟
稍等。这是不是有点不合理啊?每完成一个故事就要运行所有的回归测试?www.mypm.net
嗯，首先我没有说运行所有的回顾测试。我是说所有相关的回归测试。我们已经有了一个干净而且可发布的主干作为基础，现在只是要添加一个故事而已!这是一个很小的增量变更。如果回归测试可以自动化完成，我们就可以全部运行了。要是有需要手工完成的回归测试，那我们就要有选择性了。项目管理者联盟
最后还是归结到了对风险vs成本的权衡之上。对于每一个手动的回归测试，我们应该评估运行它的成本(比如需要多少工作量来完成测试)，同时评估发现任何重要缺陷的可能性，对二者进行权衡。当然还要加入自动化该测试的成本。:o)项目管理者联盟
分叉代码(合并冲突)项目管理者联盟
假设我正在兴高采烈地编写调用Widget类的代码，我却不知道团队成员Jim在一个小时之前进行重构时移除了Widget类。现在我们就有了< b>分叉代码。在花费更多时间编写其他调用Widget类的代码前，我希望尽早发现类似问题。项目管理培训
规则：持续不断地(等同于尽早)将你的代码同步到工作分支中。项目管理者联盟
这种同步是双向的。从工作分支中取得并合并最新的代码，然后检入你的代码。第一步可以叫做“跟上”(等同于我要知道其他人检入了哪些内容)。第二步可以叫做“公开”(等同于我希望我所做的更新可以让团队其他人都知道)。项目管理论坛
每小时同步一次是好习惯，基本上在进行任务切换或者没有处于某项工作进行中时，就可以进行同步。这不只是关于“我要尽快知道别人的代码是否与我的相冲突”，还包括“我希望其他人尽快知道我的代码是否与他们的冲突”。要记得不要违反工作分支的方针(通过单元测试等等)。service.mypm.net
该规则听起来很浅显，但是请允许我不断重申。我希望大家都能对其一清二楚，因为涉及到多个团队协作时，我们会再次使用类似的思维方式。项目管理者联盟
多个团队——如果其他团队同时向主干中发布代码该怎么办?pmp.mypm.net
假设有团队A和团队B。他们都是跨职能团队，并且一起开发一个航班订票系统。团队A的注意力放在开发订票流程之上，而团队B主要负责开发后台相关功能。项目管理者联盟
假设他们现在要开始一个sprint，每个团队有两个用户故事要开发(通常一个sprint中会有更多的故事)。项目管理者联盟
项目管理者联盟
由于每个团队都要在发布代码到主干前进行测试，因此他们有各自的工作分支。项目管理者联盟
项目管理者联盟
现在我们遇到了一个有趣的问题。假定我在团队A中，而且有我们自己的工作分支。变更可能先在主干中发生，而不会先出现在我的工作分支中!为什么?恩，因为有另一个团队啊，他们每完成一个故事就会将其发布到主干中!项目管理者联盟
所以在任何给定的时刻，在主干上都可能有我不知道的新代码。而且这些代码可能(但愿不会如此)会与我的代码冲突!也许团队B中的某人会重新命名Widget类，可我已经在代码中调用了它而且……呃……等一下，我们不是刚讨论过这个话题了么?项目管理者联盟
没错，是同样的问题。解决方案也相同。但是范围有一点点不同。项目管理者联盟
|
