分享到
敏捷开发-scrum 迭代式增量开发
 

作者:guoqiuyu_gqy,发布于2011-11-18

 

Scrum概念

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。

虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums.

Scrum过程   

Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

在每一次冲刺(一个15到30 天周期 ,长度由开发团队决定),开发团队创建可用的(可以随时推出)软件的一个增量。每一个冲刺所要实现的特性来自产品订单(product backlog), 产品订单是按照优先级排列的要完成的工作的概要的需求。那些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中,产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中,没有人能够变更冲刺订单(sprint backlog),这意味着在一个冲刺中需求是被冻结的。

Scrum中的角色  

Scrum定义了许多角色,根据猪和鸡的笑话分为两组,猪和鸡。一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意,那你准备给餐馆卖什么呢?”,鸡想了想说“餐馆卖火腿和鸡蛋怎么样?”,“我不这么认为”,猪说,“我全身投入,而你只是参与而已”

1、"猪"角色  

猪 是全身投入项目和Scrum过程的人; they are the ones with "their bacon on the line."   产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事,排出优先级,并放入产品订单。Scrum主管(或促进者)Scrum主管促进 Scrum过程,他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导(由于他们是自我组织的),而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人(设计者,开发者等)组成的小团队完成实际的开发工作。

2、"鸡"角色  

鸡角色并不是实际Scrum过程的一部分,但是必须考虑他们。 敏捷 方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划,并提供反馈对于这些人来说是非常重要的。   用户软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”利益所有者(客户,提供商)影响项目成功的人,但只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人 。

Scrum会议  

在冲刺中,每一天都会举行项目状况会议,被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则: 会议准时开始。欢迎所有人参加,但只有"猪"可以发言。不论团队规模大小,会议被限制在15分钟。保持会议简短,会议应在固定地点和每天的同一时间举行。在会议上,每个团队成员需要回答三个问题:

今天你完成了那些工作?明天你打算做什么?完成你的目标是否存在什么障碍?(Scrum主管需要记下这些障碍)每一个冲刺完成后,都会举行一次冲刺回顾会议,在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作,进行口头交流,以及强调项目有关的规范(disciplines),这些有助于创造自我组织的团队。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意,变更他们的需求,而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样,Scrum采用了经验方法– 承认问题无法完全理解或定义,而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

自适应的项目管理(适用需求的变更)

以下是一些Scrum的通用实践:

客户成为开发团队中的一部分。(例如客户肯定对开发的结果真正感兴趣。)和所有其他形式的敏捷软件过程一样,Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件,同时使得项目可以变更项目需求以适应不断变化的需求。

频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解,监测和管理(风险分析)。

计划和模块开发的透明 – 让每一个人知道谁负责什么,以及什么时候完成。

频繁的利益所有人会议,以跟踪项目进展 – 平衡的(发布,客户,员工,过程)仪表板更新 – 利益所有者更新 – 你必须拥有预警机制,例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。


 
相关文章

由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
 
相关文档

统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
 
相关课程

IT安全原理、框架与实践
ITIL认证
ITIL Foundation认证培训(ITIL V3 Foundation )
IT规划体系与实践
 
分享到
 
 
     

相关文章
由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   

相关培训课程
统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

成功案例
某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号