下面研究一下软件开发中的一个典型场景。软件开发人员 Zoë 在 Web 浏览器中刷新“My Bugs”页面，并看见团队负责人 Rick 已分配给她一个新的错误报告。她打开 Eclipse IDE，并在工作区中查找出错的代码。她修复该错误并向测试套件添加一个递归测试。她运行测试套件以确保一切都按预期工作。她更新构建说明，以记录代码流中的该错误已修复。然后 Zoë 可以将她的所有更改签入源代码存储库，并使用错误报告编号和标题作为签入备注。然后她使用将在其中应用修复的计划的构建版本，对该错误报告做出注释，并将该错误报告标记为“已解决/已修复”。更新错误报告会自动导致向相关各方发送电子邮件，包括报告该错误的团队成员 Mike。一旦某个构建版本变得可用，Rick 将下载该构建版本，验证问题已修复，并将该错误报告标记为“已解决/已验证”。
这个小插曲对于许多软件开发人员来说实在太熟悉不过了——甚至有点单调——但是从整个团队的角度看，其中发生了几件非常有趣的事情。修复错误的工作在团队中流动，从发现并报告问题的 Mike，到复核传入的错误报告并将该工作分配给 Zoë 的 Rick，到修复该错误的 Zoë，并最终返回到 Mike 以进行验证。错误修复本身也在团队中流动，从修复代码流中的该问题的 Zoë，到验证包含该修复的构建版本中的修复的 Mike。这些流可能非常脆弱。如果签入某个修复而没有更新错误报告，或者如果不存在将修复与特定代码流和构建版本联系起来的纽带，则团队中的流就会中断。这些中断会在团队中导致混淆并妨碍进度。更糟糕的是，中断也许不会立即在团队中的任何人面前表现出来。与领域相关的工作（例如，为软件产品编写代码）和主要与维持团队协作相关的工作（例如，在修复错误时标记错误）之间的交织也是非常令人生畏的。
查看IBM developerWorks专区中的原文>>
（责任编辑：云子）
