拆出一个只关注架构的团队
我们的项目只是整个应用链条中的一部分，必须要跟客户现有的IT基础架构无缝挂接。虽然我们的产品负责人对核心功能需求非常熟悉，但是在安全、日 志、可用性、性能等方面就所知甚少了。要从客户的组织中了解这些需求难度很大，因为这得跟不同部门中的许多人沟通讨论。这种调查工作给Scrum的迭代节 奏拖了后腿。为了解决这个问题，我们创建了一个独立团队，他们只关注架构方面的内容。他们的工作就是弄清楚非功能性需求，好让我们把它们转换成 backlog中的用户故事。我们用“Scrum of Scrum”会议来跟特征团队沟通。我们都喜欢这种方式，因为特征团队可以全速前进。而且有些员工也喜欢在“架构团队”中工作。
文档
客户要求大量的文档，而且还要符合MIL文档规范。还要用荷兰语写。很明显，这项工作只能由荷兰人来干。而且开发跟测试都不熟悉MIL规范，写用户 手册这样的文档也不是他们所擅长的。所以我们决定雇一个曾经写过MIL文档的技术文案。开发跟测试可以继续关注于各自职责。这个做法也很成功，不过我们发 现这也要求技术文案和其他团队成员之间也要有大量的沟通交流，这是需要引起注意的，因为开发人员只想“做他们该做的事情”。
需求管理
我们的产品负责人是一些业务分析师，他们习惯于用荷兰语写出大量的需求文档。而在我们的过程中，只要backlog中有用户故事，产品负责人也能在 计划会议上做解释，这就足够了。但是客户又要求有很多文档。所以我们打算和产品负责人一起把需求翻译成用户故事。结果就是需求被放在了两个地方：需求文档 和 backlog。当需求发生变化的时候就会导致问题。我们做了大量的辅导工作，确保产品负责人不仅仅是关注需求文档，也要负责backlog。
有了一行文字表达的用户故事，再加上产品负责人的解释，我们的Scrum团队就可以构建和测试软件了。不过需求文档对外部的测试团队做测试还是很有价值的，虽然在好些迭代里面，我们很难把实现的用户故事跟需求文档中的某些部分“映射”起来。
回顾从前，我们其实一直都没有一个理想的需求管理过程。我们只是尽了最大努力，来应对这相互冲突的需求：我们需要用户故事，客户需要详细的需求文档。
