模式介绍
视频内容请参考此处。
什么是敏捷研发
敏捷研发是涉及整个软件工程的理念与实践，它的核心是迭代和增量式软件开发方法。开发者快速发布一个可运行但不完美的版本投入市场，在后续迭代中根据用户的反馈改进产品，新增一到多个用户可以感知的完整功能，从而逼近产品的最终形态。
敏捷研发比较特别的地方是：它是组织文化、流程以及工具的结合体。在敏捷研发中要着重强调“工具、流程、组织文化”三者同样重要而且缺一不可。缺少工具支持的敏捷研发无法实现“高速”，缺少组织文化支持的敏捷研发会让团队成员之间无法团结一致完成共同的目标。
CODING 承载了最先进的敏捷研发理论，能够帮助团队快速入门敏捷研发，并通过标准化的流程和完整的信息统计成为企业实践敏捷研发的好工具。
关于 Scrum 敏捷项目管理模式
CODING 的 Scrum 敏捷项目管理模式适用于迭代驱动型的团队。这类团队通过短周期的快速试验来暴露自身所面对的潜在问题，并不断检视与调整来持续改进产品、团队和工作环境，从而高效并创造性地交付最高价值的产品。
对效率的要求使得敏捷协作理念的受众已远超 IT 人员这一群体，这套理念面向的受众也趋于多样化。有运营团队基于 CODING 项目协同进行活动策划、有产品经理使用这套理念协调开发项目；Scrum 敏捷项目管理模式为各类团队提供了实践 Scrum 的可能性。
扩展阅读——《深度解读最新版 Scrum 指南》
模式特性
Scrum 敏捷项目管理模式提供了以迭代与事项（史诗、用户故事、需求、缺陷、任务、子工作项）为核心的任务协同工具。面临一个大型任务时，可以将其作为「史诗」进行编写，再具体至工作细节的需求、任务、缺陷管理等。敏捷协作的关键在于先快速发布一个有效但不完美的最简版本；每一次迭代都包含规划、设计、编码、测试、评估五个步骤。在这样不断改进产品，添加新功能的正向工作流内，通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
在 CODING Scrum 敏捷项目管理模式下，工作流（迭代、史诗、用户故事、需求、缺陷、任务、子工作项）之间的层级关系可以大体概括为下图：
迭代
迭代是敏捷研发的横轴，意为时间冲刺（Sprint），指团队完成一定数量工作所需的短暂、固定的周期。迭代的生命周期按先后顺序依次为未开始、进行中和已完成三个阶段。在迭代式开发方法中，整个开发工作被组织为一系列短小的、固定长度（如 2 周）的小项目，被称为一系列的迭代。
史诗
史诗是敏捷研发的纵轴，初次使用史诗管理前需要开启史诗。史诗可以将大型工作拆解为细致入微的事项，通常一个史诗要经历多次迭代才能完成。敏捷史诗的范围是灵活的，基于客户反馈和团队开发节奏灵活调整其下需求和任务。可以将史诗分解为粒度较小的需求和任务，并将它们安排到迭代中去完成。
用户故事
用户故事是敏捷框架中最小的工作单元，是从用户角度描述软件如何为其带来特定的价值，是敏捷研发模式中需求敏捷化的重要手段。一个好的用户故事包括以下三个要素：
- 角色：谁要使用这个功能；
- 活动：需要完成什么样的功能；
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
需求
需求是指用户解决某一问题或达到某一目标所需的软件功能，它帮助团队成员跟踪更加具体细节的问题。通常一个需求的粒度是可以在一个迭代当中完成的，一个迭代会完成若干个到几十个需求不等。
任务
任务是指为实现某个目标所进行的具体活动。一个任务的粒度也是可以在一个迭代当中完成的，一个迭代会完成若干个到几十个任务不等。一个任务还可以关联或拆分为数个子工作项，自如管控任务分发。
缺陷
缺陷是指不符合最初定义的业务需求，其覆盖范围高于 Bug，除了错误编码外其他导致不符合最初定义的业务需求问题都属于缺陷范畴。
开启 Scrum 敏捷项目管理模式
下文将以常见的敏捷研发工作流为例，演示如何在 CODING 内实践 Scrum 敏捷项目管理模式。
创建项目
敏捷研发的第一步是确认敏捷团队的人员构成。一般而言，敏捷团队有三个角色：
- 具备决策的产品负责人（Product Owner）；
- 为团队提供敏捷流程服务的敏捷教练（Scrum Master）；
- 开发人员（Developers）。
确认成员后，在 CODING 中创建一个用于此次敏捷研发的项目，在初次进入「项目协同」时选择「Scrum 敏捷管理」，并将团队中所有成员加入到该项目中。
第一个迭代
配合迭代计划会议，在会上将本次迭代所需进行的工作都清晰定义，团队成员达成共识后，Scrum Master 负责将规划好的用户故事、需求、缺陷和工作添加进迭代中，并设定好开始和结束时间，就可以开始第一个迭代周期。在这个过程中，团队成员可以根据迭代模块中的统计面板调整自己手上的工作，而如何确保迭代按照原计划进行则是 Scrum 负责人所最关心的。
在迭代开始后，团队需要通过每天早上开站立会议来讨论和解决在执行过程中发现的问题。每天的站立会议尽可能的精简，控制在半个小时以内，团队成员每天早上需要描述昨天做的事情，今天要做的事情，以及遇到的问题。当有问题出现，相关人员需要一起协力解决。
需求管理
在需求管理模块内，产品负责人可以制定项目的产品规划（Product Backlog）并负责维护、更新、分配或由开发人员认领相关用户故事与需求。在撰写用户故事和需求时，可以制定优先级、处理人、截止日期等关键信息，还支持文件上传，关联外部资源等。
测试管理
一般来说每次迭代会产出一个可上线的版本，在正式部署之前还有一个重要的环节：测试。测试工程师可以根据功能情况，在 CODING 内编写测试用例、规划和执行测试计划。在测试计划的执行过程中，会发现项目中的一些问题，称之为 Bug 以及缺陷。除了错误编码外其他导致不符合最初定义的业务需求问题都属于缺陷范畴，所以在后续的迭代中，还需要将缺陷考虑进来。
关于测试管理的详细内容，可查阅《测试管理》。
缺陷管理
在测试环节和正式上线之后发现的问题，都可以在 CODING 缺陷管理模块中归纳统一，并排出优先级作为下一个迭代中的工作来源之一。不过也要具体问题具体分析，紧急程度高的缺陷需要第一时间反馈到产品进行修复，优先级不高的缺陷可以安排至后续迭代修复。缺陷管理具有强大的统计功能，对缺陷类型、优先级、模块、发现时间等关键指标进行了全面的统计，方便测试工程师了解整体进度。
结束第一个迭代
不论迭代内的事务是否完成，到达预设的结束时间即意味着迭代周期的结束。而在迭代真正结束之前，需要由相应的产品负责人（Product Owner）对所有的成果进行评估，重新审视事务完成情况，计算距离设想目标的达成率。在所有事务评审完成之后，Scrum Master 就可以点击迭代中完成迭代的按钮，正式宣告本次迭代结束。
最后整个团队还需要进行一次回顾会议，回顾这次迭代哪些地方做的好，哪些地方仍有遗漏，并列出下次的可执行任务，便于改进整个团队的研发效能。
开启新的迭代
敏捷研发的核心在于多个短频快的迭代，每个迭代环环相扣，在迭代中验证产品功能与市场反应，交付有价值的产品。想要更好地实践敏捷，除了选对合适的流程和工具之外，组织的支持也是必不可少。每个团队各自面临的问题也不尽相同，实践敏捷本身就是一个迭代的过程，每次回顾总结提炼的问题都将成为团队内宝贵的经验。
2023-10-12最近更新在阅读中是否遇到以下问题？*
您希望我们如何改进？*
如果您希望得到回复，请留下您的邮箱地址。
