“最初，该方法并不包括文档，但是许多组织已经找到了使用方法……”来自Alyssa Fox和Meredith Kramer —移动与敏捷：浮动作家的生存工具包
当他们的软件公司从传统的“瀑布式”开发方法转换为越来越流行的敏捷方法论时，许多作家正试图弄清如何按时完成任务，编写质量文档并保持理智。 尽管我们的主管，经理和敏捷教练决心帮助我们成功，但是Salesforce的文档和用户协助团队发现很少资源可以帮助我们与敏捷合作。 根据我们的经验，我们创建了战略和最佳实践，以帮助我们在敏捷环境中蓬勃发展（并享受）写作。
你真的很敏捷吗？
如果您的公司以偶然的方式实施敏捷方法，那么您可能并不是真正的敏捷。 而且，如果您不是真正的敏捷者，您可能找不到很多好处。 这篇文章的其余部分可能会为您提供一些小小的帮助，但是要应对敏捷或大多数敏捷的实现可能会很困难。
以下是能够从敏捷环境中获得最大价值的最低标准：
- 行政支持 。 高管们可能会想像一个充满自组织团队负责产品开发过程的公司，这使他们感到害怕，但是敏捷除非这些高管冒着风险并尊重Scrum团队组织的规则，否则它们是行不通的。
- 整个团队 。 开发，文档，质量保证和产品管理应在所有敏捷会议上派代表参加。
- 培训和指导 。 组织可能会采用敏捷方法的一些要素，例如即时开发或轻度的组织结构，但它确实需要所有方面的才能使其正常运行。 您的组织应该在培训和教练上进行投资，以使其真正发挥作用。
好消息–您仍然可以在不十分敏捷的环境中使用以下任何一种技术来改进文档编制过程。
实施方案
我们建议以下策略为作家实施敏捷。
- 鼓励耐心 。 我们的高管了解到，包括作家在内的所有开发团队成员都将经历过渡到敏捷的调整期。 没有人期望一个完美的过渡。 经理传达了整个组织的耐心需求。
- 提供培训。 每个产品团队成员（包括作家）都应参加解释敏捷的课程。 产品开发的每位新员工均应参加敏捷培训。
- 构建模板。 在管理人员提供了模板之后，编写，更新和组织文档计划对作者来说变得更加容易。 这些模板可帮助作者考虑使用敏捷开发的产品的文档要求，并允许作者随着产品的发展而更改计划的各个方面。
- 标准化跟踪工具 。 如果所有产品开发团队都使用相同的跟踪工具，则在敏捷环境中工作将变得更加容易。 我们的是内部开发的，但有许多商业上可用的。
- 垫估计 。 为您的团队提供比完成任务所需时间更长的估计时间。
- 提供明确的定义 。 在管理层在内部Wiki页面和冲刺审阅中使用的幻灯片上提供示例定义之后，“完成”等概念对作者而言变得清晰起来。
- 雇用更多的作家 。 改用敏捷后立即暴露了需要雇用更多作家来确保高质量文档的需求。 当开发人员人数增加时，编写人员人数也应增加。
- 学会适应 。 当作者专注于其优势而不是其挑战时，更容易适应敏捷环境。 我们已经学会了期待更多的变化，并花费更多的时间与团队成员交谈。
- 延长文档截止日期 。 当文档的截止日期稍微超出产品开发的截止日期时，在敏捷环境中编写的压力就较小。 为作家提供至少一个额外的星期，可以提高质量。 但是，这也为积累更多债务打开了大门。 一周以上似乎增加了债务。
每日最佳做法
我们建议在敏捷环境中的作家每天使用以下最佳实践。
- 提出问题 。 要求您的团队在日常Scrum会议上澄清您不清楚的所有内容。 这就是会议的目的。
- 给您的团队发送电子邮件 。 通过电子邮件将任何产品或过程建议发送给Scrum团队中的每个人。 敏捷意味着团队协作，而不是单单从管理层那里寻求指导。
- 写小说 。 学习为尚未测试的产品编写文档感到自在。 与撰写成品的非小说类作品相比，通过撰写小说类作品更有可能在最后期限之前完成任务。
- 修改小说 。 在将任何虚构内容交付给客户之前，请先对其进行修改。 在文档中插入修订提醒，并将修订提醒添加到您的日历中。
- 跳过会议 。 跳过不会增加文档价值的会议。 例如，编写者可能没有必要参加开发人员和质量工程师之间的代码审查会议。
- 安排办公时间 。 每周在日历上安排几个小时，以回答与Scrum团队（或未分配作者的Scrum团队）有关的文档相关问题。 敏捷是一个积极主动的环境：让开发人员和产品经理来找您。
- 组织文档“突击”。组织每周或每月文档突击，这是您的团队共同努力检查并发现彼此文档中的缺陷的时候。 闪电战有助于确保准确性，并向作家介绍他们可能不熟悉的产品。
- 自下而上和自上而下编写 。 敏捷强调流程的灵活性。 开始撰写主题后可以写一个计划。 做您认为最适合您，团队和产品的事情。
- 学习忽略什么 。 从敏捷中获取最大的收益，而忽略其余的一切。 敏捷专注于软件开发，而不是写作。 例如，每周仅参加两次每日Scrum可能就足够了。 敏捷意味着自我组织； 如果不同的团队以略有不同的方式工作也可以。
故障排除
对每个问题的简短回答是：大声说出来！ 敏捷依赖于面对面的互动，频繁的更新以及团队成员有足够的信心来自愿输入意见，无论好坏。
如果我不被邀请参加会议怎么办？
找到主持会议的人并要求添加该人，并准备解释原因。 您可能需要向人们保证，您不会减慢会议速度，并提醒他们，您学得越多，与主题专家的联系就越少。 如果需要，请升级。 如果您不能参加Scrum会议，Sprint审查和类似会议，那么该组织可能有更大的问题需要解决，并且您并不是真正在敏捷环境中写作。
如果他们认为敏捷是不编写功能规范的许可证，该怎么办？
如果您有敏捷教练或任何监视敏捷实施状况的人员，请寻求帮助。 如果您不这样做，我们会发现举行会议，并在邀请中建议回答以下问题将使与会者不必参加会议即可获得结果。 如果您提出问题，团队中几乎总会有人愿意给您答案。
另外，乐于做更多的挖掘和游戏。 您可能会很少需要入门，这会让您感到惊讶。
我该如何处理最新的代码签入？
一些组织坚持认为，文档不应与开发和质量检查保持相同的周期，但这当然会导致积累更多的债务。 一些组织定义“完成”的方式是为周五下午的签到留出一些摆动的空间。
解决此问题的最佳方法是帮助管理流程，以免延迟签入。 在sprint审查会议中提出，任何影响UI的工作都应尽早完成，而不要迟到。 或者，提醒人们他们的作品可能没有翻译，或者如果没有适当的时间审查在线文本和其他步骤，可能会以较低的质量突出。
如果有人确实在最后一刻确实检查了一大堆代码，并带来了很多文档方面的后果，请提醒团队整个团队直到所有工作完成后才完成，并寻求帮助。 您可能不会在第一时间获得帮助，但是Scrum的妙处在于，团队成员有机会学习自己的错误并每月改进。
摘要
在敏捷环境中进行书写给作家带来了新的困难，但是打字机和计算机在首次引入时也是如此。 在我们的经理和主管人员的广泛支持，耐心和最佳实践的帮助下，我们学习了如何使用敏捷，并发现它为作家提供的好处超过了我们在学习如何使用它时所遇到的挣扎。
最初在 www.scrumalliance.org上 发布 。
