敏捷。自90年代以来，这种哲学一直影响着IT的发展，但它仍然用大量的术语和基本过程唤起了作家的恐惧，这些术语和基本过程唤起了一些可怕的可能性。敏捷听起来对作家来说可能是混乱和敌对的。 Scrum: 这个词只是带着睾丸激素的动作滴落，强壮，出汗的团队成员被锁在一起并与反对派抗衡。作家适合哪里？我是被踩到并踢进草皮的球吗？ 精益: 没有规格？我必须依靠日常的站立会议，面对面的对话，电子邮件线程，任务板和问题跟踪系统？而且我必须使用这些资源为我很可能看不到或使用的产品编写文档？ Sprint: 我正在努力，每两到四个星期就准备生产可运输的文档？没有规格？还是产品？同时参加每个scrum的日常会议？ 甚至敏捷宣言似乎都将核心价值直接对准了作者的核心: “我们已经开始重视工作软件，而不是全面的文档”。 在阅读敏捷中的用户文档时，我注意到大多数评论员将讨论的重点放在减轻作家的恐惧上。他们建议作家在面对混乱时保持理智和富有成效的过程和技术，甚至可以茁壮成长和快乐。我认为快乐的作家是一件好事。但是，正如我在上一篇专栏文章中提到的那样，快乐，富有成效的作家并不能保证用户的成功。我曾经是一名作家，很高兴为沮丧的用户制作数千页，这些用户用我的手册支撑了他们的显示器。 我已经在混合敏捷环境中工作了大约六年。我仍然 (大部分) 理智。同事和客户的反馈表明我仍然富有成效。我可以毫无保留地说我很高兴。我为什么快乐？我体验了敏捷的一些作家友好的方面，针对不太友好的方面开发了一些应对策略，我也看到了敏捷能够给用户带来的一些好处。我认为敏捷可以帮助我成为更好的用户倡导者。 敏捷作家 敏捷速度很快，但是一些实用性减轻了我的惊人速度。 敏捷方法论强调在小的工作单元中不断迭代。工作单位代表了非常具体的用户目标。在Scrum中，可交付工作的最小单位称为用户故事。 多年痛苦的敏捷前课程教会了我写作以供重用，而敏捷的快节奏，迭代的性质惩罚了自定义的临时写作。基于主题的创作是一种自然的解决方案。故事几乎一一映射到主题。每个主题都充分捕获一个工作单元，作为独立内容，以演示给利益相关者和发行说明。当需要集成新内容时，我一直在努力确保整个doc项目足够灵活和可扩展，以最小的努力来更新和增强较长形式的文档，从而适应新主题。 说到更长形式的文档，敏捷方法可能专注于原子级的工作单位，但它们也承认需要更大的、大范围的目标和可交付成果。例如，Scrum扩展了叙事隐喻，并将相关故事收集到史诗中。我总是可以为史诗中的大型文档项目协商足够的时间和资源。 由于快速迭代的不断流失，我的待办事项清单总是充满到爆裂。作为辩护，我定期进行doc分诊。每个可交付成果都不需要相同水平的精力和开销。例如，用户故事及其文档并不总是代表客户交付的完整且独立的功能。最终用户可以是内部利益相关者，这意味着我仍然可以满足对生产，集成和交付的较低要求 (以及较低的压力) 的要求。 在以前的开发制度中，我可以在一个从未见过的产品或功能上辛苦工作六个月。如果一个可交付成果还没有准备好发布，它就会被碰撞到下一个版本的下一个周期。由于发布周期如此之短，延迟很少是悲惨的。我的文档内容一直遵循，在产品和我自己的脑海中保持相关性和新鲜感。经验告诉我，我很快就会再次看到该功能。 对用户的好处 我已经强调了敏捷的一些功能以及我作为作家对它们的反应，但是用户呢？如果有的话，用户从敏捷中得到什么？ 敏捷的时间表及其频繁的迭代确保了活动项目的内容不超过其开发周期。用户每两到六周就可以访问更新的内容。另外，当我收到中流反馈或非关键文档错误时，文档更新已经在计划中。没有戏剧。 敏捷还可以提高这些频繁更新的质量。 作为几个scrum的可见成员，我一直在与开发人员和产品所有者交谈。我的90% 问题的答案是简短的对话或简短的站立会议。我的同事没有陈旧的旧规格。他们不觉得需要对我隐瞒，因为我们的互动既迅速又无痛。我也没有陈旧的旧规格可以坚持，给我一种错误的安全感。我花更少的时间回答诸如 “您从哪里得到的？这是完全错误的/旧的/过时的!”尽管过去当我回答“ 来自规范 ”时，我感到很合理，但我对此并不满意。没有成效。我宁愿不生出坏血，也不烧掉善意。我宁愿医生是正确的。 除了简单的机械正确性之外，一些用于doc增强的最佳想法还来自开发人员，客户经理和支持人员。最终，我的用户受益于更丰富的内容。 引用敏捷宣言中的另一项: “我们重视客户合作而不是合同谈判。” 从理论上讲，客户在开发中具有正式而积极的作用。在实践中，参与程度可以根据几个因素而有所不同，尤其是他们对合作的开放程度和能力。当我有一个友好、积极的客户时，我会体验到最令人满意的敏捷。在编写文档时，我从客户那里得到了建设性和创新性的反馈，而且我知道我的所有用户都将从文档中获得的客户体验中受益。 敏捷不是灵丹妙药。它也不是一个边缘化和吞噬不幸作家的怪物。它只是一种具有自己的一系列挑战和好处的开发方法。我来解释敏捷宣言对 “工作软件” 而不是 “全面文档” 的评价不是威胁，而是一种要求。产品开发的目标不是编写详细的规格和fat参考指南，而是交付使用户成功的产品。文档仍然起着关键作用，那就是保持用户的快乐和成功。 总的来说，我在敏捷领域的时间让我对宣言进行了简单的调整: “我开始重视工作文档而不是全面的文档。”