敏捷交接

关于敏捷项目，我最常看到的一个问题是，它们如何处理向另一个团队的交接。如果你有一个开发团队离开并将支持工作移交给一个支持团队，那么当敏捷项目往往比计划驱动的流程产生少得多的文档时，他们如何应对？

你需要考虑的一件事是，问问自己，另一种流程产生了多少有用的文档。我注意到，那些强制要求编写文档的流程往往会产生一些没有多大帮助的东西，而且在截止日期的压力下，这些东西往往不会得到更新。在很多方面，敏捷方法更倾向于少量高质量的文档。

敏捷项目更喜欢面对面的交流，所以一个我经常遇到的常见方法是，在开发团队离开之前，让支持/维护团队的成员与他们一起工作一段时间。通过让两个团队同时在场一段时间，开发团队可以在维护团队使用系统时向他们讲解系统。我遇到过很多关于这个主题的变体。

• 一个团队在每次迭代中轮换一两个人，在两三个月内逐渐替换整个团队。
• 当我们将项目转移到印度时，我们确保一名在岸开发人员至少在离岸工作几个月，与新团队一起工作。
• 一个团队在开发的最后一个月安排了一名支持人员加入。

最后一个例子来自我的同事乔纳森·拉斯穆森（Jonathan Rasmusson），他指出，在开发结束时引入一些支持团队人员的另一个好处是，它可以建立起关系，使新系统的部署变得更加容易。开发和运营之间的沟通往往很紧张；开发人员经常忽略运营的需求。让运营人员成为团队的一员一段时间，有助于双向沟通。

这又让我回到了文档问题。乔纳森提到的一件事是，他们让支持人员充当系统文档的客户。因此，他们制作的文档比他们通常看到的要好得多。

乔纳森后来自己也尝到了自己做的“狗粮”的滋味，当时他带着一个全新的团队回来做一些改进。他们发现这些文档非常有用，因为它是按需编写的，而不是根据流程编写的。质量战胜了通常的数量。另一个了解该系统的重要帮助是 XP 大量的自动化测试，正如 XP 爱好者们一直强调的那样，这本身就是一种重要的文档形式。