2012-10-08 14:11:42 desert3 阅读数 33
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师
Scrum当中定义了许多角色。按照对开发过程的参与情况,这些角色被分为两组,即[b]猪组和鸡组[/b]。这个分组方法的由来是一个关于[b]猪和鸡合伙开餐馆[/b]的笑话:
一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行”,猪说:“[color=red]我把自己全搭进去了,而你只是参与而已。[/color]”

[b]"猪"组的角色[/b]
猪是在Scrum过程中[color=red]全身投入项目的各种角色[/color],他们在项目中承担实际工作。他们有些像上边那个笑话里的猪,要把自己身上的肉贡献出来。
[list]
[*]产品负责人:[color=red]代表了客户的意愿,这保证了Scrum团队在做从业务角度来说正确的事情[/color]。产品负责人编写用户故事,排出优先级,并放入产品订单。
[*]Scrum主管(或促进者):促进Scrum过程,他的主要工作是[color=red]去除那些影响团队交付冲刺目标的障碍[/color]。Scrum主管并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。
[*]开发团队:负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人(设计者,开发者等)组成,承担实际的开发工作。
[/list]
[b]"鸡"组的角色[/b]
鸡并不是实际Scrum过程的一部分,但是必须考虑他们。 敏捷方法的一个重要方面是[color=red]使得用户和利益相关者参与到过程中[/color]的时间。[color=red]参与每一个冲刺的评审和计划[/color],并提供反馈对于这些人来说是非常重要的。
[list]
[*]用户:软件是为了人而开发的。有人说,“假如森林里有一棵树倒下了,但没有被人听到,那么它算是发出了声音吗?”同样地,人们可以说,“假如软件没有被使用,那么它算是被开发出来了么?”
[*]利益相关者(客户,提供商):影响项目成功的人,但[color=red]只直接参与冲刺评审过程[/color]。
[*]经理:为产品开发团体搭建环境的人。
[/list]
参考:[url=http://zh.wikipedia.org/zh/Scrum]Scrum - 维基百科[/url]
2010-03-14 22:11:00 superch0054 阅读数 1088
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球
虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法

Scrum定义了许多角色,根据猪和鸡的笑话分为两组,猪和鸡
  一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意

,那你准备给餐馆起什么名字呢?”,鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样?”,“我不这么认为”,猪说,“我全身投入,

而你只是参与而已”


冲刺订单(sprint backlog)

燃尽图(burn down chart)是一个公开展示的图表,显示当前冲刺中未完成的任务数目,或在冲刺订单上未完成的订单项的数目。

不要把燃尽图与挣值图相混淆。


以下是一些Scrum的通用实践:
  客户成为开发团队中的一部分。(例如客户肯定对开发的结果真正感兴趣。)和所有其他形式的敏捷软件过程一样,Scrum有频

繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件,同时使得项目可以变更项目需求以适应不

断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。
– 在每一个阶段根据承诺进行风险缓解,监测和管理(风险分析)。  计划和模块开发的透明
– 让每一个人知道谁负责什么,以及什么时候完成。频繁的利益所有人会议,以跟踪项目进展
– 平衡的(发布,客户,员工,过程)仪表板更新
– 利益所有者更新
– 你必须拥有预警机制,例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会

受到惩罚。在工作场所和工作时间内必须全身心投入。
– 完成更多的工作并不意味着需要工作更长时间。

2013-08-08 02:20:05 cpongo9 阅读数 39
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

在敏捷项目中,架构师可以扮演重要的角色吗?还是说,因为他们倾向于“预先做大量设计(big design up front)”而只能成为辅助角色?最近,微软的企业架构师Nick Malik在一篇博文中对该话题进行了探讨,他的结论是,架构师完全可以在使用Scrum的软件项目中扮演关键角色。

\u0026#xD;\n

Malik的博文源于一个项目。在这个项目中,他试图把架构实践活动作用于Scrum过程。在文章的开头,他就立即断言,软件架构与敏捷开发过程并冲突。不过,他也承认,在一个交付周期较短的Scrum项目中,花费数月时间编写文档和图解系统的传统架构实践活动“相当傻”。但是,必须承认,任何软件项目——包括通过Scrum开发过程交付的项目——都有一个基本的软件架构。

\u0026#xD;\n
\u0026#xD;\n

软件架构的价值在于,它对系统自身核心基础设施做一系列关键决策:哪里需要泛化?要使用分层模式吗?如果使用,每一层的职责是什么?每一层包含哪些模块以及为什么要创建这些模块?如何在层和组件之间划分系统的职责?如何将模块进行大规模部署?信息如何在模块之间以及系统与外围系统之间流转?

\u0026#xD;\n

这些问题的答案可以说明一个系统的架构是什么样子。

\u0026#xD;\n
\u0026#xD;\n

据Malik说,做每一项选择都要仔细平衡系统的一连串质量需求。软件架构师在软件架构职责的三个不同层次上工作时均需要考虑这些需求。

\u0026#xD;\n

86a661862cae25aafed52d5df7facd0d.png\"

\u0026#xD;\n

原始地址

\u0026#xD;\n

最上面一层称作“校准过程(Aligning Processes)”,每季度或者每半年发生一次,解决整个组织的信息和商业策略相关的架构问题。这一层的输出是组织的未来软件模型。第二层包括“平衡过程(Balancing Processes)”,它与给定的软件项目相关联,可能发生在前面几次Scrum冲刺的推进过程中。Malik解释说,在这一层会对系统的逻辑架构进行精心设计。

\u0026#xD;\n

这些过程考虑单一系统的需求,但仅仅决定几个方面的问题,包括为什么软件要分成模块、层和组件,如何进行职责划分,以及最终系统使用特定技术部署到特定的环境以后是什么样子。

\u0026#xD;\n

最后,该模型的最底层是“实现过程(Realization Processes)”。据Malik说,这一层是“架构变成软件的地方”,架构师做出具体的设计决 ,软件开发人员按照决定构建系统。Malik承认,开发人员可能不接受架构师选择的设计模式,即便如此,“开发团队还是极有可能按照架构师的描述实现软件架构,但是可以改进它”。

\u0026#xD;\n

那么,在实践中,对于一个给定的Scrum软件开发过程,如何开展这项工作呢?Malik直接在“冲刺规划(Sprint Planning)”会议之前增加了一个阶段。原先,可以从优先“产品待办事项列表(Product Backlog)” 阶段直接进入到冲刺规划会议及后续软件冲刺阶段。现在,项目团队插入了“冲刺前Story审查(Pre-Sprint Story Review)”阶段,用于对Story进行改进及架构评估。

\u0026#xD;\n

533cc1f0f759cb9d516744c22c511b75.png\"

\u0026#xD;\n

原始地址

\u0026#xD;\n

Malik建议在冲刺规划会议前一周执行这个专注于架构的新步骤。

\u0026#xD;\n

在冲刺规划会议前的一周里,那些与产品经理一起工作的人可以改进Story、增加约束、完善描述和验收标准。这时,架构师开始发挥作用。他完成了上述模型中的“平衡”任务,将有(或可以创建)一份描述软件系统架构的概要文档,并且能够把文档与受该设计影响的具体Story“链接”起来。

\u0026#xD;\n

Malik的结论是,在敏捷项目中,一名架构师是“鸡”还是“猪”取决于他在哪一层。在精心设计第一层和第二层的时候,架构师是团队的一名普通参与成员,即扮演“鸡”的角色;当在第三层工作的时候,架构师是一名投入大量时间与精力的参与者,即扮演“猪”的角色。这项由Malik推动的活动继续对架构师在敏捷实践中所扮演的角色进行研究。在今年早些时候的一篇博文中,Malik提出,架构师天生敏捷,他们注重通过增量过程完成高价值的活动,这一点与敏捷精神一致。由于企业试图提高软件开发的效率,同时又希望能够避免增加架构方面的负担,所以敏捷与架构的交点仍然是一个热门领域。

\u0026#xD;\n

查看英文原文:Architects: Chickens or Pigs in an Agile Development Process?

\u0026#xD;\n

感谢马国耀对本文的审校。

\u0026#xD;\n

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

\u0026#xD;\n
2018-09-25 10:55:46 qq_31977125 阅读数 458
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师
让我们来看这么一个故事:
一天,一头猪和一只鸡在路上散步
鸡看了一下猪说:“嗨,我们合伙开一家餐馆怎么样?
猪回头看了一下鸡说:“好主意,那你准备给餐馆卖什么呢?”
鸡想了想说:“餐馆卖火腿和鸡蛋怎么样?”
猪说:“不开了,我全身投入(火腿是一次性资源),而你(鸡蛋是可再生的)只是参与而已!”

在这里插入图片描述

这个故事是Implementing Scrum网站为了解释,什么是Scrum而推出的系列故事中最具代表性的一个,它展示了在Scrum中的两组角色:猪和鸡。

在故事展开之前,我们先来了解一下什么是Scrum。

Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。

好了,回到本文开头的故事。

猪被认为是Scrum团队中的核心成员,在一个团队中产品的负责人和Scrum主管和开发团队就是"猪"角色。

鸡不是Scrum的一部分,但必须要考虑他们,用户、客户或提供商、经理等扮演着“鸡”角色。需要说明的是在Scrum团队中不会有一个人同时成为“猪”角色和“鸡”角色。

我们看看团队中的“猪”都有哪类角色:

产品负责人(Product Owner)

即负责维护产品订单的人,代表利益相关者的利益。

我们可以把这一角色理解为没有项目管理权限的产品经理,他只对产品负责,决定做出来的产品是什么,包含哪些功能要点。传统的软件开发流程中,产品经理是要肩负起一定的项目管理的职责的,产品经理可能同时就是项目经理,甚至在一些企业中CEO就是最大的产品经理。但是在Scrum框架中,产品经理没有项目经理的权限,无权干涉项目开发的进度,项目的成功与失败也不需要产品经理独自承担责任。产品负责人最大的职责就是做好开发团队与客户之间沟通的桥梁,维护好“产品订单”,排列出开发的优先级。简单来说,有没有按时做完项目不是产品负责人的责任,但做出来的东西是不是客户想要的就是产品负责人的事情了。所以产品负责人必须是Scrum团队的一员,和其他成员一起时刻盯着团队开发的是否是“产品订单”中列举的东西。

Scrum主管(Scrum Master)

即为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。Scrum Master需要知道团队其他成员如何完成开发工作。这一角色通常要团队中最资深的那个开发人员来担当比较合适,不仅仅是他的技能可以指导其他成员,更因为他有资历去排除哪些影响Scrum实施的外界干扰。 Scrum Master虽然同样无项目经理的权限,但需要他在关键的时刻站出来,帮团队推掉来自外界甚至是高层临时下达的产品开发需求。

开发团队

由负责自我管理开发产品的人组成的跨职能团队。Scrum教程里倡导的Scrum团队的理想人数是7人,那么即意味着除了1个Product Owner和1个Scrum Master外,开发团队应有5人。开发团队必须是跨职能的,如果大家的技能相同,很容易出现彼此推诿的现象。 每个人都应该明确,自己的工作只有自己才能最好的完成,这样才能组合在一起形成一个团队。另外,开发团队人数不能过多。

Scrum倡导的是自我管理的团队,这其实是违背传统的管理模式的。团队人数少的时候,即使团队中个别人缺乏自我管理的意识,那周围同伴也很容易帮助其提高和改善自我管理的能力。但团队人数一旦很多,出现一群无自我管理意识的人群的时候,那影响的作用力就是相反的,这一小群人会影响周围更多的人,此时Scrum团队又无一个专职的管理者,便会出现“无政府主义”的现象,造成一盘散沙的恶果。
在这里插入图片描述

属于“鸡”的又有哪类角色呢?

用户

在Scrum流程中,虽然不能完全听取用户的意见,但还是得时刻关注用户的感受和反馈。 因为Scrum是一种迭代式增量软件开发的过程,如果每个小模块都能得到用户良好的反馈的话,那无疑最后完工的整个系统出差错的概率会小很多。毕竟用户不是专业软件开发人员,整个系统对其来说过于庞大和复杂,一个个小模块是其能最好理解的单元个体。处理好用户与开发者关系的重要人物就是前面所讲的Product Owner,他必须及时的收集用户的反馈,以此完善每次冲刺的订单,但同时又不能让用户的反馈去影响开发的步骤。

利益所有者(客户,提供商)

在Scrum体系中,一旦开发团队与客户确认好开发需求后,客户应该无权在中间干涉团队是怎么完成的。客户需要了解,随意的更改需求、干涉开发的流程是很危险的,极有可能出现鸡飞蛋打的双输场面。在前期项目立项的时候要尽可能多的和客户接触,完整的记录客户所有的需求。但在开发过程中,特别是每天的站立会中,建议不要让客户,特别是根本不知道什么是Scrum的客户来旁听站立会。

经理

可以把他理解为项目经理或部门经理,甚至是管理产品开发的副总或直接就是老板!这群人就是故事中的鸡爷爷,他们财大气粗,有权有势,为了能开发出新的有竞争力的产品,为小猪们提供了资金和场所,所以他们对产品的意见也是至关重要的。

Scrum实施中一个令工程师们兴奋的就是项目经理将不再管理我们的开发过程,我们自己管理自己。但实际操作起来,这确实是最难的一个环节。

一旦项目经理在Scrum“每日立会”中下达指示,而Scrum Master又没挡住的话,那这个团队的Scrum实施就失败了,团队成员会觉得自己失去了领导的信任,被授予的自我管理的权限又被无情的收回了。

大家又会重新回到原先的模式,每一步听从项目经理的指示,按指示办反正不会有错,失败了是项目经理指示错误的责任,成功了也能跟着项目经理分碗汤喝。

Scrum能否成功实施,很关键的是能否得到高层的认同和理解。一个团队要实施Scrum,首要需要接受培训的就是公司高层领导们,高层领导们要权衡实施Scrum的利弊,如果Scrum能带来高效、优质的开发成果,那就应该忘记Scrum实施过程中给所带来的心灵上的折磨。我们可以合理的定好Scrum团队中每个人的KPI,让每个成员真正意识到项目成功是自己的事,而不是项目经理、高层们的事。

Scrum能否成功实施关键在于“猪”与“鸡”两种角色之间心理上的平衡与和谐!“鸡爷爷”切不可把“小猪”们看成是一群猪八戒,空有一身本领,但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮,只会半夜鸡叫,影响正常的开发进度。猪和鸡双方相互理解,达到项目开展过程中的平衡点,才能让整个项目顺利的完成。

2013-12-10 09:30:11 duheaven 阅读数 2141
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

以下部分转载自:http://developer.51cto.com/art/200907/136850.htm

任何人力流程都离不开人来执行,所以在讲解Scrum流程之前,有必要先把Scrum中的角色讲一下。

一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意,那你准备给餐馆起什么名字呢?”,鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样?”,“我不这么认为”,猪说, “我全身投入,而你只是参与而已”

猪是全身投入项目和Scrum过程的人,有三种角色:产品负责人(Product Owner)、ScrumMaster、团队(Team)。

角色 职责
ProductOwner(PO)
  • 确定产品的功能
  • 决定发布的日期和发布内容
  • 为产品的profitability of the product (ROI)负责
  • 根据市场价值确定功能优先级
  • 在30天内调整功能和调整功能优先级
  • 接受或拒绝接受开发团队的工作成果
ScrumMaster
  • 排除产品开发和产品负责人之间的障碍,确保产品负责人直接推动开发工作
  • 教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标
  • 激发创造力和放权,从而改善开发团队的环境
  • 千方百计实践和工具,确保每个功能增量都具备潜在可交付行

  • 向各方确保团队工作进展实时更新并高度可视
Scrum Team
  • 具有不同特长的团队成员,人数控制在7个左右
  • 确定Sprint目标和具体说明的工作成果
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标
  • 高度的自我管理能力
  • 向Product Owner演示产品功能

鸡角色并不是实际Scrum流程的一部分,但是必须考虑他们。 敏捷方法的一个重要方面是使用户和利益相关者参与到过程中的实践。参与每一个评审和计划,并提供反馈对于这些人来说是非常重要的,管理者就属于鸡。

在知道Scrum的主要角色后,我们看看下图中的过程图:它由Product backlog开始,经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事(story)形成迭代的sprint backlog(一个sprint一般为1个月)。在sprint中会进行每日站会,迭代结束时会进行演示和回顾会议。

Scrum流程图

第一次听到以上术语的可能不能很好的理解backlog和spring之类的东西,大家不用着急,以后会慢慢对每一个过程进行仔细讲解。

以下将对一些术语进行简单介绍,以便大家现在开始逐步了解Scrum。

【Backlog】

Product Backlog

在项目开始的时候,Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性,包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。

在下一篇我将着重讲解如何制定Product Backlog,怎么写故事,如何拆分和合并故事,以及如何确定优先级和进行估算。

Sprint Backlog

Sprint Backlog 是Sprint规划会上产出的一个工作成果. 当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后,这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务,工作量小于2天。Sprint backlog完成后,Scrum team会根据它重新估计工作量,如果这些工作量和原始估计的工作量有较大差异,Scrum team和Product Owner 协商,调整合理得工作量到Sprint中,以确保Sprint的成功实施。

【会议】

Sprint Planning Meeting(Sprint规划会)

根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司,客户就是市场,Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景,规划出今后一段时间产品发展的路线图,以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级。

当为一个Sprint定义好足够多的Product Backlog,并且排列好优先级后Scrum就可以开始了,Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候,Product Owner会和Scrum team一起评审版本,路线图,发布计划,及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum Team按照优先级的高低来确定开发的先后是很重要的。

当Sprint backlog确定后,ScrumMaster带领Scrum Team去分解这些功能点,细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。

Daily Scrum Meeting(每日站会)

一旦计划阶段结束,30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上,每个团队成员需要问3个问题:我昨天做了什么,今天做什么,遇到哪些障碍。谁都可以参加这个会议,但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观,用于发现任何新的依赖,定位项目成员的要求,实时的调整当天开发计划.

Sprint Review Meeting(Sprint评审会)

在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务,市场,技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分,是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式,找出好的方式以后继续发扬,找出需要做的更好的地方,想办法提升。Sprint评审会结束后,新一轮的迭代又继续开始(中间最好修整半天或者隔个周末),迭代会一直继续,直到开发了足够多的功能去交付一个产品。

下面是自己的体会为原创。

首先的项目中还是需要PM参与管理,PM需要管理项目,协调外部的资源,为scrum团队解决比如环境,工期等问题。Scrum的核心是将客户最关心的业务首先交付给用户和项目干系人,如果由于工期原因导致项目部分功能不能如期交付,用户也可以使用这些已经开发完成的核心功能。对于一个sprint执行过程中,是不允许有任何的需求变更的。如果有会安排到下个sprint中。在sprint执行过程中,每天需要控制安排一个20分钟以内的会议,会议会讲三个内容,昨天干了什么,今天干什么,有什么问题需要解决(不深入讨论)。会后会针对这些问题在进行专门会议的讨论。sprint团队的人数不能太多,10个人以下包括QA,每日例会中QA提出的问题列为团队首先解决的问题,如果人数多的话需要拆分。同时一个sprint的任务属于整个团队如果某人因为私人问题离开或者是开发进度慢或其他问题,那么团队里面的其他成员需要帮助完成他的工作,比如QA离开,那么开发需要完成测试,如果不能保证权威性,可以利用截图等手段保证。一个sprint所交付的功能是功能上完整的,经过QA测试的,QA会提供测试报告。如果没有完成会放入下一个sprint。同时scrum team成员需要在一到两个sprint后,召开sprint总结会议,一般情况只有scrum team人员和Master参加,总结执行过程中的成功经验和教训,找到或解决team和队员的问题,注意此会议找到的作用更大,解决可以会后单独沟通,提高团队的整体效率。

下面是自己对于scrum场景的一些理解:

对于国内政府献礼类的项目或某些大型企业的项目我们经常遇到的用户需求朝令夕改,工期过短的问题,scrum并不能够适用,他无法代替加班甚至可能降低效率,如果这种情况,最合适的还是每日开会,然后干不完不能走的强制手段,而且目前国内项目很多都是这种情况,所以如果实施过程中需要具体提前评估,不要领导听了敏捷就认为可以解决加班问题,这个太荒谬了。注意一般一个sprint的计划做的内容是根据你团队有多少人*每天6小时或以下(不是8小时更不是12个小时)*sprint的天数和每个任务估计花费的时间综合算出来的,所以不可能解决加班问题,而且此方案预留了部分比如培训和其他项目的会议的时间。

需要工具辅助scrum团队,比如JIRA,Jenkins,LoadRunner,自动化测试工具等。

Scrun造成对队员的考核有时候不清晰。scrun对于队员的成员要求很高,首先是以团队是否完成作为考核标准的,功过都属于团队。这要求每个队员都从主观上有意愿完成这些任务,这些任务都是在plan里面承诺的,所以要尽力去完成。如果发现完不成队员主动加班,因为这个是自己承诺的。但是这种机制有可能造成某些队员滥竽充数,每一个Sprint都指望着其他队员替他完成工作,注意如果是新的队员加入,老队员一定有义务教他保证他可以独立工作,花费1-2个sprint让他熟悉是非常有必要的,这个不算滥竽充数的。scrum的队员中至少有3-4个人是乐于奉献的,他们是团队的承上启下的关键,最好是每一个成员都有主动承担的意识(这点很难)。新成员也要在进入团队初期养成发现问题即时解决,即时沟通的习惯。

sprint中的滥竽充数的人员的现象表现为:

1)一个问题解决很长时间,问他在哪被卡住了,他只能和你说一些表象,无法深入理解问题,其他人员也无法从沟通中得到任何的有用信息。

2)上班的时候无法专心工作,活没有干完就QQ聊天,上网页等。

3)你把他的问题拿过来之后,可能用了半小时就解决了,但是他已经花费了好几天并且没有向团队说明这个问题,直到你自己发现他。

4)当关心什么时候能够做完的时候,他无法回答你这个问题,即使是没有被卡住的问题

5)已经给了4-5个sprint还是无法接手工作

6)对于他的问题,你和他分享过你的解决方案,他说他已经按照这么做了,但是后来发现根本没有做。

对于以上的人员,我们需要在定期召开sprint总结会议上进行分析,团队成员可以在会上互相批评,会议安排在一个密室里面,注意保密性,分析问题的原因。如果是业务不熟,可以安排培训,如果是技术不理解,也可以安排培训。培训会放在下一个sprint当中。如果是主观上的问题需要和该人员进行沟通,适当时候可以由Master出面要求领导帮助沟通。如在未来2-3个sprint里面仍然无效,可以采用行政手段。

最后附上萌版的流程图:



方法论 - Scrum

阅读数 659

猪和鸡合伙开餐馆

阅读数 2603

没有更多推荐了,返回首页