• Cal-ii
  • Hardware-agile-practice
  • 2020-scrum-guide-banner
  • Clp
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 汽车行业敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
ShineScrum分享 大型敏捷项目中的规划——敏捷规划中的五个层次
If you're having trouble viewing this email, you may see it online.

ShineScrum 分享
国际知名Scrum认证大师Hubert Smits易埙1月来华首次授课
ShineScrum ——全球领先的敏捷及Scrum专业培训咨询机构
     国际知名Scrum认证大师
  Hubert Smits易埙首次来华授业解惑
Hubert Smits 易埙
资深认证Scrum培训师、国际知名敏捷顾问、Scrum导入及组织转型专家Hubert Smits,作为ShineScrum的金牌签约讲师,将于2014年1月份首次来华培训CSM认证课程。作为一位认证的Scrum培训师,Hubert Smits已经完成了180次课程培训,共计培训学员2500多名。他曾发表多篇关于Scrum、敏捷项目计划及敏捷项目扩展的文章,还经常在各种大型会议中就这些话题进行演讲。作为资深的Scrum培训师,Hubert Smits以他丰富的教学经验、多样化的授课形式,获得了学员的一致认可和好评。
       Hubert Smits易埙是一位具有创新精神、有主见并且以目标为导向的敏捷顾问、教练和培训者。他曾成功带领企业级敏捷和精益软件开发。作为思科语音技术的首席顾问,他设计并实施的敏捷软件迭代开发流程取代了多年的瀑布式流程。包括高管、产品经理、项目经理以及开发团队在内的3000多名参与产品开发的员工都成功地参与到Scrum流程中,并在其中找到了自己的角色。
       易埙的客户和成功经验包括像甲骨文、Avaya公司、BMC软件公司、AOL、芬达、通用电气能源、Amdocs公司、思科以及Compete公司。他拥有和全球的分布式团队协同工作的经验,并已签约培训了印度、阿根廷、以色列以及欧洲地区的众多团队。
       敏锐的商业头脑使易埙成为一个具有强大谈判、解决问题和团队建设能力的出色沟通协调专家。他喜欢利用敏捷的原则和实践来调动团队、建立目标、促进积极的组织变革、提高团队表现、提高产品质量,从而减少人员流失。
       易埙擅长大型产品的开发工作,擅长在组织中渐进式地进行敏捷实践改革。他对重组软件开发流程,与IT各方协作,管理因组织变化而对财务、产品管理、市场营销、销售方面造成的影响很有信心。除了与Cutter、IEEE合作出版之外,易埙还经常作为敏捷大会的演讲者并已发表关于分布式团队规划、敏捷规划及跟踪的文章。

学员反馈:
      Hubert和他这门课程,用一句话来讲,简直是太棒了。即使我们呆在会议室整整两天,参与讲座、讨论、活动。我会继续参考课程小册子和Hubert的额外资源,并向我的同事们推荐这门课程。  ——Anna,项目经理
      Hubert就像是我见到过的发言极其流畅的演讲者一样。    ——Gwydion,客户总监
      这是一个很好的课程 - Hubert是一位天才教练,他能够教授理论知识并提供实践指导。     ——Ann,项目经理
      优秀的培训师,广阔的敏捷专业知识。根据课上反馈授课,大量趣味练习使得课程非常有趣。    ——Veni,项目经理
      精彩的会议,得到了Scrum敏捷概念的详细信息。我将会向所有正在从瀑布式或RUP开发方法向敏捷转型的人员推荐这个培训。很清晰、很具描述性和精彩的例子和课堂任务。在课程结束之后,你最终一定会成为认证的Scrum Master。     ——Viral,测试专家
      精彩的、极富价值的培训,伟大的培训师。    ——George,VP系统解决方案
      
      下面这篇文章就是Scrum认证大师Hubert Smits易埙的亲笔力作,文章讲述了敏捷规划流程中的五个层次及其原则和特征,推荐与各位共享!
大型敏捷项目中的规划——
                     敏捷规划中的五个层次
        在敏捷方法中,加载一个团队工作是通过迭代规划完成的。由于迭代的急促性(通常是一到六个星期)一次计划的重要性收益减少而做计划的重要性收益增加。对于小项目来说,在一个时间段内只计划一个单次迭代可能是很充分的。迭代计划应用到运行多个迭代或多个团队项目经历的缺点是迭代活动的长期影响的视角可能会被忽略。换句话说:“宏观” 视角的都将丢失。一个解决办法是增加规划的层次来整合“宏观上”的视角。在计划驱动和瀑布方法中,这个问题通过前期大量的设计被克服了,旨在准确预测每个项目的任务工作量是多少。这会导致在项目前期投入大量的资金,而所设计出来的产品功能不确定是否符合产品负责人的预期。一个具有多层次规划的解决方案将会避免重复前面大量的设计工作。  
大规模研发工作的计划活动应该依赖五个层次:
  • 产品愿景
  • 产品路线图
  • 发布计划
  • Sprint计划
  • 每日承诺
在五个层次的每个层次中开展活动的确定性增加,因此,大量的细节(投资的钱)、涉及的人数、频率会增加,并且没有将资金浪费在未开发或以不同方式开发的功能上的风险。  
五个层次规划的基本规划原则:优先级,估算和承诺。  
产品愿景——第一层次
        愿景就是产品负责人对产品未来最广阔图景的描述。在这个愿景中,她解释了一个组织或产品应该如何呈现。她会指出哪部分系统需要改变(优先级)以及应该付出哪些努力来达到目标(估算和承诺)。
产品愿景——如何做
        一个远景规划工作的可能结构是创建一个电梯声明或一个产品愿景盒。这两项工作的原则是创建语句来描述将来期望产品的特征、目标客户以及与以前的产品或者有竞争力产品的关键差分点。
        杰弗里•穆尔在他的电梯声明中使用下列结构:“对于 (目标客户)来讲, 谁 (阐述需求) (产品名称) 是一个 (产品目录) 以及 (产品关键收益, 购买原因). 不像 (一般的竞争对手的主流产品), 我们的产品 (对主要区别作最后的陈述).”产品愿景描述产品在将来12个月或以上的状态。进一步的规划(设计)活动将细化愿景,并可能从最初的愿景上转移,因为未来将使我们改变看待市场、产品以及为将愿景变成现实所付出的努力的角度。  
产品路线图——第二层次
        大型项目几年后交付的时代已经离我们远去。客户要求会更频繁地变化,典型的产品上市的时间表只需要数周以至数月。更高的频率和更小的时间表迫使产品负责人不得不思考一步步通往最终产品的路线。就像把前期计划好的旅途路线与同路人分享、沟通一样。创建产品路线图,并与交付团队沟通这样做的目标是为了让产品负责人能够:
  • 整体沟通;
  • 当需要发布时进行确定和沟通;
  • 决定哪样功能对每次发布是充分必要的;
  • 专注于来自发布的商业价值;
另一方面交付团队将:
  • 全盘检视;
  • 了解实现愿景的步骤;
  • 学习业务优先级;
  • 提供技术输入的路线图;
  • 提供对项目特征的预估;
产品路线图——如何做
        创建的产品路线图,主要是由产品负责人(或产品负责团队)驱动。这个阶段的项目对技术限制的影响有限。在一次会议或一系列的会议上,产品负责人将绘制产品路线图。可以毫不夸张地说,通过发布的图形显示,或以更正式的书面文件列出日期、内容和可预见发布的目标。
产品代办事项列表
        预测下一个计划阶段(发布计划),需要建立预期的特征列表——产品待办事项列表。在最简单的表格中,这样一个待办事项列表是一个介绍产品要求的电子表格,简洁的描述可以使得交付团队提供实现每个特征的预期。最重要的是,这个列表要有优先级。敏捷项目的成功取决于早期交付最高优先级的特征。因为一个项目的成功是从商业的角度来衡量的,功能列表的优先排序是负责商业的人决定的,即产品负责人。产品负责人与交付团队的交互是必需的。没有对特性/功能的讨论,交付团队就很难对可接受的不确定性进行估算。一个产品待办事项列表的特征应包括:
  • 所有团队只有一个产品待办事项列表(看到整体);
  • 大至非常大的功能(由20人工作20天来交付一个功能);
  • 功能优先级基于业务优先级(通过市场调研发现);
  • 技术功能(有时被称作非功能特性,以工作期望的方式来做产品,例如:为了保证一定的系统性能来实现一个特定的数据库管理系统)被那些对产品在市场上的成功有直接影响的特征所限制。
 
发布计划——第三层次
        在小的项目中(单个团队在几个迭代后交付产品增量),单单一个产品待办事项列表就能够提供足够的项目概况。规模、可持续时间、可交付成果很容易识别, 没有必要同步交付或集体交付或团队交付。当把敏捷的概念应用于项目中时,团队和项目之间将会有一种依赖的关系时这将要改变。一些团队可以根据不同的敏捷原则运作,或在一个瀑布式流程中运作。在计划发布的第一刻就开始分组活动并将他们分配到各个小组当中。
发布,顾名思义就是,一组产品增量发布给(内部)客户。
发布的一些特征有:
  • 发布由日期、主题和计划的功能群定义。发布日期可以链接到事件,如会议或法律体系的变化;
  • 范围,不像日期或是质量,它具有可变性。它凸显了使用优先级产品待办事项列表作为一个计划事件的基础的必要性;当一个发布日期不能改变,增加预算是不可能的情况下,通常对发布本身是没有积极影响的,范围就是唯一可改变或打破发布日期的变量;
  • 所有的团队必须保持相同节奏的迭代,当所有团队以相同的节奏工作,相互依赖的探索和管理活动就会自动在规划中出现;
  • 有固定的发布日期贯穿于项目中的所有团队:2到4个月是典型的时间间隔;
发布计划——如何做
        有了产品愿景和产品路线图,并且产品负责人以及团队能够定期更新审查,每个人都对下一个版本的重点、主题以及发布的日期了如指掌。此外,产品的功能均体现在产品待办事项列表里,并已经过估算排出优先级。通过这些练习,产品负责人和交付团队对必须交付什么、何时以及为什么达成一致的理解。
        一个典型的发布计划会议通常需要一整天的时间,有时候需要2天的时间,如果项目非常大的话(100多人的团队)。所有的团队成员参加这个会议:包括产品负责人、交付团队和干系人。这个会议是高度协作和互动的;使用的工具通常是便签纸、活页挂图以及白板。一个日常工作事项应该是:
  • 介绍、目标、日程更新
  • 产品负责人解释产品愿景和产品隐喻
  • 版本发布和迭代的时间盒
  • 之前版本的影响和迭代
  • 交付团队生产力的计算
  • 可交付功能协议(即什么时候能“完成”一个功能)
  • 在个人团队分组座谈会议上将功能发布。这可能是一个文字性的“移动”,当把功能写在便签纸上,靠单独的翻页来代表功能发布。团队里的所有成员都加入这项练习
  • 在发布的过程中,由个人团队将功能由发布移至迭代
  • 通过检查个人规划的结果来决定相互依赖关系,将功能移至需要的迭代或版本来解决此种依赖
  • 最终计算出每次迭代的工作量以及与可用能力的比较
  • 审查发现的风险和问题
  • 所有参与者发布计划的承诺
  • 回顾会议
 
迭代计划——第四层次
        在发布计划期间确定交付功能,考虑功能之间以及团队之间的依赖关系。由于缺乏细节(直到可能的交付功能确定下来才会对设计活动投资),估算就会较为粗略,而且有一个可接受范围内的不确定性。版本发布内的迭代,会召开计划会议。在会议举行之前或是会议期间,具体细节会被通过任务分解加入功能。细节的添加可以提高估算的准确性。各个团队的实际工作容量比发布计划会议更有把握。这些增加的精确性的结合使得团队能够在迭代期间承诺实际交付的一些功能更具高度的确定性,实际交付。
迭代计划——如何做
        迭代计划会议的结构类似于发布计划会议。尽管团队的独立工作产出他们的迭代计划,但是团队之间的同步将会提供一个有效的机制来检测和解决依赖关系。计划会议的日程,与发布计划会议的有很大相似之处,与愿景规划的主要区别是:在所有活动中只发现一个迭代。在团队—团队的基础上进行的核心活动:
  • 各团队确定自己的实际能力,或迭代内能完成的工作量。
  • 各团队分解许多似乎可以在下个迭代中完成的任务——这个可以在准备工作中完成。
  • 估算每一项任务,一个典型的任务大概是半天到两天的时间。
  • 当分解和估算功能的时候必须考虑完成的定义:直到一个功能被充分地测试并被产品负责人接受,这项功能才算完成。
在发布计划会议上不会看到像在联合会议上各团队的结果被检查来决定依赖关系(或这种依赖关系消失)。  
日计划——第五层次
        许多敏捷团队习惯召开每日例会——即Scrum站会。在一个15分钟的会议上,团队内每位成员更新他们的状态(“我昨天做了什么”),承诺今天的工作(“我今天将要做什么”)以及报告困难(“我遇到了什么困难”)。这个每日例会通常不会被看作计划会议,但它肯定是计划会议。人们的目光提前一天向前看,从早期迭代中学习,并且互相告诉对方他们打算做什么。被提出的问题可能被解决,在迭代中成功交付期望功能,可以在会后决定。
站会——如何做
        像其他计划活动一样,团队之间需要同步每日计划。这在协调的站会上发生(Scrum方法论中的Scrum of Scrums会议)。每个团队的代表以相同的模板彼此互相报告团队的状态、计划和遇到的阻碍。这三个问题的回答跟在站会上的回答一样(“团队昨天完成了什么”,“团队今天将要做什么”,“什么阻碍了团队的进展”)。什么是可见的?
  • 所有团队进展如何?
  • 贯穿团队的阻碍是什么?
  • 谁正在采取行动移除障碍?
        一个协调站会的原则可以重复处理大量的团队:“团队的团队”的代表报告“团队的团队”的工作进展。这些会议通常会协调没有共同背景的团队的努力。例如,所有的IT交付团队有一个协调(每日)站会,培训团队、财务团队、制作团队等等都是如此。在每周(或发布周期后期)的每日安排上,团队的代表开会报告进展、计划和障碍。  
结论        本节讨论了交付团队的工作,通过在正确的时间用正确的层次细节来交付活动计划。通过分期活动计划,在长期和约定的以及前期的设计、计划投资之间找到一个平衡点。通过交付团队对发布和迭代的所有权计划,团队和个人负担过重的风险将会大大降低。
近期认证班:
五星级酒店授课
最顶级的世界大师
提前一个月报名享更多折扣优惠
免认证费和美国Scrum联盟两年会员费

- 2014年1月6 ~ 7日CSM美国权威认证(上海班)
Hubert Smits易埙, Jim Wang(中文助教)
课程详情

- 2014年1月10 ~ 11日CSM美国权威认证(北京班)
Hubert Smits易埙, Jim Wang(中文助教)
课程详情


2014年认证课安排:
www.shinescrum.com/courses

顺利完成课程并且通过在线认证测试之后,您将获得:
- Scrum Alliance颁发的ScrumMaster认证证书,成为一名认证的Scrum Master
- Scrum Alliance的两年会员会费及会员资格
- ShineScrum终身荣誉会员资格,可免费参加ShineScrum主办的各种活动
- 一副价值50元的估算扑克
- 一份CSM课程纸质版及电子版中英文讲义
- Scrum实施模板及大量参考资料推荐
- 美国项目管理协会(PMI)学分 14 PDUs





关注ShineScrum微信平台
400-821-0871
84 Nelson Street | Winchester, MA 01890 US
This email was sent to daisy.guo@shinescrum.com. To ensure that you continue receiving our emails, please add us to your address book or safe list.

manage your preferences | opt out using TrueRemove®.

Got this as a forward? Sign up to receive our future emails.
powered by emma