日至28日参加了优普丰组织的在北京为期2天的Certified(不是Certificated) Scrum Master培训，收获多多。参加培训前邮件中介绍Vernon老师是个精通中文的美国人，一开始以为这场培训注定是一个老外讲上一堆英文，然后有个中国人在旁边翻译的讲座了，没想到这个vernon中文水平真是好，正常的语速的中国话他听得一点问题也没有，汉语说的也是相当清楚，只有少数的字有点口音。vernon老师浑身散发着巨大的热量（他自称的Passion），当热到一定程度后，vernon就把鞋拖掉，一双白袜子开始在会议室里走来走去。
敏捷宣言与Scrum
以前对敏捷开发有一些了解，最早接触的是极限编程XP，知道有17位爱好滑雪的软件人士琢磨出了著名的敏捷宣言，对一些传统的庞大的软件开发提出了挑战。
敏捷Agile就像一把大伞，Scrum、XP、FDD等等都是其中的一员，Scrum是一种框架，更注重于一些过程，XP更注重于实践。
为了明白敏捷的几个要点，Vernon老师专门设计了一个传递纸球的小游戏，准备一堆用报纸揉成的小球，参加培训的8人为一组，围成一圈站立，规则很简单，只能用手传球，球从一个人手到另一个人手之间必须有空中时间，球必须传递给不相邻的人，一个球经过所有成员后才算1分，1分钟之内传递小球的个数为总成绩。游戏进行了5-7轮，每轮中间有1分钟的讨论时间。
游戏虽简单，但却能深刻地体会以下要点：
1）每轮的讨论都能提高下一次的成绩，第一轮好像只传了6个，最后一轮传了100多个，最后的改进幅度之大让我们自己都无法想像
2）设计再周密的方案不如马上动手，只有实践起来才能提出有针对性的改进建议
3）短时间内的决策也是相当有作用的，1分钟虽短，但短时间也同样能激发出的大脑无穷的创造力。
4）减少每个人空闲等待的时间，并行作业让球不停地在多个人之间快速流动，大大减少了等待的时间
5）当成绩提高到一定水平后，如果不在方法或工具上出现革命性的变革，成绩就不会再有多大的提高
6）把30分钟的总时间分解为多次迭代，每个迭代中进行实践和总结，远远比进行29分钟的周密设计讨论和1分钟的实践要有效得多。
Scrum总结起来就是3355，实际上应该称为3455：3种角色，3种工件，4种仪式（活动）和5个价值观。2天的课程实际上就是围绕着334来介绍的，当然讲解的过程不断地涉及到5种价值观的讨论。
Scrum Team由三种角色构成。
关于三种角色与龙舟比赛的类比：PO相当于舵手，把握团队前进的方向；TEAM相当于划桨运动员；SM相当于鼓手，负责协调团队。
1）Product Owner
客户代表，决定产品的发展方向vision，对ROI负责（投资回报率return on investment），本身最好就是个customer，PO是一个人，负责给PBI(Product Backlog Increments）排序，负责维护Backlog，确认Sprint的结果（Accept Sprint Results），PO有权利决定是否产品可以发布，PO不一定写全部的用户故事，PO要不断与团队沟通，PO有决定权Authority。
2）SCRUM Master
这个名称相当有份量，参加2天的培训，还没有Scrum的实践经验，通过了认证考试，就可以称为Scrum Master了。
我们普遍认为这个SM最没有事情可做，但老师一再强调这个角色很忙，特别对于不成熟的团队以及在项目的前期，我们把以前项目经理负责的事情一一写下来，贴在这个白板上，发现这个SM好像就是事情不多，他在整个过程中就是一个教练、一个咨询师的角色，他实际上就是辅导你如何开始正确的Scrum各个过程、会议等等。
SM在整个团队中起到一种老师、教练、促进的作用，要保证团队不受干扰、保证团队高效地开展工作，移除一些障碍。他几乎没有什么权利，但要有影响力。
Vernon关于在一些会议上ScrumMaster为什么可选参加的注解：
While the ScrumMaster is optional at many meetings they are responsible for assuring the Scrum framework is being effectively applied, so as you note in the area discussing the ScrumMaster role they are likely to be quite involved in all meetings, especially initially as the team needs to be trained and coached to understand how to effectively conduct the meetings: to understand their structure and purpose.
3）DEV Team
软件还是要由一群程序员一行一行写出来，这就是Team的任务了，这里Team中每个人的技能要掌握得全面（有专长，但不能只擅长的事），要会自我组织管理、跨职能、人数控制在5-9人之间、最好全职（可能有少量例外）、No Title（没有严格的分工，没有需求、编码和测试的分工）。
Scrum中没有项目经理的角色，没有上下级的关系，vernon打了一个比喻，说Scrum有点共产主义，但共产主义中最常见的是上下级领导关系。感觉根据我们当前的现状，三个角色最难找的是Product Owner，这个角色代表着用户利益，但要经常与开发团队混在一起。
1）Product Backlog
Product Backlog = a dynamic list of features that might appear in our product.
Vernon老师的注解：
PBI=feature, A bunch of PBIs = product Backlog
It might also be worth noting that PBIs don't have to be software. The Scrum framework can be applied to areas outside of software, so PBIs could be other prod for example the introduction in a book, or a chapter in a book.
值得注意的是：PBIs并不一定专指软件。Scrum框架可以应用于软件之外的其它领域，因此PBIs也可以是其它产品特性，例如在出版业，可以是书的一个章节。
这个Product Backlog就是软件产品的功能列表，由许多PBI（Product Backlog Item）组织，一个PBI又由许多SBI（Sprint Backlog Item）组成，这个Backlog要贴在一面大墙上，上课时曾经问了vernon老师，这个东西全用工具放在开发团队的网站首页上行不行？vernon说可以，但只用电子的backlog会影响开发效率，所以他们公司还是用大墙和便利贴，一些内容会录入到电子backlog中。
25个小星星积木的游戏让人明白了优先级的重要作用，要在最短的时间内得到的最大的收益，就是要先完成那些黑星星。
2）Sprint Backlog
这个Backlog感觉可以称为任务了，通常PBI颗粒太大，无法执行，只有分解为SBI（小于2天的工作量）才能开始动手做。感觉这东西好像GTD里将Project分解为Action的过程，不过任何项目也都是这样来分解的。
3）Tracking/Increment
这个东西在以前就是指燃尽图，现在好像说也不是必须的了，实际上Backlog也完全可以体现出项目的进展情况。
Scrum就是由一堆的Sprint组成的，这个Sprint实际上就是迭代，每个Sprint最少为1天，最长为4周，由4个活动组成。
Vernon的注解：
In theory there is no minimum sprint duration, one day is just the shortest I've seen in a production environment. Sometimes in training we use 1/2 day sprints. A key concept, however, is that for a sprint to be a sprint, it must include the 4 meetings.
理论上没有最小的sprint长度限制，一天的sprint长度是我在产品开发中看到过的最小的长度，在培训时有时可以用1/2天作为sprint的长度。然后，一个sprint可以称为sprint的关键是它必须包含4个会议。
Sprint是固定长短的，有可能第一次迭代之后，周期有点调整，但后来采用一个稳定的天数，这就是Scrum的rythym节奏。
在Sprint期间，功能范围不再变化，即PBI从左侧拿到Sprint Backlog区后，不再接受新的SBI。
Vernon的注解：
SBIs are emergent, and defined by the team, so it is quite possible that new SBIs will be added during the sprint. This is just to say that the team has developed a deeper understanding of how they will complete the PBI. So, during a sprint the SBIs can change, but the PBIs that the team has committed to cannot change. "No change" during the sprint refers to PBIs.
SBIs具有涌现性，是由团队来定义的，因此在sprint之间会出现新的SBI。也就是说，团队对于如何完成PBI已经有了深刻的理解，因此在sprint期间SBI是可以变化的，但团队已经承诺的PBI不能变化。在sprint中的"No Change&是指PBI而言的。
1）Sprint Planning
这个过程有点需求分析的作用，实际上也是一种承诺Commitment。这个会议又由2个阶段组成，第一阶段称为Selection，第二阶段称为Planning。
第一阶段由PO、TEAM参加，SM可选。对于1周的sprint，这个阶段不超过1小时。
在这一步是根据PBI的优先级拿到Sprint backlog中，对于较大的粒度，还要分解。
第二阶段由TEAM参加，PO和SM可选，但PO要随叫随到。对于1周的sprint，这个阶段不超过1小时。
2）Daily Scrum
这就是著名的站立会议，要在每天相同的时间、相同的地点举行，少于15分钟。
Scrum(由于它不是一个缩写单词，所以一般不用大写所有字母)的术语也是来源于橄榄球中的碰头开球仪式，在rugby这种运动中，每个运动员都是自组织的、跨职能的，需要根据场上的动态地调整计划。
会上要回答3个问题：
What did I get done in the last work period?
What will I get done in the next period?
Any impediment（障碍）?
通过这三个问题，团队进行广播式的沟通，跟踪项目的进度，分享一些知识，更重要的是给团队做出一种承诺Commitment。
3）Sprint Review
这种回顾对于长度为1周的sprint，不超过1小时，不需要PPT，非正式的交流。整个过程也是TEAM和PO参加，SM可选。最好还要请一些stakeholder参加。
Vernon的注解：
PO and team are required, ScrumMaster is optional. Stakeholders are encouraged to attend this meeting. Since this meeting is a key means of the PO soliciting feedback from stakeholders, their participation in this meeting is essential. The PO might even be the host/driver in this meeting.
4）Sprint Retrospective
这个会议对于长度为1周的sprint，不超过45分钟。整个过程TEAM参加，SM和PO可选。
这个过程是为了将来的持续改进，不讲坏消息，提出1-3个改进建议，然后就是celebrate。
Vernon的注解：
The Sprint Review is the meeting where the working results of the team are shared with the stakeholders and the PO. The Sprint Retrospective is the meeting where the team considers how they can continuously improve.
The Sprint Retrospective is the meeting where the team considers how they can continuously improve. The team is required and the PO and ScrumMaster are optional (at the discretion of the team). Typically the team would encourage their participation unless the PO or ScrumMaster themselves are in some way an impediment to the team improving.
User Story并不是SCRUM中的内容，但可以用于SCRUM中。
PBI相当于User Story，而SBI相当于任务Task，SBI的颗粒度要小于0.5天。
Vernon的注解：
1/2 SBIs are a practice my company uses, but not a formal definition included anywhere related to either User Stories or Scrum. As you correctly note earlier in your blog, SBIs are typically 1 - 16 hours (less than 2 days) in duration. 1/2 day is just our practice.
PBI要写到什么程度？DEEP原则：
Detailed Appropritly 比较清晰的
Emergent 涌现性
Estimated 被估算的（以团队的方式来估算）
Prioritized / Order 被排序的
vernon老师由于散发着巨大的热量，所以需要不停地补充水份，每天带着一大瓶（搞不清楚2升还是3升）基本上都喝得差不多。一个游戏就是估算他喝剩下的水的体积，8个人的估算从400ml到1600ml不等，相差如此巨大，说明了人不擅长使用绝对的数量来评估事物，而使用百分比来估算时，范围就统一在55-65%之间。
优普丰的计划扑克可以用于团队对任务工作量进行评估。
阅读(...) 评论()上完课，我觉得敏捷scrum其实什么都没“讲” - 简书
上完课，我觉得敏捷scrum其实什么都没“讲”
这两天我参加了一个为期两天的敏捷培训课程，这个课程主要是通过“体验式学习”，即游戏、练习、团队活动或模拟的方式引导学员进行学习和思考。在第一天的课程中，敏捷教练Jacky申导首先引导同学们讨论了以往项目失败的原因，以及遇到过的挑战。成功的项目都是相似的，失败的项目却各有各的原因。总结下来，学员想学习敏捷，解决的问题无外乎以下几类：项目运行周期过长，无法及时交付；没有详细调研沟通客户需求，确定项目目标，而是快速的开展项目工作，导致后期返工，错误、疏忽，风险频发；缺乏人员，资源配备和供给欠佳；项目组成员职责分工不够清晰，使得其组织协调工作困难等等。由此，申导与大家分享了敏捷项目的思维与原则。同时，还通过一段视频——乔布斯的石头的预言，引导我们思考与发现，在自组织团队里，成员的职责以及如何分工协作。
第二天的课程一开始，我们就在导师介绍完规则后，自组织完成了一次通过抛橄榄球回顾知识点的小游戏。整个活动过程中，Jacky申导除了提示、鼓励成员参与以及强调规则以外，没有任何干预我们活动的行为，大家完全是在依靠自觉服从公约的前提下完成了这个小游戏。很有意思，同时也让我们亲身感受了自组织的效率和团队职责。
第二天的课程我们不仅学习了敏捷工件，比如Backlog需求列表、sprint计划会议、sprint评审等等，还与小组成员一起完成了一个浓缩版的手机APP的项目交付流程。整个课堂体验非常有趣，但是对于我这个零基础的“敏捷小白”也有很多困惑，毕竟敏捷是一个项目管理方式，需要的是全体成员的参与与认同。如果我带着很大的热情想要把引入我的工作中，我的领导不认同怎么办？我的同事不懂敏捷怎么办？道理我都懂，做起来好像阻力重重又怎么办？两天的敏捷课程培训无法解决我工作中的所有的问题，但是如敏捷所倡导的价值观：抱着开放的态度迎接每次的挑战，专注最终目标，尝试解决困难，尊重团队成员的想法，还有就是，与所有的敏捷爱好者一起：抱团学习，互相激励，持续提升。
欢迎所有爱学习爱思考的敏捷爱好者们加入我们优普丰敏捷学院。
全球首位获得Scrum Alliance认证培训师CST及敏捷教练CTC双料导师级认证者
培训师、顾问、教练
http://www.JackyShen.com
http://www.UPerform.CN
为了回馈敏捷社区对上海优普丰敏捷学院成立10年来的支持，我们决定免费放出敏捷开发Scrum实践集核心精髓免费入门学习教程培训讲义，包含美国Scrum联盟的Certified Scrum Master培训（即CSM认证）公开课培训的核心内容，方便大家预习和复习Scrum实践，...
敏捷读书之重回根本：《Scrum指南》100问 作者/分享人：glenwang 本文是对Scrum指南的解析，以展示这个简单而有力的软件开发管理方法。 本文推荐的读者有三大群体： - Scrum Master。Scrum Master是Scrum的首要用户，他/她需要掌握和...
1、在项目的Sprint回顾会后，团队成员指出那是抱怨会，不是非常有效。Scrum主管应该怎么做？A 建议团队尊重敏捷宣言原则，解释其属于回顾会的组成部分B 建议团队成员将他们的观察列入产品待办事项，进而可以添加进用户故事中C 建议团队遵守Sprint回顾会精神，做出正面和...
（由 Ken Schwaber 和 Jeff Sutherland 开发并维护） Scrum 指南的目的Scrum 是用于开发和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包 括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Sc...
1、在第五次sprint审查期间，团队获得产品负责人对所有功能的签署同意。但是，产品负责人注意到在第二次sprint期间开发和验收两个功能不能正常工作。随着新功能的开发，在之前开发的功能中，故障出现越来越频繁。若要控制这个问题，事先应该怎么做？A Scrum 主管谴责团队B...
开头段：先讲重要性，然后转讲不好的地方。 Nowadays with the rapid development of advanced ……., more and more….. are commonly and widely used in everyday life....
饮二三白酒
我的他呀，你到底有多优秀，才能让我等那么久，那么久还不出现。 我很简单，也很傻，一直信奉的人生信条是否极泰来，经历了一件很糟糕的事，一定会有惊喜等着你，一件事压抑了很久，那转机也马上就要到了。 靠着这四个字，我度过了我的青春期，我的少年时代，一直到现在。 这四个字真的很神奇...
01 视觉感受 写了二十多篇文章以后，返回去看看，觉得自己写的过于随意。而且自己的简书的排版真是low到姥姥二姨家了，以为文章靠里子撑着就行，传递真实的情感，岂不知拼颜值的时代，好的视觉体验即真理。虽然更多的是写给自己的积累和梳理，但以后还是要尽可量的创造美的视觉感受。 0...
我们总是会在茫茫人海中遇见一些人，也会遗失掉一些人，我与你在茫茫人海中相遇，未曾想过遗失你，却又再也没再看见你的背影。
高中的生活对于我来说是艰苦无味的，最好的朋友相隔不远却并不能时刻相见，无论是生活中的距离还是精神上的距离对我来说都是那么遥远。我呢，性格倒也算作孤僻吧...课程：Scrum敏捷开发实战_项目管理培训_项目管理者联盟
适合敏捷开发项目
敏捷项目管理最佳实践
重视项目商业分析
商业价值与需求分析能力
产品管理国际认证
全球产品管理最佳实践
单项目管理经典指南
年轻项目经理首选
大型复杂项目全球标准
定位高级项目管理层
链接战略与项目
实现组织资源投资回报
信息系统项目管理师
系统集成项目管理工程师
信息类别：新闻-沙龙活动
培训时间：
培训地点：
讲师姓名：
显示全部介绍 &
[1627]?[1422]?[1231]?[761]?[1649]?[1122]?[1069]?[1022]?[1019]?[883]?[1219]?[1076]?[933]?[1003]?[724]?[702]?[685]?[624]?[617]?[743]?
PMI, PMP, PgMP, PfMP, PMI-ACP, PMI-PBA, OPM3, PMBOK and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc.
项目管理培训课程介绍
[主办单位]
单&&&&位：
电&&& 话：
400 818 8020
传&&& 真：
邮&&& 件：
地&&& 址：
北京市朝阳区建国路77号华贸中心写字楼3座24层
[课程介绍]
Scrum敏捷开发实战
开课时间：& 信息类别：新闻-沙龙活动& 浏览量：952
本阶段培训通过简短介绍，让学员大致了解敏捷开发的历史及其尝试解决的问题。
敏捷开发尝试解决的问题
Scrum及其历史
产品负责人 Product Owner
产品负责人团队
产品负责人的职责
现场演练：分组并推选Product
迭代计划会
本阶段通过讲解计划会的完整过程及背后的思想，并通过实际练习，对之前需求分析阶段获得的用户故事进行估算。
详细内容包括：
猪与鸡的故事――敏捷计划会背后的分权思想
如何通过放权提升开发人员个体的积极性。
产品经理如何讲解故事
如何从大到小、从整体到局部、从背景到功能地分层讲解用户故事；如何在客户环境中理解需求。
开发人员扑克估算
如何让团队成员说出真实的估算值；如何让高手在估算时就能帮助新手；如何通过估算来澄清需求。
讲师在从事开发时，曾将已经完成的、多达4000行代码压缩为55行代码。在实施敏捷估算后，在计划会即可避免这种浪费，而无需等待编码实际结束后才发现。
日常活动第一步：每日立会与敏捷生态系统
无数敏捷团队因为每日立会简单易行而将其作为第一个推广的敏捷活动；无数敏捷团队也在无奈中亲自见证了这个简单易行的会议最后如何变得死气沉沉，不得不依靠“迟到罚款箱”来维持。
培训中将介绍每日立会――乃至所有敏捷开发活动――背后的运行原理：敏捷生态系统。看似无关的敏捷实践与团队模型之间其实存在着隐形的联系。
日常活动第二步：看板
看板是一个通过将所有迭代内工作分为“待开发”“开发中”“开发完毕”三个状态来进行任务可视化管理的工具。
不过，看似简单的看板和燃尽图也有很多背后的故事。
本阶段培训后，学员会发现除了简单地“透明化”之外，看板还能用来确保产品按时发布、防止任务堆积、风险前移等。
启发式演练：如何按需改进看板？
日常活动第三步：燃尽图
燃尽图不仅是项目进度的仪表盘，还是分析项目问题的利器。
在这个环节，学员们需要动用十八般武器――从第一天到最后一天培训的所有内容――才能分析并驯服失控的燃尽图。
高级敏捷实践
介绍实际企业在推广敏捷时所作的改进。包括：
NEC的预估会与预评审会制度
金山的渐进式评审与跟进人制度
DSDM方法中的MoSCoW方法
当前流行的看板开发
面向MVP与持续交付的的可变周期开发
团队建设第一步：自组织团队原理与同行压力
团队认为10个月才能完成的项目，被领导拦腰砍成5个月。领导刚刚离开会议室，队员们哈哈大笑：原来他们早就知道进度会被腰斩，所以提前多估了一倍！
为了提高生产率，公司加强了绩效管理：凡是延期交付的项目全部会被扣奖金！于是，所有团队都为自己的项目预留了100%的额外时间……结果是：一年后，公司除了生产率下降一半之外，什么都没有得到。
领导压力似乎总是失效，那么到底是什么在驱动敏捷团队呢？
本内容会介绍神秘的“同行压力”是如何在计划会、每日立会上驱动团队努力前行的。
团队建设第二步：项目经理转型
敏捷开发来了，项目经理该怎么办？
很多公司尝试废弃项目经理，启用Scrum，这反而令原来的项目经理成为推广敏捷的阻力。
培训中会介绍项目经理应该如何升级为PM2.0，从而成为符合敏捷开发原则的项目领导者。
团队建设第三步：1-3-9团队――大型团队的敏捷方案
当团队超过10人时，众多敏捷开发中未曾想到的问题就浮出了水面。
越来越难以实现众多人员之间的“跨职能”，甚至在纯软环境中分工也越来越难以打破；高手总是认为自己很忙，因而提供帮助的应该是别人；计划会上越来越多的人开始弃权，因为只有个别人感觉自己是潜在的任务执行者……
1-3-9团队创造了一种大团队分组的方法，即通过产品需求树将团队分解为多个Feature Team，独立运行敏捷开发，从而降低了团队的规模。
团队建设第四步：松结对编程
项目中的顶尖高手应该做什么？各自为战？安排攻坚？
在敏捷开发“团队协作”的语境中如何使用高手？如果他们为新手提供帮助，如何保证其自身的生产力不会降低？
“松结对编程”提供了一种有别于两个人同时编程的“结对编程”。具体实践包括：高手与新手一起估算任务，在发现由能力造成的工作量分歧后，约定某个时间点高手协助新手，以极短的时间解决新手遇到的困难；每天执行代码审查，确保每一行代码的质量。
陈老师　易迪思金牌讲师
17年软件研发、管理及咨询经验，擅长在实际环境中应用敏捷开发实践。
曾在清华同方、普天集团、亚信科技等企业担任EPG骨干、组长。
曾任斯福泰克、DNV ITGS等机构CMMI敏捷咨询师。
曾在中国系统与软件改进年会、中国软件技术大会、敏捷中国大会、MPD等国际国内会议从事敏捷演讲、翻译或主持工作。
曾任泰克赛尔软件公司中国部门的咨询总监、ALM事业部总监、副总经理。
5月14日上午9时，中关村南大街5号海淀科技大厦5层。
100元/人，讲座前一周交。
[发表评论]
[相关评论]
项目管理者联盟 版权所有 京ICP证070584号 | 京公网安备号
如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者