文章频道为您提供Leangoo实践,以及Scrum,敏捷,精益创业,产品创新等领域专业文章。

scrum中文网scrum行业报告

Scrum行业报告 2017-2018摘要

《2018 State of Scrum》报告由美国Scrum Alliance发布。从实践者、教练、讲师等角度来探寻规模化敏捷转型中的问题,有助于理解、比较和思考敏捷方法在不同行业的效果。

本文摘取了部分精华数据,翻译成中文,供华语敏捷社区参考。鼓励大家在培训和教练辅导中引用这些关键点。

WechatIMG3

关于Scrum Alliance

Scrum Alliance是一个为Scrum和敏捷实践者提供教育、资源和支持的组织。深入一步,你会发现Scrum联盟是观念和变革运动的一部分。Scrum联盟提供主张、社区参与、研究、人际网络和关注组织变革,这些变革正在改变着全球的工作方式。Scrum是一个非盈利组织,由全球超过50万认证者组成,驱使我们的不是商业,也不是什么财务盈亏;我们的动力正是来自于全球社区的成员,以及寻求实现真正工作与生活平衡的每个人。

敏捷与Scrum

Scrum是一个实现了敏捷思维的框架,帮助团队快速前进和学习,是一种把事情搞定的敏捷方法,Scrum常常与其他敏捷框架结合起来使用。
scrum中文网scrum行业报告4

调研参与情况

2017年秋季调研,共91个国家参与(2015年96个,2016年76个)。 其中比例最多的国家是美国48%,印度7%(亚洲共10%),德国6%,英国5%,加拿大和澳大利亚各4%。
scrum中文网scrum行业报告5
这2000多个受访者代表了27个行业。受访者主要来自的领域分布如下:•  IT – 39%•  软件开发 – 27%•  产品开发 – 11%•  PMO – 6%•  咨询 – 6%•  C-Level高管 – 2%•  运营 – 2%•  销售与市场 – 2%•  金融 – 1%

•  教育 – 1%

非IT部分使用Scrum的情况分布如下:

•  运营或生产 – 42%

•  研究和研发 – 31%

•  销售和市场 – 25%

•  内容创作和管理 – 24%

•  咨询 – 22%

•  人力资源 – 19%

•  金融或会计 – 18%

Scrum的应用情况

94%的受访者在敏捷实践中采用Scrum。 其中,78%结合其他方法一起使用,16%单纯使用Scrum。

scrum中文网scrum行业报告6

平均团队大小是7.4个人。其中8%的是1-4个人,78%的是5-9个人,13%的是10人以上。

scrum中文网scrum行业报告7

91%的组织提供了相关培训与教练辅导。

scrum中文网scrum行业报告8

平均Sprint时长是2.4周。

scrum中文网scrum行业报告9

每个Scrum项目平均包含5个Sprint。

scrum中文网scrum行业报告10

Scrum项目平均周期是11.6周。

scrum中文网scrum行业报告11

2017年最热门的认证是ScrumMaster,其次是Product Owner, Scrum Coach, Scrum Team等。

scrum中文网scrum行业报告12

Scrum项目成功率是63%。

scrum中文网scrum行业报告13

81%受访者在每个Sprint后会进行回顾会议。

scrum中文网scrum行业报告14

86%受访者在每个Sprint前会进行计划会议。

scrum中文网scrum行业报告15

87%受访者会召开每日Scrum站会。

 

scrum中文网scrum行业报告16

为什么选择Scrum?

关于Scrum项目的优先级,71%的高管认为交付客户价值是首要,灵活性与响应力紧随其后,获得56%的高管投票。改善组织设计和文化排名垫底,仅有25%的高管投了票,然而那是优秀的Scrum实现所非常需要的。

85%的受访者说Scrum持续地改善工作与生活质量

scrum中文网scrum行业报告17

97%受访者表示愿意继续使用Scrum。

78%受访者愿意推荐Scrum给同事、朋友和其他行业人士。

组织内55%的项目是Scrum项目。

scrum中文网scrum行业报告18

认证和培训

81%受访者认为认证改善了实践,91%的组织提供了某种形式的培训。

scrum中文网scrum行业报告19

ScrumMaster仍然是最热门的认证,获得了84%的青睐。有更多人在呼吁在线认证的方式。
98%受访者选择了各种类型的Scrum认证:
1.  Certified ScrumMaster (CSM: Scrum Alliance) 84%
2.  Certified Scrum Product Owner (CSPO: Scrum Alliance) 33%
3.  Certified Scrum Professional (CSP: Scrum Alliance) 17%
4.  SAFe Agilist (SA) 8%
5.  SAFe Program Consultant (SPC4) 5%
6.  Professional Scrum Master (PSM: Scrum.org) 4%
7.  Leading SAFe 4.0 4%
8.  Certified Scrum Developer (CSD: Scrum Alliance) 3%9.  LeSS (Large Scale Scrum) 3%

10. Scrum Master Certified (SMC) 2%

11. Certified Agile Leadership (CAL: Scrum Alliance) 2%

12. SAFe 4.0 Advanced Scrum Master 2%

13. SAFe 4.0 for Teams 2%

14. Professional Scrum Product Owner(PSPO: Scrum.org) 2%

15. SAFe 4.0 Product Manager/Product Owner 2%

6%受访者选择了各种类型的敏捷认证:

1.  ICAgile Certified Agile Coach 4%

2.  ICAgile Certified Professional 2%

3.  PMI Agile Certified Practitioner (PMI-ACP) 1%

还有9%受访者选择了其他认证,而2%受访者不要任何认证。

(Scrum Alliance将推出新的进阶认证,包括A-CSM, A-CSPO等,作为新CSP发展路径的一部分。同时,也发布了另外两个新的高级认证:CAL和CTC)

成功的采用Scrum

高管层的支持是成功采用Scrum的关键,而组织设计和文化则是最大的挑战。

scrum中文网scrum行业报告20

scrum中文网scrum行业报告21

 

规模化敏捷Scrum

Scrum最初创立时的最佳团队大小是5-10人。然而随着63%的Scrum项目成功,以及超过15%的非IT项目采用Scrum,人们愈加渴望能在更大规模上来运用Scrum,更多的团队和更大的项目。

Scrum的最高业务优先级:

* 满足客户需要 29%

* 改善上市时间,缩短周期时间 24%

* 符合预算、时间与范围约束 14%

* 完成驱动创新和市场份额的项目 13%

* 增加新功能

* 改善质量 6%

scrum中文网scrum行业报告22

超过一半的投票认为,规模化Scrum的阻力在于:自上而下、命令与控制的管理方式,对变革的抵触,缺乏理解和支持等

scrum中文网scrum行业报告23

启动敏捷

敏捷转型的驱动力:

1  高管的主动支持 56%

2  与组织战略和财务目标对齐 47%

3  清晰的业务目标 42%

4  清晰定义的度量 41%

5 确保平滑和无冲突的转型 31%

6  有经验的讲师和教练的参与 30%

scrum中文网scrum行业报告25

敏捷转型的领导者:
1  高管 61%
2  ScrumMaster 48%
3  IT主管 27%
4  产品负责人 22%
5  软件工程师 21%
6  项目经理 21%
7  敏捷教练 4%

scrum中文网scrum行业报告24

敏捷转型的成果:
1  改善了交付满意度 54%
2  更短的上市时间 51%
3  更好的质量 49%
4  改善了士气 45%
5  改善了IT的投入产出比 31%
6  现在度量还太早 25%

scrum中文网Scrum行业报告31

规模化框架的采用:
1  没有用具体的框架 34%
2  Scrum of Scrum 33%
3  SAFe 33%
4  LeSS 10%
5  Scrum@Scale 8%
6  DAD 5%
7  Nexus 2%

scrum中文网Scrum行业报告30

敏捷转型

53%受访者参与在更广泛的敏捷转型中。56%受访者具备敏捷转型计划。

scrum中文网scrum行业报告26

敏捷转型的关键催化因素是过程相关问题,然后是人员问题。

scrum中文网scrum行业报告27

78%(两年前只有55%)的受访者会将Scrum与其他方法混合使用,其他方法包括Kanban、瀑布、精益等。

scrum中文网scrum行业报告28

scrum中文网scrum行业报告29

 

官方完整报告链接:   https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/State%20of%20Scrum/2017-SoSR-Final-Version-(Pages).pdf

(摘编与翻译:Jacky Shen, CST & CTC)

 

 

屏幕快照 2018-01-10 下午2.42.02

为什么Scrum Master不叫Scrum Manager?

leangoo为什么Scrum Master不叫Scrum Manager?

昨天, 去看最新上映的星战8
其中有一段剧情是这样的, 卢克·天行者担心自己没有能力教导下一代绝地武士, 尤达大师现身对他说了一段话, 大意是:

[“yes you can teach them, you can pass knowledge, pass experience, pass…, pass failure, yes, failure, is the most important thing… we are something they grow to beyond, that's the true meaning of masters.

你有能力教导她, 你可以传递知识, 传递经验, 传递…, 传递你曾经失败的经历, 是的, 失败的经历是最重要的, 在我们的帮助下, 他们将超越我们, 这就是一位Master真正的意义. "

*现场听记,可能与原文有出入 ]

leangoo-为什么Scrum Master不叫Scrum Manager?

这段话可算是“服务型”领导人绝佳的写照了, 也是Scrum Master的精髓所在.

Read more

leangoo敏捷实践编年史

敏捷实践编年史

敏捷实践编年史(敏捷联盟版)记录了上世纪六十年代至今敏捷相关实践的发展史,其英文原版材料来自于国际敏捷联盟网站(AgileAlliance.org) .

原文链接: https://www.agilealliance.org/agile101/practices-timeline

本文由国内知名敏捷教练李洁(Jerry Li)和廖靖斌(Eric Liao)翻译成中文版本。

1968年:“康威定律(Conway’s Law)”

“康威定律”被提出并概括为:“任何组织,在设计系统(不仅限于信息系统)时,产生的设计在结构上必然会复制自身组织的沟通结构。”长期以来,“康威定律”都只是被当成民间传说,而非得到充分论证的科研成果,尽管最近有些研究为其提供了一些学术支持。(直到90年代中期,软件开发的人际交互方面仍然在很大程度上为软件工程学术研究忽视。)
Read more

timg

Scrum Master的职业发展路线

我最近写了篇博客回答了这个问题:“一个Scrum团队是否可以变得足够的优秀以至于他们不再需要Scrum Master了?”,在这篇文章中我发现了一个与此密切相关的话题:假设Scrum Master不会消失,那么Scrum Master的职业发展路线是什么?

根据我的经验,Scrum Master的职业发展路线通常会有如下的四个方向:

服务多个团队或更具挑战性的团队

Scrum Master典型的职业路线是从服务一个团队开始的。经过一段时间之后,团队相关的问题得到解决,团队磨合的越来越好,团队自身开始承担越来越多的责任,Scrum Master花在团队上的时间逐渐减少。

这个时候,一个好的Scrum Master将寻求更多的挑战。通常,合理的下一个步骤是服务多个团队,或者服务于需要更多支持的团队或产品。

在培养新Scrum Master的时候,我们通常倾向于把他放在一个更有可能成功的环境下,服务于一些比较容易合作的团队,既没有刺头,又没有不切实际的交付要求。但是,从一个优秀的Scrum Master发展成一个卓越的Scrum Master往往需要在更复杂、更具挑战性的环境下历练。

这也印证了成功是对额外挑战的奖励的哲理。
Read more

Sprint-Review

给产品负责人的Sprint评审会建议

Sprint评审会议可能是产品人员最重要的Scrum活动,它可以帮助您收集反馈意见,做出正确的产品决策,从而增加创造成功产品的机会。但是我发现,产品负责人并不总是清楚谁应该参加会议,应该如何开展这个会议,以及如何收集相关反馈。本文将回答这些问题,并分享我的一些建议,以帮助您在Sprint评审会上得到更多收获。

邀请正确的人参与

从正确的人那里收集反馈信息对于做出正确的产品决策至关重要:如果您邀请了不合适的人参与,或者关键人物未到场,那么您不太可能收到您所需要的反馈。因此,你应该确保你邀请合适的人参与。
一般来说,邀请那些你需要获得反馈来验证最新产品增量,以及可以帮助您推进产品发展的人参与。这些人通常是您的关键干系人 - 对您的产品有兴趣的人员,以及您需要去发掘的产品用户和需要你提供产品的人。这些人可能包括营销,销售,服务和支持人员以及其他业务部门的人员,具体取决于您的产品和组织。
为了鼓励干系人参与,以及管理干系人的期望,告诉他们为什么需要他们参加会议,以及他们可能会看到什么,这是很有帮助的。 Read more

Sprint Backlog  8 个小贴士

创建一个好的Sprint Backlog 的8个小贴士

Sprint Backlog是Scrum 团队在当前Sprint必须完成的任务清单,根据Sprint backlog ,Scrum团队在Sprint的最后交付一个带有增量功能的软件。

创建Sprint Backlog发生在sprint计划会议的第二部分,每一个团队成员都需要参加。真正的重视这个过程是更好地了解Sprint中团队应做哪些工作,以及更好的做Sprint的计划的基础。尽管这样,许多团队仍然为这个事情挣扎。
我希望如下这些建议对他们有点帮助:

1.让每个队员都要参与这个过程。

2.讨论每一个用户故事应该如何实现。确定开发任务之前。

3.对于完成的标准要有明确的定义。

4.标识出所以需要完成的任务。

5.不要事先分配任务。

6.重新审视sprint的承诺。

7.不要使用过多的时间。

8. 在sprint过程中演化Sprint Backlog。

此文由Scrum中文网整理,转载请注明出处

leangoo_sprint

设置Sprint0是个好主意吗?

我在之前的帖子里曾写过对sprint进行编号除了用数字之外还有其他选择吗?今天这篇帖子我来说说一些团队给sprint编号时使用的的一个非常特殊的数字—0。

Sprint0这个概念在有些团队中变得越来越常见,所以我们很有必要来思考一下它到底是不是个好的提议。

首先,假设我们赞同sprint0存在的必要性。Sprint0通常被声明为必须的,因为在scrum项目开始前有许多事情要完成。例如,需要组建一个团队。这可能涉及到要招聘或调拨一些人到这个项目来。有时,也需要采购一些硬件或至少要安装一些软件。许多项目组也在努力说服别人,说他们需要在sprint0中编写初始backlog(即使仅仅是高级别的)。

设置spint0的一个最大的问题是,它产生了例外—有些sprint或sprint类型具有与众不同的特性。比如,在sprint结束时能得到潜在的可交付的成果这一scrum宗旨就被摒弃了。毕竟,如果sprint的目标是组建团队,那么他们怎么能得到潜在的可交付的东西呢?
Read more

用户故事

写好用户故事的10个技巧

用户故事可能是捕获产品功能的最流行的敏捷技术:使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。
1. 用户第一
顾名思义,用户故事描述了客户或用户如何使用产品,它从用户的角度进行表达。另外,用户故事特别有助于捕捉特定的功能,例如搜索产品或进行预订。下图说明了用户,故事和产品功能(由圆圈表示)之间的关系。

1

如果你不知道谁是用户和客户,以及为什么他们会想要使用这个产品,那么你不应该写任何用户故事。首先进行必要的用户研究,例如通过观察和访问用户。否则,就有基于自己的想法和信念写出假想的故事的风险,而不是基于数据和经过验证的证据。
Read more

海报22副本

2016 Scrum联盟Scrum行业调查报告

2016年的Scrum联盟会员调查显示,曾经只用在软件开发领域的Scrum和敏捷实践,在IT行业之外也取得重大进展,并在非技术行业中也获得认可。这项调查结果反映了目前的一种趋势——各类公司都在使用Scrum和其他敏捷框架来进行创新和保持竞争力。

全球劳动力市场上的敏捷趋势

89%的受访者表示,在他们公司使用Scrum(或至少包含Scrun)作为实施敏捷的方法。(92%的受访者使用各种形式上的Scrum)。kanban是第二常见的,接下来就是Hybrid,然后是传统的瀑布模式。前三位的排名2015年是21%,在2016年已降至17%。
Read more

图1

反对迭代0:停止拖延,开始迭代

很多项目都不会一开始就完全就绪——例如,需要分配人员和准备工作。为了处理这些项目开始前的任务,很多团队使用了“迭代0”的做法。虽然理解其由来,但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由:

首先,尽管很难相信,但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有:需要组建团队,包括调配人员到项目上或雇佣新人;需要获取或者设置硬件设备;需要写一个初始的产品待办列表(即使只是高度概要的)。然而现实情况是:诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成(一个完全是正常的和传统模式的迭代一),同时至少还可以交付了某些潜在可发布产品增量。
Read more