有一天我在会议室还没结束上一个会议，忽然电话会议呼进来，接进会议，感觉气氛有点不对劲。回到座位，问清楚缘由，原来是BA和开发因为一个需求点在争执。他们争执的不是需求本身，而是该需求点是否形成需求文档，以及何时形成需求文档？！

敏捷核心价值观强调“可以工作的软件胜过面面俱到的文档”。这让我们经常思考，是否需要文档，需要什么样的文档，什么时候形成文档等。

改变不见需求文档不开发的传统观念

在过去的两三年，我们强调的是需求交接，解决方案团队交，实施团队接。我们还强调异地ODC，供应商团队只认需求规格不认需求本身。而现在，开始强调重在沟通，强调可工作的软件高于面面俱到的文档时，大家不习惯了，觉得没有详尽的文档便不踏实。这正是争执中开发人员顾虑的，没有文档我怎么开发？我的理解和BA一致吗？要是开发了又变更了算谁的？他们认为这都需要文档来回答。

敏捷的目标应该是沟通和文档之间适当平衡。全面的文档并不能保证项目成功，而且过分注重文档细节将浪费时间。

有价值的内容必须形成文档

可工作的软件胜过面面俱到的文档，并不代表敏捷开发无文档，而是重视文档的作用。文档对团队来说作用极大，特别是团队更换或规模扩大时。

首先，文档写有价值的内容，无价值的文档纯粹是浪费时间。其次，减少文档并且尽量精炼，不需要长篇大论的文档。第三，文档需要及时更新和维护。比如，很多团队产品文档很多，种类很全，但内容不完整或不及时更新，需要查看时却得不到想要的信息。所以，我们要的是团队真正需要的文档，而不是要求团队编写的文档。

建立跨职能团队

争执中BA认可形成需求文档，只是时间紧，暂时还不能及时完善。当前团队BA人力严重不足，个别BA工作压力极大，在这种情况下，不一定只有BA才能更新文档。文档是开发过程的一个部分，而且相当重要，整个团队都有责任维护它。同是为了保证需求文档的Owner，我们最后决定，应当采取合作的方式，可以由team提出更改意见，BA确认即可。而且，文档不应该只由一个人编写到完成，而应该在草稿阶段就与team进行沟通以获得足够的信息。　

团队合作与信任

这是一个长期和关键的话题。敏捷团队的成熟度一定程度体现在自组织的水平，自组织除了需要团队拥有共同的价值观，还需要拥有共同的目标，让团队成员认识到团队目标高于个人或某个角色目标，达到高度协作。而团队合作离不开相互信任，PO和team之间，Scrum master与team之间，BA与开发人员之间，开发与测试之间等等，哪个环节缺少信任，哪个环节就容易掉链子。

我们团队的产品一体化和敏捷转型刚刚起步，而且当前由于种种因素举步维艰。不仅仅是敏捷开发文档的问题，还有更多话题，需要团队持续找到适合自己的方式。不断调整，持续改进，才是我们的方向。