jira培训以及缺陷管理.ppt

敏捷开发缺陷管理JIRA培训
.
敏捷开发
Jira软件介绍
日常操作功能介绍
操作演示
介绍大纲
.
关键实践
自我管理和自我组织的团队
每日15分钟的站立会议以解决固定问题
21天的迭代周期
每次迭代开始于已确认的计划
团队每日进行进度评估
每次迭代需交付测试通过、功能完整的软件
从潜在产品发布开始不超过21天
.
.
要考虑的因素✪价值
✪知识/ 不确定性/ 风险
✪释放吗？
✪依赖
最低市场功能集——首先通过缩小User Story
商业价值是首要- 专注于高价值的功能
经济划算-容易取胜
技术风险的首次登场——首先攻克技术难点
延迟风险——随后做难的事(或者从不)
投票 - ​​请你的团队给予反馈将有助于理解
.
积压产品的Grooming / Sprint 预备计划预备计划备计划
目标:
计划下一个sprint
定义或更新软件体系结构(图)。
识别依赖
提出sprint 的设想和面对的风险(整个sprint; 用户故事)
更新发布版本的计划
会议安排
✪ 划分积压产品的优先级
✪ 定义或更新软件体系结构
✪把庞大的用户故事分解成几个子故事。子故事的结构可以被模块化、重构、重新设计.
✪ 定义接受性准则-了解如何设计、编码和测试计划的结果。
✪ 估计(故事点数),LOE= 交付软件付出的努力(不是指时间).而是要考虑一些比如：复杂性-大小-风险-经验 等因素
✪ 针对整个团队的速度，把优先的工作移动到下一个sprint. 直到sprint 计划开始，一个本组的人显示的帮助提出下个sprint 的内容
✪ 项目能力- 谁需要去做这个工作。 确保我们已经为下个sprint 准备好了资源.
参与者:
产品经理 (PM – BSA, BA), Team Leads (开发 和测试) and SME’s
.
= 所有story的分值 / 一个周期
✪ 工作速度是整个团队在一个sprint中可以做多少工作的一个量度。工作速度是一个周期内实际所做的工作而不是计划的。部分完成的story不是Done的状态。
✪ 在scrum中 Story points 也是一个重点。Story以工作特点作为区分。每个story都有自己的分值。分值可以随你定。
比如1, 2, 3, 5, 8 ,13, 21, 40…... 一个story分数的高低 取决于它的难易程度，风险高低，规模大小，商业价值。假如有6个story，每个story8分，这样的话，整个速度就有48分。
.
多少个sprint backlog项目能同时进行？
这个取决于很多因素：团队的规模，开发测试人员的比例，对产品的熟悉程度，敏捷的水平等
一个优秀的配比规则:
团队规模
同时进行的story(WIP)
5
2
6
3
7
3
8
4
9
4
引用燃尽图检查，sprint是否按照正常轨道按时完成。
这个评估必须在每天结束时的站会完成。
.