1. Scrum框架
●一个Sprint是一个1-4周的迭代，它是一个时间盒。
●Sprint的长度一旦确定，将保持不变。
●Sprint的产出是"完成”的、可用的、潜在可发布的产品增量。
Scrum团队角色
Scrum制品
使用用户故事来描述产品订单
可视化管理
- 任务白板是团队开发的晴雨表,它将团队的任务和进度可视化地展现出来。而引入电子白板可能会削减团队之间的沟通,降低团队的透明度,违背了敏捷重视人和团队的原则。
- 燃尽图以图形化方式展现了剩余工作量( Y轴)与时间( X轴)的关系。
Scrum规划
Scrum活动
- 迭代计划会议在每次迭代(或冲刺)开始时召开,一般是2~4小时,目的是选择和估算本次迭代的工作项。
第一部分:以需求分析为主,选择和排序本次迭代需要实现的订单条目
第二部分:以设计为主,确定系统设计方案和工作内容- 每日站立会
团队在会议中做计划,协调其每日活动,还可以报告和讨论遇到的障碍。
任务板帮助团队聚焦于每日活动上,应在这个时候更新任务板和燃尽图。
每个团队成员需要回答三个问题：
● 上次例会后完成了什么 ?
● 遇到了什么困难(或障碍) ?
● 下次例会前计划做什么?- 迭代评审会议
Scrum团队在会议中向最终用户展示迭代的工作成果,团队成员希望得到反馈,并以之创建或变更Backlog条目。
基本要求：
● 由团队展示有可能发布的产品增量
● 允许所有参与者尝试由团队展示的新功能
● 用户对团队演示的产品功能进行反馈- 迭代回顾会议
每一次迭代完成后，都会举行一次迭代总结会，会上所有团队成员都要反思这个迭代。举行迭代总结会议是为了进行持续过程改进，时间限制在1小时左右。
关键点：
● 会议气氛:团队全员参加,气氛宽松自由,畅所欲言,发现问题和分析原因;
● 关注重点:每次仅就1-3个关键问题做出可行的解决方案;
● 跟踪闭环:可以放入下一次迭代订单中执行改进。
需求在一个Sprint内是不允许变化的
2. 用户故事与估算
用户故事
用户故事( User Story )是从用户角度对功能的简要描述。（包括功能/非功能）
敏捷估算
- 故事点的基本做法
● 给一些简单的"标准故事”设定一个"标准点数”, 形成比较基线;
● 其他故事与标准故事进行比较,给出一个相对的比例,得到该故事的一个估计值。
3. 软件配置管理
软件配置管理是一种标识、组织和控制修改的技术,它作用于整个软件生命周期,其目的是使错误达到最小并最有效地提高生产率。
软件配置项
软件配置项( Software Configuration Item ,简称SCI )是为了配置管理而作为
单独实体处理的一一个工作产品或软件。
版本
版本是在明确定义的时间点上某个配置项的状态;版本管理是对系统不同的版本进行标识和跟踪的过程,从而保证软件技术状态的一致性。
基线
基线( Baseline )是软件配置项的一一个稳定版本,它是进一步开发的基础,只有通过正式的变更控制过程才能改变。
分支管理
分支包含了一个项目的文件树及其发展的历史,记录了一个配置项的发展过程。一个配置项可能选择多个分支,归并是将对分支的修改合并到另一个分支。
