在之前的文章DevOps中，简单提及了敏捷开发。敏捷开发是以为客户创造价值的思维为前提，鼓励尽早并持续的交付可工作的软件。其中一个关键的部分在于用以客户为中心的方式去定义用户故事中的产品，同时敏捷还鼓励跨职能的交流协作，强调灵活性和快速应对变化，敏捷时通过不断的实验和反馈来持续改善产品的方法。
敏捷开发的核心理念记录在2001年签署的敏捷宣言中，如图示。
本文将简要介绍最常见的敏捷方法Scrum和看板之一的Scrum。
Scrum是一种广受欢迎的敏捷框架，它的关键点在于团队是以时间盒「Time-boxed」为单位逐步累加地进行工作，即限定某些工作在特定的时间范围内完成。在这个特定的时间范围内所完成的工作，被称为一次迭代或一次冲刺「Sprint」，其持续的时间是固定的。通常是两周的冲刺期，或者一周、三周等。
Scrum的基本单位是Scrum团队，由一名Scrum导师「Scrum Master」，一名产品负责人「Product Owner」和开发成员「Developers」组成。「通常不超过10人，5～9人为佳，详情可查看Scrum指南2020版」
Scrum导师负责促进团队的Scrum实践以及提升Scrum团队生产力。大型企业可能会配置一名导师参与到一个或多个Scrum团队中，不过dev lead或者dev manager常常会兼任这个职位，也有团队要么直接忽略要么由多名团队成员共同分担其职责。
产品负责人负责将Scrum团队生产的产品价值最大化。团队完成的所有工作就源自该产品待办事项列表「Product Backlog」，用户故事是很不错的待办列表实践，产品负责人将从客户、股东那里收集到的反馈，整理编写成用户故事，并按优先顺序放入产品待办事项列表。团队中通常由产品经理担任产品负责人的角色，有些小型初创公司，可能会直接由创始人来承担这部分工作。
开发团队成员致力于在每次Sprint中创造各方面可用增量的团队成员。团队中往往包括几名开发人员，来评估用户故事的规模范围并构建产品。其他重要的角色分别是用户体验师、视觉设计师、品质保证测试员，虽然Scrum指南并不区分个其角色，但明确他们的职责会更有帮助。
在每个冲刺期之前，团队都需要开展特定的准备活动。产品负责人会完善产品待办事项列表，确保下阶段的用户故事编写完好并被全体成员所理解。产品负责人会和团队成员「包括Scrum导师，开发成员」通过待办任务细化会议「backlog grooming meeting」来一起完成这件事。
下图绘制了Scrum的工作流程、相关会议以及交付材料。
冲刺开始时团队举行一次冲刺计划会议，决定在这次迭代中应该完成那些用户故事，并将其从产品待办事项列表取出，移至冲刺待办事项列表。应选取产品待办事项中高优先级的用户故事，并且其故事点数与团队预期的工作速度相匹配。在制订好冲刺计划之前，团队应对在这次迭代周期内，计划需要完成的用户故事有清晰的认识。
在这个过程中需要完成的一项工作就是用故事点法来预估每个故事的规模。「“计划扑克/Planning Poker”是一种快速生成可靠预估的技巧」那些粗颗粒度、范围大、难以在一次迭代中完成的用户故事被称之为史诗故事 (Epics)，必须加以分解后才能进入下一冲刺阶段。
团队在冲刺迭代期间，每天都会有大约15分钟左右的例会，来简要概述他们前一天的工作、当天的计划以及目前进展过程中遇到的障碍等。
有许多 Scrum工具可以帮助团队管理记录他们的工作，如之前的JIRA、国内的PingCode、禅道等，还可以使用燃尽图「Burndown Chart」来表示本次迭代期中还剩哪些工作有待完成。
每个冲刺期的最后成功都以“增量形式”添加新的产品功能。Scrum原则要求清晰描述「完成的定义标准」，对许多团队而言，“完成”意味着产品可供交付，称为“可交付产品”或“与发布产品”。
在冲刺期结束时，团队会举行一次冲刺评审会议来展示所创建的产品，这有助于确保产品能按预期计划推进，并让所有人都知晓当前进度。「理想的情况是客户或其他利益相关者也会参与评审会议并给出反馈」
Scrum重视不断改进团队内的流程，所以会安排冲刺回顾会议反思最近一次迭代冲刺的状况，成员讨论之前的成功与不足之处，以及在下次迭代中应如何改进。
网友评论