“最开始的时候，这一套方法并没有任何文档，但是很多公司都找到了正确的解决方案…”摘自Alyssa Fox和Meredith Kramer的《Mobile and Agile: The Floating Writer’s Survival Kit》。
很文档的撰写都想尽办法要找出如何能按期交付，如何能完成质量文档和如何在软件公司从传统的瀑布式模型过渡到日渐流行的敏捷流程时保持平稳。虽然我们的管理层和敏捷教练都决心帮助我们在敏捷的道路上成功，但是我们的文档和用户协助团队仍然觉得没有足够的资源能够帮助我们拥抱敏捷。从我们的经验看来，我们可以建立一些制度和最佳实践来帮助我们在敏捷的环境中更好地生存。
你真的敏捷了吗？
如果你的公司毫无计划地开始实施敏捷流程，你们就有可能不是真正的敏捷。如果你们不是真正的敏捷，那么你就有可能看不到敏捷带来的很多好处。本文将从各个小方面入手帮助你，但是要对付“半敏捷”和“几乎敏捷”将会是艰巨的任务。
下面几条是要从敏捷环境中获益所必须满足的条件：
1. 部门主管的支持。说到自组织的团队负责产品的开发，这有可能会吓坏了部门主管，但是如果主管不愿意冒这个风险并且遵守Scrum的规则的话，敏捷就无法起到其应有的作用。
2. 完整的团队。在所有敏捷会议中开发、文档、QA和产品管理的所有人员都必须参与。
3. 培训和训练。有些公司可能只关注敏捷流程的其中一些部份，例如及时的开发和轻量级的组织结构，但是要敏捷流程真正地发挥作用的话，就必须要把整套思想付诸行动。因此，你的公司必须要在培训和训练方面投入足够的资源。
好消息是：即使你的公司不是真正完整的敏捷环境，你仍然可以利用下面的一些技巧来改进文档开发流程。
实施方案
我们推荐以下这些文档开发人员的敏捷实施方案。
鼓励有耐心
我们的部门主管明白所有的开发团队成员，包括文档撰写人员都需要一个向敏捷过渡的一个调整阶段。没有人会期望一次性完美地过渡。经理们应该在公司里面向其他人传达这样的信息。
提供培训
每一个团队成员，当然包括文档撰写人员在内，都应该参与一次关于解释敏捷的课程。所有新加入公司参与产品开发的员工也必须要参加敏捷培训。
建立模板
如果有文档模板的话，那么撰写、更新和组织文档计划都会变得更加容易。文档模板能够帮助文档撰写人员考虑以敏捷流程开发的产品对文档的需求。同时也让他们的机会随着产品而改变。
标准化跟踪工具
在敏捷的工作环境下，如果所有的产品开发团队都使用同一个跟踪工具的话工作起来会轻松很多。我们的工具是我们内部开发的，当然市面上有很多商业的工具可供选择。
估计缓冲
给你的团队比他们估计完成一项任务所需的时间更多的时间。
给出清晰的定义
管理层应该能够为一些术语在wiki上和在Sprint评审会议的PPT的注释中给出定义。
聘请更多的撰写人员
实施敏捷以后会马上暴露出需要更多撰写人员以保证文档质量的问题。当开发人员的数量增加的时候，文档撰写人员的数量也应该相应增加。
学会适应
当文档撰写人员专注在敏捷环境带来的好处而不是挑战时，他们更加能够适应新的环境。我们应该学习接受更多的变化，以及与团队的其他成员进行更多的交流。
延长文档的交付日期
如果文档的交付限期稍微比产品开发的限期晚一点，那么压力将会小很多。让文档撰写人员能有多至少一个星期的时间来撰写更高质量的文档。
日常最佳实践
我们推荐在敏捷环境中的文档撰写人员采用以下的一些日常最佳实践。
提问。要求你的团队在每日站会的时候向你提出需要澄清的问题。这个就是会议的重点。
给你的团队发邮件
把你的任何关于产品或者流程的建议发给你Scrum团队中的每一个人。敏捷就是要所有人都在一个团队你工作，而不是沿着管理层指挥的方向前进。
撰写虚拟文档
尝试为还不能测试的产品开始撰写文档。这样比你一直等到产品完成再开始，更可能在最后限期之前完成任务。
修改虚拟文档
在文档交付给客户之前，记得要先修改虚拟文档。在文档中插入修改提示，或者在你的日程表中插入修改提示。
跳过会议
跳过那些对文档没有意义的会议。例如，文档撰写人员就没有必要参加代码评审会议。
安排办公室时间
在你的日程表中美洲安排几个小时来回答你的团队关于文档相关的问题。敏捷环境是主动的：让开发人员和产品经理主动来找你。
安排文档评审
每周或者每个月安排一次文档评审，让你的团队互相评审对方的文档。这样能够保证文档的准确性和让文档撰写人员更加了解关于产品他们还不熟悉的部份。
顺序不是问题
敏捷强调灵活胜于流程。你可以先开始撰写文档再开始写计划。做你认为对你、团队和产品最有利的事。
学会忽略
学习你能从敏捷中学到的东西，其他的就可以忽略了。敏捷关注的是软件的开发流程，而不是文档的撰写。例如，每周出席两次每日站会有可能就足够了。敏捷强调自组织，实施的时候稍微有点变化是没有什么问题的。
解决问题
解决问题的最直接最简单的办法就是说出来！敏捷依赖于面对面的交流互动，频繁的更新和团队成员之间的交流。
如果我没有被邀请参加会议怎么办？
找到主持会议的人并要求加入，不过要记得先准备好充分的理由。你有可能需要跟会议主持说明你的加入并不会使会议进度变慢。你也要说明你能够从会议中学得越多，你从团队的专家那需要的时间也就越少。如果你不能参加Scrum会议，Sprint评审会议以及类似的会议的时候，很有可能公司里面存在着更加严重的问题，这样你其实并不是在一个真正的敏捷环境中。
如果他们认为敏捷就是不用写功能文档的许可该怎么办？
如果你们有敏捷教练或者有人负责监测敏捷实施的健康程度的话，那么请寻求帮助。如果没有的话，你可以召开一次会议，然后在邀请中列出一些问题，然后明确表明回答这些问题可以得到明确的结果，而不需要参加会议了。如果你列出问题，那么团队中总会有人会给出答案的。
该如何处理最后一刻的代码签入呢？
有些公司将文档放在和开发测试不同的周期里面，当然这最后导致的后果就是不断的累积债务。有些公司这样来定义“完成”来为最后一刻的签入留出空间。
解决这个问题的最好的办法就是帮助经理们制定流程来保证这样的问题不再发生。把这件事在Sprint评审会议上提出来，表明所有影响UI的工作都应该尽早完成。或者可以提醒你的同事，他们的工作有可能不会被记录到文档里面，或者因为没有被检查过而导致低质量最终被抽出。
如果有人真的在最后时刻签入了代码，从而导致了很多文档需要修改，这个时候就需要提醒团队，任务在文档没有修改完之前不算完成，然后向其他人求助。当然，你不一定会在第一次就得到帮助，但是Scrum的优点就在于团队在每个月都能从他们犯的错误中学习和成长。
总结
在敏捷的环境中撰写文档必然是会遇到新的困难和挑战的，但是当第一次使用打字机和电脑的时候又何尝不是呢？如果能得到来自经理和主管们的支持和耐心，我们就能学习如何使用敏捷，也能发现敏捷给我们带来的好处。
想要获得更多关于日常实践，团队最佳实践和文档撰写者如何能够从敏捷中获益的资料，请阅读完整的白皮书http://media.developerforce.com.s3.amazonaws.com/techpubs/agile_writers_guide.pdf。
作者:Gavin Austin
原文地址：http://www.scrumalliance.org/articles/369-a-writers-guide-to-surviving-agile-software-development
