软件开发就是这样一个过程，它不同于其他种类的工程过程。它需要一个流动的、灵活的、愿意对变化做出快速反应的团队的关注。这时，敏捷方法就介入了。 敏捷方法是一组面向提高软件开发专家效率的例程。 它更像是一种哲学，选择重视适应性和灵活性的原则——敏捷的目标是更好地了解不断变化的业务需求。我们可以在敏捷项目管理中应用各种框架来开发和交付产品或服务。每个敏捷框架都强调一种特定的方法，并专注于确定的结果。根据所请求的结果选择特定的敏捷方法。它们都有自己的一套特征和术语，但同时，它们也有共同的原则和实践。 支持敏捷开发生命周期的两种最流行的方法是Scrum和看板。 什么是Scrum？ Scrum代表在最短的时间内交付高质量的软件。它使用称为sprint的迭代时间框。冲刺最多持续四周，并且有明确的开始和结束日期。在整个sprint团队中： 创建文档， 开发scrum软件， 监控工作流程， 然后改进以确保未来项目的成功。 Scrum团队由三个角色组成： Scrum代表在最短的时间内交付高质量的软件。它使用称为sprint的迭代时间框。冲刺最多持续四周，并且有明确的开始和结束日期。在整个sprint团队中 Scrum代表在最短的时间内交付高质量的软件。它使用称为sprint的迭代时间框。冲刺最多持续四周，并且有明确的开始和结束日期。在整个sprint团队中 开发团队是一组专家，他们负责完成产品负责人所描述的工作和确定的优先级。 Scrum的创建是为了确保团队在整个项目中以恒定的速度工作和持续改进，并确保工作按时完成。在Scrum模型中，团队沟通是优先考虑的。团队必须准确地了解他们正在进行的任务和正在取得的进展。这有助于团队朝着目标前进，而不会在途中遇到许多障碍。此外，scrum管理员还可以跟踪团队的进度，并在需要时使用性能进度表来鼓励团队的速度。 看板是什么？ 看板促进了不断变化的环境、不断的迭代和敏捷的交付。看板方法还可以帮助您可视化您的工作流程，并定位任何当前的问题。看板板是帮助可视化开发过程的主要工具。通常它有三个可视化列“待做”、“正在进行的工作”、“已完成”。当团队需要适应最终用户不断变化的需求时，您可以在工作过程中不断插入任务。 支持敏捷开发生命周期的两种最流行的方法是Scrum和看板： 工作流可视化，以帮助轻松识别问题并修复它们。 通过设置任务限制来限制WIP（在制品）以提高生产率。 工作流管理，用于在观察工作最佳和不最佳的任务时优化工作流。 坚持政策。团队需要遵守敏捷工作流指导方针，这样团队中的每个成员都在同一页上，并进行高质量的工作。 反馈回路。通常在日常会议上表达，在会议上团队评估当前情况并改进工作过程。 持续的和实验性的交付进化。通过不断的改进，团队可以加快工作过程，并不断地向市场交付软件片断。 Scrum与看板 正如你所看到的，Scrum和看板非常相似，因为它们都是敏捷哲学的子集。与此同时，它们的不同之处会让你偏爱其中一种。让我们看看他们的区别。 当Scrum基于短的和结构化的sprint时，看板方法是恒定的，并且更加可变。 Scrum是一种复杂而严格的方法，有许多规则和团队必须遵守的高度特定的框架。看板是一种更精简的方法，规则更少，框架更简单。然而，两者都能帮助团队坚持敏捷的核心原则。 看板使用流水线的方法在一个队列中移动工作。像Scrum一样，看板有一个按优先级排序的项目任务的backlog，但不是在sprint中计划工作;团队成员要处理待办事项列表中优先级最高的任务。Scrum过程需要对范围内的内容进行高度控制，而看板让你随流而动。 两种方法都不如另一种。对团队的正确选择取决于您的组织结构，团队偏好以及您的工作和项目的具体情况。 另一个重要的事情是，你不必总是坚持一种方法。事实上，已经在一起工作了一段时间的团队可以轻松地在两种方法之间切换，以适应不同类型的项目和工作集。 敏捷文档编制方法 敏捷开发方法是作为文档驱动开发过程的一种替代方法而创建的;它确实意味着消除内部文件。因为软件开发是动态的，所以它只是为可工作的软件增加了比综合文档更多的价值。 因此，如果您需要为项目创建大量文档，敏捷开发方法学中没有任何东西固有地阻止您这样做。 因此，文档应该尽可能地高效，以实现敏捷软件开发项目中的相关目标。敏捷文档是一种创建紧凑文档的方法，可以解决当前的情况。 什么是软件文档？ 没有良好的文档实践，软件的成功是不可能的。从零开始开发一个软件产品，发布它，然后吸引用户是很有挑战性的。因此，为了保持每个人的同步并使其更容易导航，软件文档的概念出现了。软件文档描述了软件产品的开发、功能和/或使用。编写有效的软件文档是一个复杂的过程，需要技术写作专家。 敏捷文档类型 敏捷软件开发方法是关于将变更快速部署到软件中，因为它提倡适应性计划、演进开发和持续集成。然而，有趣的是，敏捷文档这个术语并不存在。然而，它被广泛用于暗示在使用敏捷实践创建软件产品时进行活动文档。由于每个项目都是不同的，所以团队可以维护不同类型的文档。但是软件文档有两个主要类别： 产品文档 过程文档 可能的敏捷文档的示例包括表格，图表，案例研究等。下面是您可能想在项目期间创建的一些文档： 产品愿景声明。它是对产品核心本质的描述。它描述了它解决了什么问题，为谁设计的，以及为什么。产品愿景可以让你的团队对他们正在从事的工作有一个更大的了解。 设计评审。这是一个关于项目的简要信息，例如，用于构建系统的技术和工具。 设计概念--关于团队在项目的各个阶段所做的与设计和架构有关的关键决策的一般信息。 操作和维护文件。这通常是员工正确高效地履行职能的指南。 随附文件。专门针对支持人员的培训材料，故障排除指南等。 系统文档。提供系统的概述。它有助于确保如果开发团队离开，关键信息仍然保留。 用户文档。包括用户手册和支持指南。保持简单易懂。 Scrum方法中的文档 如果没有技术文档管理过程，任务可以自发地来自任何来源，并分配给开发团队，只需要很少的信息或资源分配。通过调整Scrum流程来管理技术文档，可以避免这种情况。此外，以这种方式管理和跟踪项目，使每个团队成员在处理文档时具有更大的透明度和责任感。 技术文档管理流程包括以下步骤： 定义即将到来的项目(冲刺计划)。在每个sprint之前回顾即将到来的项目。了解一下这项工作和设定的优先级是值得的。为了不让工作在需要结果前两周出现时感到惊讶。 为大型项目创建文档计划。这样的计划包含了许多需要保持在项目顶部的细节。这不是一个瀑布方法或文档大纲，而是一个关于项目的注释列表，例如谁是谁，QA测试脚本在哪里，预期结果，计划发布日期，关键产品文档，等等。这样的文档计划可以作为项目的一种支票簿。 使用文档将工作划分为任务。与作业相关的票据由文档计划生成。他们应该概述每个项目的主要任务，并给出所需工作的想法。这里的主要思想是通过将工作分成更小的任务来简化复杂的任务。 把票分解成两周的冲刺。门票应该在各个sprint中分发。每次冲刺通常持续两周。这种通过标志的速度叫做速度。只有在几次冲刺之后才能了解你的速度。速度信息的计算和交流对于了解技术作者是否具备执行工作所需的一切非常重要，同时要考虑发布的时间。 涉众应该了解关于文档的工作，以了解项目的进展情况。除非文档有优先级，否则sprint不应该改变它们的赋值。应考虑到紧急情况和危机。使用Scrum方法进行文档编写，很难坚持sprint计划。不同的团队可能迫切需要快速更新。Scrum过程在这里很重要——它平衡了当前的工作量，消除了过多和分散注意力的工作。您不需要因为未完成的文档任务而比当前速度更快。 在每个冲刺结束时发布两周的冲刺报告。与每个对这项工作感兴趣的人分享已经完成的细节。这通常包括通过电子邮件发送更新。报告显示了一个封闭冲刺后的完成票和下一个冲刺的预定票。sprint报告是最重要的任务之一。它让人们知道一个科技作家一直在写什么。 在发布文档之前要检查文档。有必要进行审查过程，以确保文件符合质量标准。这个过程展示了产品是如何满足客户需求的。值得查看与已完成的票据相对应的文档部分。因为试图在同一时间浏览太多的内容是压倒性的。 看板方法中的文档记录 在看板中，没有任何类型的规定文档。它是一个非常轻量级的，连续的流程，与Scrum相比更简单。看板中的每一个工作项一旦有能力处理，就会被单独处理。让我们看看这个方法如何与文档一起工作的示例。 想象一下，随着时间的推移，您积累了一大堆文档，您需要以某种方式将其结构化。你打算怎么办? 您可以创建一个共享看板板，在这里将文档划分为类别，以创建导航系统。 为支持排序的列指定通用名称。看板板应该有尽可能少的列，但同时，看板应该反映实际的工作流程。 为您计划在文档中涉及的所有主题创建卡片。 您还可以用不同的颜色标记一些卡片，以指示主题缺失且需要创建或呈现且需要删除。 然后把所有的卡片放在一个未排序的列中。你可以要求你的团队成员将他们拖到他们认为应该组织卡片的地方。 同意结构并进行相应修改。 从那一刻起，您可以将信息转换为菜单或子菜单。 在那里!现在，在看板卡片分类的帮助下，您已经有了逻辑结构。您的内容设置的方式是为用户提供他们正在寻找的信息。 在任何情况下，你的看板板应该随着你更多地理解你的过程和你开始做改变变得更精简而发展。 如何用敏捷方法更有效地组织文档的创建 您可能会说，敏捷中的文档是流动的，并且由整个团队协作维护。这里有一些简单的规则 永远记住，您必须维护以后创建的任何文档。如果文档很轻，不复杂，不太详细，那么它将更容易理解和更新。 如果你想避免积累错误和过时的信息，不要急于记录。在需要的时候生成文档，而不是在需要之前。 将文档收集到一个地方。记住，它也应该是可访问的，是有用的。将产品文档存储在您和您的团队成员可以轻松找到的地方。 与团队合作。在敏捷团队中维护文档是一个协作的过程，每个团队成员都应该为这个过程做出贡献。 如果您想实现上述所有功能，您需要灵活且易于访问的软件文档工具。 结论 敏捷方法使您能够在编写敏捷项目文档的同时，对更改做出高度响应并进行改进。至于Scrum和看板实践——很容易指出两者之间的区别，但这只是表面上的。虽然做法不同，但原则大体相同。这两个框架都可以帮助您用更少的麻烦来制作更好的产品(和文档)。 祝你的技术写作好运！ 单击帮助小组 跨平台和设备编写，托管和交付文档