scrum软件过程基础浅析

就软件过程框架本身而言，scrum比较好理解，是一种迭代、循序渐进的开发方法，也明白这个框架充分重视了人作为开发主体的重要作用，即不是以文档驱动，而是故事点（代码任务或者说可演示的功能）驱动开发。但就实际而言，这个框架可能不太适合中国软件开发的“行情”，实际效果有待验证。

scrum简介

Scrum是一个轻量级的敏捷开发框架，是一个增量的、迭代的开发过程。其核心准则就是自我管理和迭代开发，可以最大化生产率。

Scrum特点

Scrum好处

Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。

Scrum与XP的关系

Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践，两者相互兼容且相互补充，如结对编程、测试驱动开发、持续集成等XP的最佳实践仍然可以在Scrum中使用。

通过高透明性、检验和适应性来管理复杂性、不可预测性和变化。

p.s. 354很好记

scrum master

做为团队和外部的接口，解决团队开发中的障碍,保证各个角色及职责的良好协作，保证开发过程按计划进行，组织会议，并更新燃尽图

product owner

负责提出和维护产品Backlog

scrum team

SCRUM团队负责在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。自组织，跨职能，一般5-9个人

发布计划会议

只是确立大致交付日期和成本，之后每次迭代开始前均需要依据项目进展情况重新进行调整

确立项目整体发布目标和预期结果
确定产品Backlog条目、重大风险和发布所包含的全部特性和功能
敏捷工作量估算：规模计量单位使用故事点，是一个相对值（区别于传统的人天估算）
- 计算团队速度：一个迭代中团队完成的故事点总数
- 计算迭代周期数：所有故事总的故事点数/团队速度
- 计算项目成本：每个迭代的成本 * 迭代周期数
根据工作量估算确立大致交付日期和费用

Sprint计划会议

确定做什么

介绍最高优先级的产品Backlog条目；选择产品Backlog条目，确定Sprint目标
- 选多少：Sprint计划完成故事点数 = 团队速度 * 120%（120原则）
- 选什么：新用户故事占70%，bugs和技术债务占30%（70/30原则）
确定怎么做

团队成员将产品Backlog分解为多个1天以内可以完成的任务，细分的任务构成Sprint Backlog

每日站会

这个图看起来挺有意思的，精准展现了每日站会，所以贴上。从中也可以看出，敏捷团队的规模只是5-6人左右（还有程序员真的是聪明绝顶（bushi）），中间红衣服的人最有可能是scrum master，纯属猜测。

由scrum master主持，每个开发成员会被问三个问题：

前两个问题的目的是维护任务状态，哪些已完成，哪些未完成。但注意，每日站会不是进度汇报，而是Scrum成员互相的承诺；不是系统设计讨论，遇到的问题应会后解决；会议还应注意时间和效率（10-15分钟），确保 “鸡” 的角色不允许在会议上发言过长。

“鸡的角色”，描述得有点形象，有可能暗示只说不做，不了解任务实现难度，滔滔不绝的人。下面的图emmm很直观

Sprint评审会议

Sprint回顾会议

通过总结以往的实践经验来提高团队生产力

产品 Backlog

SprintBacklog

Sprint 燃尽图

发布燃尽图

前期

产品负责人整理业务需求，形成Product Backlog库
执行
- 以Sprint为单位迭代式地完成Sprint Backlog
- 每个Sprint以Sprint Planning开始，通过每日例会跟踪进度和issue
- Sprint结束时进行评审，交付可运行的产品
后期
- 每个Sprint完成后，通过Sprint回顾发现问题和改进点
- 制定下个Sprint要引入的新的实践