处理软件开发并不是最干净、最容易的事情。它涵盖了无数的技术和非技术问题。技术方面肯定要复杂得多，需要硬技能，但同时可以使用正确的策略和工具以某种方式进行管理。另一方面，非技术世界有更多的自由度。它与人性一样具有可变性和不可预测性。 与任何其他产品制造流程一样，自软件开发冒险的早期以来，已经实施并测试了许多最佳实践。敏捷方法是一组不同的方法，主要用于应对需求的极端变化，以及缺乏对交付最终产品的最重要目标的关注。 有时，此类方法超出了其最初目的，最终结果远非理想。 Scrum 是这些方法之一。它更多地被描述为一个框架。它基于一组基本的原则、规则、事件和角色。我们在本文中讨论如何判断和灵活地使用该框架，并避免一些可能远非理想的严格解释。 Scrum 的简要介绍 基于所谓的“敏捷宣言”中定义的以下一般原则： 敏捷方法 “个人以及流程和工具上的交互” “工作软件胜过全面的文档” “客户合作胜过合同谈判” “通过遵循计划来应对变化” （来源： ） 敏捷宣言 根据敏捷宣言，在上述陈述中，虽然右边的项目很重要，但左边的项目更重要。 从开发过程的角度来看，敏捷方法论都意味着迭代和增量过程，而不是经典的瀑布模型：整个开发由许多增量步骤组成，每个步骤都由表征整个瀑布项目的相同阶段组成：需求、分析、设计和编码的集合。也就是说，每一步都代表着整个开发的一个增量，可以看作是一个完整的项目。 方法可以被视为对上述原则的特定拒绝。 Scrum 是一个框架，团队可以在其中使用自己的流程来开发某些特定的软件产品。它的基本特征是 、 和 。 Scrum 角色 事件 工件 是： 角色 ：它可以包括分析师、开发人员、测试人员以及参与项目的各类专业人员。它应该在 Scrum 规划会议的范围内以自组织的方式工作。 团队 ：他/她协调所有 Scrum 流程、组织会议等。 Scrum Master ：他/她对产品负责。他/她管理所谓的 ，其中包含以清晰的方式表达的所有必需功能。他/她可以与团队讨论这些问题，并从团队中获得帮助，但他/她是唯一的责任。 产品负责人 产品待办事项列表 有： 活动 ：代表迭代开发中的单个增量。它的持续时间通常为两周至一个月。 Sprint ：对于两周的 Sprint，该会议最长持续时间为 4 小时；对于一个月的 Sprint，该会议最长持续时间为 8 小时。它由 Scrum Master 组织和安排，包括团队和产品负责人。在这次会议中，选择、评估和讨论了要在当前 Sprint 中开发的 的许多功能。功能是根据其优先级来选择的。 Sprint 计划 产品待办列表 ：这些每日会议不超过 15 分钟。它们由 Scrum Master 安排。在这些会议中，每个团队成员都会描述他/她为执行当前任务所做的工作、出现的任何问题以及如何克服可能出现的困难。 Scrum Master 负责这些会议的安排和协调以及它们的正确执行。 每日 Scrum 会议 ：这是在当前 Spring 结束时举行的会议。两周的 Sprint 需要两个小时，一个月的 Sprint 需要四个小时。它由 Scrum Master 组织，参与者包括 Scrum 团队、Scrum Master、产品负责人以及根据产品负责人的决定所需的所有利益相关者。讨论了当前的增量。概述了哪些进展顺利，哪些出了问题，最后，如果需要，会更新产品待办事项列表。 Sprint 回顾 ：两周的 Sprint 会议为一小时，一个月的 Sprint 会议为两小时。它发生在 Sprint 评审之后和下一个 Sprint 计划之前。在这次会议期间，根据上一次迭代的经验，讨论并计划下一个 Sprint 的所有改进和提高最终产品质量的行动。 Sprint 回顾 有： 文物 ：它是一个不断发展的文档，包含产品的所有要求。每个项目称为用户故事，并具有描述、顺序、估计和价值等属性。顺序越高的项目越清晰、越详细。 产品待办事项列表 ：它包含为下一个 Sprint 选择的产品待办事项列表以及必要的计划。 Sprint Backlog ：正如我们上面所说，用户故事是产品待办事项列表中的一个项目。用户故事遵循一个常见的文本结构：“ <种类的操作系统用户>， <做一些任务>， <我可以实现一些目标>。它还应该有许多接受标准，每个标准都具有以下模式： <一些前提条件>， <用户执行一些任务> <发生一些系统状态更改>。 用户故事 作为一个 我想要 以便 给定 当 然后 ：横轴表示时间，纵轴表示每个步骤剩余工作量的图表。工作量可以通过所谓的 来衡量。故事点是一个测量工作单元，它考虑了所有可能影响开发工作的变量，例如技能、复杂性、工具等。 燃尽图 故事点 ：是迄今为止的总增量，即迄今为止完成的 列表项加上过去迭代中已完成的所有其他项的总和。 增量 产品待办事项 不要将 Scrum 与某种形式的学说混淆 您可以将上面列出的项目视为一组专业人员可以操作的基础。他们可以被视为一个有用的工具，但真正为项目带来凝聚力、相互沟通和有效性的是人本身。事实是，即使严格遵守所有这些规定，并且 Scrum Master 做出所有承诺，项目也可能陷入混乱并惨败。 这是因为人们经常将规则、方法论和框架与某种旨在驱动人类走上正确道路的神圣引擎相混淆。这是一种常见的心理缺陷。一个非常重要的考虑因素是，现实与理论不同，它是一种非常复杂和野生的动物。如果您认为可以通过一系列规则和模式来驯服它，那么您注定会失败。 Scrum 的真正目的是最大限度地减少开发过程中的“背景噪音”并提高对最重要事情的关注。如果使用适当的灵活性和谦虚，它可以有效地做到这一点。 在下一节中，我将描述一个真实的用例，在这个用例中我踏上了 Scrum 世界的旅程。这是一个由没有经验的人（包括我自己）组成的旅程，他们第一次愿意以一致的方式接受敏捷原则。我之前工作过的许多项目都是以迭代的方式完成的，但没有真正的敏捷框架的整个仪式。 一个真实的用例 我们在这里谈论一个真实的用例，其中远非严格采用 Scrum 框架。该项目是关于一个软件系统，旨在跟踪解剖病理学实验室涉及的所有活动，从收集组织标本，并以不同步骤处理它们，直到组织载玻片的最终分发。该系统还应该通过特定的软件驱动程序在特定阶段与外部自动化机械集成。 我作为软件架构师参与了这个项目。我必须与项目经理合作，概述主要问题并设计基本架构蓝图。如果你将敏捷原则发挥到极致，那么提前考虑架构并不是最好的事情。甚至架构设计也是在迭代场景中看到的。但在大多数情况下，您仍然需要一个起点，并且必须与所有相关利益相关者进行讨论。 我进行了这项初步的建筑研究，试图以基于 、 和 的结构化方法对环境进行清晰的分离。遵循这种方法非常重要，可以清楚地分离问题，并根据特定类型的利益相关者定制讨论。 观点 观点 视角 所讨论的架构的一部分确实是开发阶段及其组织。该公司本身尚未采用任何敏捷方法。尽管如此，根据经理和其他相关人员的同意，我们希望填补这一空白，并选择从 Scrum 方法框架中获取灵感。 我们根本没有接受过 Scrum 培训，但我们都了解它的基础知识。我们对该项目的主要指导方针（方法论和技术方面）是： 需要遵循的一组基本实践，以迭代方法（我们最终决定中的 Scrum）专注于部分和整体目标。 通过自动化工具跟踪活动/来源。 方法与 相结合。 行为驱动开发 单元和集成测试 Scrum 实践 由于需要执行一些可靠的方法框架，但由于我们缺乏深厚的技能，我们选择采用 Scrum 的一些主要规则，但又不走得太远。首先，迭代方法在我们看来非常重要。 Scrum 通过所谓的 Sprint 涵盖了这一点，我们可以将其视为迭代工作单元。每个 应该涵盖积压中选定数量的功能，并具有特定的持续时间。 Sprint 我们选择两周作为冲刺的持续时间。在开始真正的交易之前，我们设置了为期一周的常规 Sprint 零号，以完成前期工作和组织任务。在这个初步的 Sprint 中，我们还编写了待办事项列表的初始版本，其中所有功能均按优先级列出。我们没有采用特定的方法来评估任务工作量，只是团队成员之间的正常讨论。 在每个 开始时，对于Scrum规则，我们会讨论已经完成的工作，评估所有遇到的问题，并选择在即将到来的 中要实现的功能。 Sprint Sprint 项目经理扮演产品负责人的角色，并得到领域专家的支持。这在特定情况下是有意义的，因为没有真正的产品经理参与，并且项目经理本人了解客户需求的所有知识。至于 Scrum Master，我做了一段时间，然后将这个角色交给了另一位同事，即使我们都没有接受过充分的培训。 我们的团队是一支多元化的团队，成员来自不同的城市。然后，我们被迫在每天的同一时间安排 Skype 通话来组织虚拟版本的站立会议。会议时长约 15 分钟。一些团队成员对此有某种形式的抵制，也许是因为他们将其解释为一种控制形式，但事实并非如此。 我们花了一些时间让他们意识到日常会议的真正意义：队友之间进行简短的讨论，聚焦主要问题，加强沟通，找到改进的方法，让大家的工作变得更轻松。有一段时间，他们一直说这是浪费时间，而且会分散实际工作的注意力，但最终，我们成功说服了他们。 通过自动化工具跟踪活动/来源 除了方法论实践之外，我们还需要工具来解决这些主要问题： 对代码进行版本控制、跟踪其更改并在团队中共享。 跟踪活动和错误解决：必须做什么、分配给谁以及其状态。 将源代码更改与活动相匹配。 项目中的信息流过于复杂，无法仅依靠方法实践来控制它。您需要扎实的工具基础才能使工作变得更轻松。自动化的任务越多，您就越能专注于重要的事情并生产出更好的产品。 对于代码版本控制，我们使用 Git，因为它是最自然的选择。 Git 可以有多种使用方式，我们个人采用了 作为工作流模式。 Gitflow 为了跟踪活动，我们使用了 ，这是一个旨在管理项目的通用平台。 Redmine 为了解决第三个问题，我们将 Git 存储库与 Redmine 集成，通过在提交注释中使用问题识别码，Git 提交可以与特定的 Redmine 票证相关联。这样我们就有了活动和 Git 工作单元之间的完整映射。 行为驱动开发方法与单元和集成测试相结合 我们非常愿意将我们的开发流程建立在行为驱动方法的基础上。 BDD 非常适合 Scrum 以及一般的敏捷原则，特别是在沟通方面。它允许以非技术人员可以理解的格式编写测试场景，并使用正确的工具给出当前状态的可视化报告。它绘制了产品的逻辑边界，并迫使开发工作在这些边界内进行。 BDD 功能测试只是整个测试工具的外层。我们还使用了单元测试和集成测试。为了不被这种开发环境的复杂性压垮，我们必须使用正确的工具和自动化功能。 涉及的主要技术有： ： 中 Cucumber 通过 REST 服务集成到 Spring Boot 应用程序 其他测试工具：支持集成测试的 、 和 Spring Boot 库。 JUnit Mockito 下面的思维导图显示了上面讨论的内容的摘要： 注意事项 采用 Scrum，即使是以一种轻松、灵活的方式，值得吗？答案是肯定的。但我们要明确的是，我们不能将其视为所有问题的解决方案，如果在不理解其精神的情况下采用它，甚至可能是有害的。方法论的本质是提供一种集体思维模式，使人们在最大程度地共享信息和承诺的情况下一起工作，但如果人们专注于遵循异国仪式的规则而不是实际的工作，那么最初的目的就消失了。 体育类比 通过体育运动的比喻，你可以更好地理解上面所说的内容。并非所有人都喜欢足球，但几乎每个人都至少对足球的运作方式有一个最基本的了解。首先，是一场集体比赛。两支球队在比赛场地上相互对峙，试图将球传入球门。为了完成这项看似简单的任务，他们必须将个人主动性与集体战略和战术结合起来。这些策略和战术是由教练事先传授的，占整个训练时间的很大一部分。 为了真正有效，足球运动员遵循的上述集体规则必须毫不费力地执行，甚至不认为它们存在。它们必须是自动的，例如驾驶汽车的手势。达到这一目标的一个基本要求是，它们必须足够简单，以便在为冠军做准备所需的有限时间内被所有玩家完全吸收。 如果你专注于遵循 Scrum 仪式而不是真正的工作，你最终会带来混乱而不是秩序。另一方面，如果你采取更务实的方法，保持灵活性，甚至摆脱所有在我们的具体经验中不起作用的东西，你就可以充分利用它。如果您发现某些 Scrum 方法难以遵循，您甚至可以考虑推迟它们，然后尝试在稍后阶段引入它们。 管理经理人 让我们强调一个概念：敏捷方法论，特别是 Scrum，只有在团队成员愿意采用它或者至少意识到它的优势的情况下才能发挥作用。如果只是由公司的管理者引入并跟风告诉外面的世界：“看到了吗？我们很敏捷！”，这是行不通的。让我们明确一点：如果目的只是营销，那么最好假装遵循这些方法。没有必要在内部流程中引入仅具有促销目的的负担。 这个故事的寓意是：敏捷方法只有被工程师和管理者一起采用，而不是仅仅由管理者强加，才能产生一些积极的影响。大多数经理，尤其是那些没有技术背景的经理，对方法论如何影响软件项目的生命周期一无所知，而工程师，尤其是高级工程师却知道。多年的经验胜过最好的书籍和最好的课程。 此外，根据我在意大利公司的奇怪经验，组织通常受到似乎来自某种中世纪遗产的文化的支配。在这种情况下，Scrum Master 甚至产品负责人角色都可以被简单地视为职业道路上的权威来源，而不是操作性角色。 说实话，我最近已经尝试过这个残酷的现实。通常这些人根本不知道什么是方法论的原理，就用他们根本不明白的规则来骚扰人。 在这些可怕的环境中，极限编程和 Scrum 都只是毫无意义的头衔。在这些情况下，管理者是需要处理的熵的来源，为了达到适当的生产力水平，团队必须管理自己的工作，甚至管理者，以减少他们的不良影响。这就解释了本节的标题：“管理经理”。 方法、测试实践、跟踪活动和相关工具之间的平衡 在本文描述的用例中，我们讨论了方法论，还讨论了测试策略、跟踪活动以及用于支持它们的工具。最好的方法论框架本身无法解决软件开发中涉及的所有复杂问题。 事实上，涵盖功能测试的 BDD 是共享正在开发的软件系统逻辑知识的非常有效的方式。它在所有团队成员和产品负责人之间建立了牢固的联系，并提高了对项目更重要方面的关注。因此，它涵盖了 Scrum 应该涵盖的部分问题。 另一方面，单元测试和集成测试更多地参与软件开发人员的内部流程，但它们间接地使更改更容易处理，与 Scrum 的迭代方法很好地耦合。 结论 即使在由单个开发人员处理的最小项目中，软件开发也是一件复杂的事情。如果一个项目需要组建团队，就会出现许多组织问题。敏捷方法论是解决这些问题的一种尝试，但只有持保留态度并避免任何形式的无意义放大，它们才会真正有用。
