Open felix-cao opened 4 years ago
felix-cao
commented
4 years ago 参考这篇文章： https://blog.csdn.net/liuyinfei_java/article/details/79708307
进入项目列表，点击某一项目进入项目设置页面
管理->应用程序->Jira Software 设置 -> 勾选 '并行 sprint'
felix-cao
commented
4 years ago 在 Jira 中翻译为 ‘问题’
在Scrum 中，经过识别解析得到的用户故事、开发任务、测试得到的BUG等等统称为事项（Issue）。
在Scrum项目中，Epic 是指从用户需求中识别出来的在一定程度上相互独立、而内部则相对联系的需求集合，例如系统管理模块、用户认证模块等等。
也就是说，一篇史诗是由一系列用户故事组成的故事集。通常用 Epic 大致描述系统模块的功能概要或需求范围，但不应描述细节。
Task 是明确定义了输入输出、技术指标和其他具体要求的任务说明。对于从 Story 中具现的任务，一般直接从 Story 中开出 Sub-task。如果 Story 足够小，则不必再开出 Sub-task，可直接将Story作为任务交给具体人员去完成。
新增的用户需求。并非对已有用户故事的细化或者完善，而是指新的用户故事。尽量杜绝在一次冲刺中间插入新特性，应当把他作为用户故事规划到 Backlog 里，再根据其优先级安排到以后的冲刺中。所以在 JIRA 中，尽量不要创建 New feature。
Improvement 指改善性的微小需求变更，是对已完成的用户故事的细微优化调整。这些调整一般不涉及具体功能的变更，而是基于用户体验的细节优化，不足以形成新的用户故事。
一、Scrum 概述
把工作细分成细小、实在的交付成果，交排人员负责需求清单以及跟据重要性排优先级别，由团队估算每个项目相对工量。
把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
二、Scrum 三种角色
Product Owner：产品负责人，确定「大家要做什么」。一般由相关的产品经理担任；如果是为客户做项目，PO 一般就是客户负责人。Scrum Master：Scrum的推动者，掌控大节奏的人。Team：一般由多个developer组成，开发的主力。三、Scrum 执行流程
上图概言之，就是
1、产品经理整理出需求列表，做好优先级排序，这些需求可以来自客户或者产品经理的判断
2、开个会，和研发团队一起讨论需求列表的工作量，确定要进行Sprint（冲刺开发）的任务
3、研发团队进入开发环节，这个期间可以让产品经理修改需求，但是不得延期或修改验收标准。
Sprint期间每天要进行站会，汇报工作进展、问题和下一步计划4、再开个会，和产品经理一起验收产品，并确定最终的可发布版本。
5、整个团队一起回顾项目，提出改进点，然后进入下一个
Sprint四、一些概念
4.1、Sprint 迭代周期
在敏捷开发领域，迭代=冲刺，这里有一篇不错的文章供参考《迭代=冲刺？》，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的长度是1到4周。
4.2、Team
Scrum Team，推荐人数在5-10人左右，可以按需组建相应的团队等。如根据所开发的软件系统特点，将全员分成4个小组，分别是管理和产品组、前端组A、后端组B、测试组。
4.3、Product Backlog 产品待办事项列表
即产品待办事项列表，也被称为用户故事，是量化的用户需求。即
PO、Scrum Master、Team围绕产品创建一个团队需要做的所有事情的列表。然后产品负责人进行筛选并按照优先级进行排序，以商业价值作为排序的主要原则，从Product Backlog中挑选高优先级的需求进行开发，挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称它为Sprint backlog。Product backlog中列举了本项目应该实现的需求，需求采用了User Story的方式进行描述，User Story是一句简短的采用用户熟悉的术语表达的需求，是从用户的角度提出问题并找到解决问题的方案，进而分解出可执行的Task。 故事可以有标准的格式，称为三段论式故事，哪三段呢？比如，有这样一个故事： 作为一个家庭主妇，我需要一个30平米的餐厅，以便于我可以招待10位朋友来用餐，光线明亮。
除了用户故事本身之外，还包括用户故事的验收标准，或者叫用户故事的测试要点，这也是由
product owner来完成的，product owner可以先完成前三段，在和team member的沟通过程中，逐步丰富完善验收标准。Product backlog在项目进展过程中是会发生变化的，只有product owner有权来修改此文档。可以用EXCEL文件来管理它。Product backlog= 用户故事 + 优先级 + 验收标准4.4、Sprint Backlog
即任务列表，是一次迭代中团队需要完成的具体任务，也是开发过程用得最多的
Backlog，非常细化。当Scrum团队完成Sprint backlog列表中的所有任务时，本次Sprint结束，进入下一个Sprint迭代周期。可以用Jira类敏捷工具来管理。每个月，团队都努力实现列表最顶端的任务，这一部分是他们估计需要一个月完成的工作。把它展开成一个详细的任务列表，叫做
Sprint Backlog。这个团队承诺在月底向出资人演示或交付结果。用故事点的方式，即用斐波那契数列的数字（1，2，3，5，8，13，21……）的形式去估算时间。单个用户故事点数不超过8是最理性的状态，超过21则需要拆分。Product Backlog和Sprint Backlog两者区别如图所示。4.5、燃尽图和看板
4.5.1、燃尽图, Burn-down Chart
即实时评估完成任务数量和剩余时间的趋势。每天
Scrum Master都会记录待完成的剩余点数，而后画在燃尽图上。可以使用Jira系统的燃尽图。对此图的研判规则如下：
1）如果趋势线在控制线以下，说明进展顺利，有比较大的概率按期或提前完工； 2）如果趋势线在控制线以上，说明有比较大的概率延期，此时需要关注进度了。
注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏的任务时，估计剩余的工作量也有可能在某天上升了。
每天开完15分钟站立会议后，由
scrum master根据进展更新燃尽图。第1个点是项目最初的工作量估计值，第2个点是第最初的估计工作量减去第1天已经完成的任务的工作量，依次类推计算后续的点。任务完成的标志是什么呢？准则如下： 1）开发人员检测：所有的单元测试用例都通过； 2）Product owner或测试人员检测：通过了所有的功能测试；燃尽图最好是张贴在白板上，让每个人项目组成员抬头就能看见，这样给大家一个明确的视觉效果，每个人随时都能看到我们离目标有多远。燃尽图可以每天画，表示完成某个迭代的进展趋势，也可以某次迭代结束的时候画，表示完成整个项目的进展趋势，此时横坐标就是迭代的顺序号。
4.5.2、看板
让工作透明化除了使用燃尽图之外，还有看板。看板的栏目大致包括待办事项、进行中事项以及已完成事项三个部分。随着迭代进度的推进，由
Team每天及时将事项转移到对应看板栏目下。4.6、任务申领
原则上，奉行
Scrum各个组里的成员主动申领任务。4.7、
Scrum四种会议在
SCRUM方法中定义了4种会议活动：即Sprint规划会(Sprint Planning)。这是第一场Scrum会议。团队成员、Scrum Master以及产品负责人坐到一起，规划冲刺的内容。PO 向大家介绍排好序的产品待办事项（Production Backlog），然后大家共同思考决定如何推进计划，梳理出 Sprint Backlog 来完成后续的工作。简单点说，就是一个大家理解「需要做什么」，然后讨论「怎么完成」，并形成待办事项列表的会议。 冲刺周期一般是固定的，不超过一个月，一般是2-4周。团队要从待办事项清单的顶端着手（即从最重要的事项着手），评估一个冲刺阶段能完成多少。
Daily meeting 即每日站会，每天团队都面对面地开5～10分钟的会。每日例会后每个人更新自己的任务表，还要每天更新下燃尽图。 1）昨天我完成了什么工作？ 2）今天我打算做什么工作？ 3）我遇到了哪些困难，打算怎么办，或需要哪些帮助？
Sprint review
即Sprint评估或展示会议(Sprint Review)。在冲刺结束前，给产品负责人展示成果，也就是展示哪些事项可以挪到“完成事项”那一栏，并接受评价。这是一场公开的会议，任何人都可以是参与者，不仅仅包括产品负责人、ScrumMaster及开发团队，还包括利益相关者、管理人员与客户。团队应该只展示那些符合“完成定义”的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完整的产品，但至少是一项完整的、可以使用的功能。
除去开发活动外这4种会议构成了scrum方法的核心活动。这四种会议的要点如下。
最后，敏捷开发在线协作工具，有Jira、Teambition和Worktitle等。