本次摘录内容来自:
ChrisSims, HillaryLouiseJohnson, 西姆斯, et al. Scrum要素[M]. 人民邮电出版社, 2013.
首先先介绍Scrum的参与角 {MOD},再来介绍Scrum工件,介绍完成后会介绍Scrum的周期,其中Sprint的含义也是迭代,这里是借用书中的名称。
这里是对Scrum的简单介绍,在有敏捷编程的概念上能很好的理解,如果没有,可以看我这一篇博客
软件工程基础摘录。
Scrum参与角 {MOD}
产品负责人
简单点来理解就是想要开发这个软件的客户,由他们提供要求。
Scrum Master
Scrum团队的管理者,主要负责Scrum团队和外界部门之间的协调和交流工作。
Scrum团队
简单点就是程序员。
闲杂人等
我不喜欢那些书上的称呼,他们一般叫其余人员“鸡和猪”。。。。。。。
Scrum工件
产品列表
就是记录客户需求的清单或者列表。
Sprint列表
本次Sprint(迭代)中需要完成的需求清单。
燃图
剩余工作量随时间变化的轨迹。就像下图一样:
燃尽示意图
其中,横坐标表示迭代的次数,
注意!!!这个是记录!不是每次的估计,更不要去估计!
任务点表示未完成的用户需求。总感觉看着这种图亚历山大啊。还有,燃图也好,燃尽图也好,都是一个名称而已,懂就好,音译中嘛。
Sprint燃图
跟燃图的功能一样,外观也差不多,就是把代表每次迭代的横坐标换成了每天的工作量。全部需求换成了本次Sprint(迭代)中所要完成的需求。
任务板
形似与下面的东西:
任务板示意图
完成定义
需要Scrum团队一起定义每个任务点的“完成”的含义,感觉蛮对的哎。
Scrum周期
Sprint演示
其中可以看出举行会议大致的时间点,而且也不一定限制在一周之内,只是一般鼓励一周进行一次Sprint(迭代),所以这里拿一周做例子。下面就讲讲这些会议的内容。
Sprint规划会议
顾名思义,就是规划本次Sprint的会议,这个会议一般具有两个主题:
- 根据本次Sprint所要完成的需求,Scrum列出具体任务
- Scrum团队根据这些任务估算时间
Scrum日会
也就是上面的站立会议,只有Scrum Master和Scrum团队参加,具体就是团队成员轮流讲述下面的内容:
- 自从上次Scrum日会后,我完成了哪些任务
- 到下一次Scrum日会后,我将完成哪些任务
- 我遇到的最大障碍
这个是另外一本书中说要加入的内容
- 是否需要更新Sprint列表
- 我从同组成员那是否有学到新的知识
故事时间
也可以叫“Sprint列表修改时间”,你就知道他是干什么的了吧。
Sprint评审
就是请产品负责人到场,然后给他演示本次Sprint的成果。大致上就是干这个的。
回顾
类似于期末总结大会吧。。。。。。。。。
还有,虽然会议很多,很频繁,但是基本上都是在15分钟到1个小时之间。
Scrum参与者具体职责讲解
有了上面的认知,就可以来看下面的各个参与者具体的职责范围了。
产品负责人
就是对产品拥有“最终解释权”,愿景可以理解成用户需求的集合,也可以理解成软件最终实现的功能。
Scrum不像XP(极限编程)要求客户全程,全职陪同开发团队,但是Scrum也还是要求能有一个客户代表来解释具体需求,确定迭代需求和评审迭代产品。
就是产品列表是由产品负责人负责编写的。
就是确定每次Sprint的需求,这些需求来自“用户故事”,所以这里也叫规定故事优先级。
上面的“完成定义”是针对Scrum团队来说的,但是针对每次Sprint评审的最终检验还是产品负责人来验收的,所以这里就叫“设定故事的接受标准”。
Scrum Master具体职责讲解
Scrum Master需要确定本次软件开发按照Scrum的要求进行,同时针对其中的一些问题进行解决。
Scrum Master不是纯粹的管理者,他拥有一些管理职责,但是更希望团队能自主去完成工作,他只会在团队成员需要资源时提供帮助,而不是指导或者规划好时间安排,然后强制团队去执行。这在另外一本书上也叫“服务式管理”。
Scrum团队
- 完成每次迭代中的需求
- 做所有的开发工作
- 自组织地工作
总结
Scrum是一款轻量级的软件开发模型,他只是给出了大致的建议,并没有对开发过程做出具体要求。同时,每个开发团队采用的方式都不尽相同,所以没有固定的模式,但是作为第一次接触敏捷开发或者Scrum开发的人,看完这篇博客应该能有一个具体的了解,也能明白一些名词的解释,我也是为了自己以后能借这篇博客来回忆一些知识点写的,可能不详尽,可能有错误,还请谅解。