Scrum敏捷实践集

u=389611283361,1817667073&fm=26&gp=0

不能将软件组织的绩效目标分解到职能

在上一篇文章《软件研发绩效管理的第一性原理》中,我阐述了软件绩效管理的三大目标和原则,大家可以用来评估和改进自己的绩效管理体系。

本文中,我将讨论软件组织中绩效管理的责任主体。

一. 组织通过价值流来实现绩效

要进行组织的绩效管理,首先要理解组织是如何实现绩效产出的,这就必须了解价值流的概念。

什么是价值流? Read more

Scrum_tp

软件研发绩效管理的第一性原理

我的上一篇文章《软件研发管理中需要破除的三大绩效管理理念》发表后,得到了不少小伙伴的赞同,大家希望能进一步给出一些问题解决方案。比如:有一位ID为“飘游乱码”的小伙伴留言:“问题有了,有建议的解决方案没?谢谢!”

由于绩效管理是个比较大的话题,我会持续选择一些主题来进行讨论。在本文中,我想先讨论一下自己对软件研发绩效管理的第一性原理理解。

一 在很多组织中,软件绩效管理“三观不正”

我自己亲自在很多家公司工作过,也接触过很多公司,亲眼目睹了许多软件研发绩效管理的“三观不正”现象。特别是以下两种现象:

#1 绩效管理,完全以考核人为目的

在某些公司,绩效管理完全围绕着绩效考核来进行。每年/半年/季度,这些公司的管理者都要对员工设置绩效目标,并在周期结束时进行绩效考核。

然而,在软件研发中,个人绩效目标很难预先设置和合理设置;所以,在绩效考核时,管理者往往也并不是真得完全基于绩效目标来进行考核,而是要对自己认为表现好的员工,挖空心思去加分,而对于自己不满意的员工,则挖空心思去减分。

于是,绩效管理,就变得完全以考核员工为目的——依赖绩效考核这个手段,把人区分出三六九等,给与分别对待——对于管理者认为表现好的人,升职、加薪和多发奖金,而对于管理者认为表现不好的人,则是将其淘汰的机会。

这样做,保证了管理者的权威,同时也让组织变得“官文化”流行。

#2 崇拜“神器”

很多公司都很崇拜绩效管理“神器”。

曾经非常流行KPI,所有的岗位都要有KPI——彷佛没有KPI的公司就是游击队,绩效管理完全围绕着KPI来进行。后来,出现了一篇非常著名的抨击KPI的文章,名字我就不说了,大家可以自行百度一下。于是乎,一夜之间,“神器”变成了“过街老鼠”。

一个神器破灭了,怎么办?没关系,还会出现新的“神器”!你看,新的“神器”不是又出现了——OKR。

于是无数的公司又捧起了OKR这个“神器”——所有的岗位和工作都要制定OKR目标。还有许多知名人士在发文著作,O该怎么定义,KRs该怎么定义,OKR该怎么跟……彷佛企业只要参透了这个秘密,彷佛企业只需要推行了OKR,就能够立马打通任督二脉,从此飞上了天。

然而,不可避免的是,有人质疑:“OKR与KPI到底有什么区别?难道传统的KPI就没有目标和关键成果物吗?难道传统的KPI就不进行目标和关键成果物的跟踪吗?”——“这个问题说不清楚,别讨论这个问题,你只要相信OKR就行了,总之OKR就是好!”……

当然,我并不反对企业合理运用KPI和OKR这两种工具,但是我反对企业无脑地、不加思索地、盲目地崇拜“神器”。一味地依赖和滥用工具,只会导致官僚主义和效率低下。

二 解决软件研发绩效管理问题,要回归第一性原理 

“刻舟求剑”的故事大家都学过:战国时,楚国有个人坐船渡江。船到江心,楚人把随身的宝剑掉进了江中。为了把宝剑找回来,他马上掏出一把小刀,在船舷上刻上个记号,并且对大家说:“这是宝剑落水的地方,所以我要刻上一个记号。”船靠岸后,那楚人立即在船上刻有记号的地方下水,去捞取掉落的宝剑。结果当然是捞不到。

虽然“刻舟求剑”只是一个寓言故事,然而只会僵化地执行某些方法论的人却比比皆是。

要解决软件研发绩效管理问题,绝不是依赖于某一两种方法论或者工具,而是要回归第一性原理,也就是要搞清楚研发绩效管理的核心目标和有效性原理,这样才能建立起正确的“三观”。

三 软件研发绩效管理的第一性原理分析

我个人认为,软件研发绩效管理有三大目标和原则:

  1. 尽可能地促进组织交付更多的价值
  2. 尽可能地促进端到端协作
  3. 尽可能地激发员工的内驱力和促进员工成长

下面,我对这三大目标和原则做一个详细讲解。

#1 尽可能地促进组织交付更多的价值

进行组织绩效管理,首先必须先搞清楚什么是组织绩效,以及如何衡量组织的绩效产出。

彼得·德鲁克在《21世纪的管理挑战》中谈到:“任何组织的绩效都只能在外部反映出来。……管理的责任是通过协调组织的资源,以在组织外取得成效。”——这段话为组织绩效管理指明了方向。

我们必须明白,组织绩效就是其向外交付的价值;组织的绩效只能通过其向外交付的价值量来衡量。对于任何组织,无论这是一个企业,还是一个大学或者机构,都是如此。

软件研发组织的绩效,也只能通过其交付的价值量来衡量。尽可能地交付更多的价值,就是整个软件研发组织的绩效目标。

所以,软件研发绩效管理的首要目标和原则只能是:尽可能地促进组织交付更多的价值。

那么具体如何衡量一个软件组织的绩效?

可以从以下三个方面来衡量软件组织的绩效:

  • 价值的生产和交付周期:即从需求提出到得到满足的端到端时间,也就是通常所说的“前置时间”。
  • 价值交付量:即一段时间内交付了多少价值,这里的价值通常表现为能满足客户需要的功能特性和实现的业务价值。敏捷开发中,往往使用“交付的故事点数”来衡量。
  • 交付质量:即交付的成果物满足内外部客户的程度。通过可以用“缺陷数”、“故障数”、“技术债”之类的指标来衡量。应当注意的是,我们不仅要关注外部质量,还要关注内部质量,否则就会导致未来价值交付量和交付质量的降低。

#2 尽可能地促进端到端协作

在软件研发组织中,要交付更多的价值,不是通过某个人的单打独斗或者个人英雄主义来实现的,而是通过整个端到端价值交付过程中的所有人员通力协作来实现的。

所以,软件研发绩效管理的第二大目标和原则是:尽可能地促进端到端协作。

那么该如何衡量端到端的协作呢?

可以通过度量价值流的流动效率来实现,具体做法如下:

 

假设:如上图所示,从需求提出到发布上线一共经历了6个步骤,每个步骤上有两个两个时间数据:“工作时间”和“停留时间”。我们可以把6个步骤的“工作时间”和“停留时间”加起来,就可以分别得到“总工作时间”和“总停留时间”(即“前置时间”),然后利用“总工作时间”/“总停留时间”,即可得到“流动效率”。图上的“总工作时间”是6小时,而“总停留时间”是7周(可通过“8小时”和“5天/周”,换算为280小时),这样可以计算出“流动效率”约为2.1%。

#3 尽可能地激发员工的内驱力和促进员工成长

许多企业为了解决协作问题,制定了复杂的工作流程,建立了精细的项目管理系统,希望能够通过流程和工具来解决人际协作问题。但这些做法,结果却往往只会适得其反——让过程变得沉重而低效,以及让员工变得官僚。

那么如何才能解决协作问题呢?《敏捷软件宣言》中给出了答案:个体和交互胜于流程和工具。

在软件研发组织中,要解决协作问题,应当依赖于每个人的主动性和能力。如果每个人都有足够的能力,并且积极主动地为他人补位,那么协作就不会是问题。反之,如果每个人都等让着流程和系统来协调,那么就会浪费无数的时间。而流程和工具定义得再完善,也无法弥补个人的主动性和能力上的缺陷。

所以,软件研发绩效管理的第三大目标和原则是:尽可能地激发员工的内驱力和促进员工成长。

四 运用三大目标和原则,评估您所在组织的绩效管理

个人认为以上这三大目标和原则,就是软件研发绩效管理的第一性原理。

如果能够将这三点做好,绩效管理必能成为组织发展的一大助力。反之,如果您的组织违反了这三点,必然会在某种程度上成为组织价值交付的障碍。

您能运用这三大目标和原则,去评估当前您所在组织的绩效管理,并找出问题和改进点。

五 您怎么看

您觉得软件研发绩效管理有哪些关键目标和原则?在您的组织中,采用的绩效管理办法,符合本文提出的三大目标和原则吗?还是说,您的组织中,有更为优越的指导思想?

欢迎在评论区留下您的观点。

 

本文作者:

李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

Scrum_tp

不能把开发团队对迭代目标的承诺视为保证

一. 莫把“承诺”当“保证”

在实施Scrum的过程中,许多团队在确认迭代目标时表现得非常谨慎和保守,他们担心如果实现不了迭代目标会遭受处罚。在某些组织中,我曾经听到某些管理者说出类似这样的话——“既然承诺了,就一定要兑现”、“如果做不到,为什么要承诺”、“如果承诺的东西都兑现不了,那么承诺有何意义”;同时,我也发现开发团队心存恐惧——担心因为承诺兑现不了,而被管理层看低甚至遭受处罚。

“承诺”是Scrum的核心价值观之一。然而,这些组织把“承诺”当成了“保证”,这就出问题了。

Read more

timg11

您知道为何要采用固定的迭代周期吗

本文作者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

 

一.  敏捷转型之初,Scrum团队可能会想基于发布来规划迭代周期

在前几天与某个团队进行交流时,ScrumMaster说想在未来几周内规划一个为其一周的小迭代以开发和交付一个小规模的需求。我建议仍然采用为期2周的迭代,可以在迭代内规划一个发布版本来完成这个需求的开发和发布。

Read more

timg-(1)

SAFe之PI运作指南

本文作者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

一. 什么是PI?

PI(Program Increment)是SAFe中的一个基本概念,目前还没有一个贴切的中文翻译,我们就直接称其PI好了。

1. ART中存在着两级增量开发节奏

 微信图片_20201029104732

图1 ART中的两级增量开发节奏

对于需要多个敏捷团队协同开发和交付的解决方案,存在着两级增量开发节奏(如图1所示): Read more

timg1-(4)

请不要再在每日站会上逐个问三个问题

本文作者:

李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

众所周知,敏捷团队每天要召开每日站会。《Scrum指南》中,将每日站会称为“Daily Scrum”,并给出了建议的会议组织方式——在会议上向团队成员提三个问题,分别是:

  • 昨天,我为帮助开发团队达成 Sprint 目标做了什么?
  • 今天,我为帮助开发团队达成 Sprint 目标准备做什么?
  • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?

然而许多团队把这个实践方式实施成了:让团队成员逐个回答三个问题。其实,这是一种对《Scrum指南》的误解。这种做法并不是一种好的实践方法,甚至可以认为,这是一种每日站会的反模式。

Read more

Scrum团队

优秀ScrumMaster的六大特质

作者:Mike Cohn

初始链接:

https://www.mountaingoatsoftware.com/articles/six-attributes-of-a-great-scrummaster

译者:李洁(Jerry Li

在上一篇专栏文章中,我曾断言,在理想的世界里,将会由团队选择自己的ScrumMaster,但这并不总是可行。我承诺我的下一篇专栏文章将讨论该在候选ScrumMaster身上探寻什么特质,无论选择是由团队本身作出,还是由团队以外人员进行。在本周的专栏文章中,我将给出您下位ScrumMaster应该证明存在的六大特质。

有担当

在大多数组织中,当某些人被赋予责任时,他们同时也会被赋予取得成功所必需的权力。ScrumMaster的情况却有所不同。虽然ScrumMaster不用对项目的成功负责——这一责任留给了团队,ScrumMaster确实对团队采用和实践Scrum负有责任。而ScrumMaster在承担这一责任时,却并没有被赋予任何可能有助于达成此目标的权力。

ScrumMaster的角色类似于管弦乐队指挥。两者都必须为一群才华横溢的人提供实时的指导和领导,这些人相聚在一起,共同创造出他们任何人都无法单独创造的东西。波士顿波普乐队指挥基思·洛克哈特(Keith Lockhart)在谈论自身角色时说:“人们以为,当你成为一名指挥时,你会成为某种拿破仑式的人物——你会想站在指挥台上挥洒你的权力。然而,我并不是沉迷成瘾者,而是责任成瘾者”同样的道理,一个好的ScrumMaster依靠责任而茁壮成长起来的——那种不具有同等权力的特殊类型责任。

谦逊

优秀ScrumMaster会为了自我而工作。一个好的ScrumMaster会为自己的成就感到自豪(通常会极其自豪),但这种感觉会是“看我帮助完成了什么”,而不会是更以自我中心的“看我完成了什么”。谦逊的ScrumMaster意识到这份工作并不能给自己带来公司专车或者临近大楼入口的停车场。谦逊的ScrumMaster会把自身需求置于首位,而是会愿意做任何必要的事情来帮助团队实现目标。谦逊的ScrumMaster认识到了所有团队成员的价值,并通过以身作则来引导其他人也持有相同观点。

协作

优秀ScrumMaster将努力确保团队中存在协作文化。ScrumMaster需要确保团队成员感觉自己能提出问题公开讨论,并且他们在这样做时能感到受支持。ScrumMaster应该通过其言行举止,来为团队营造一个协作的氛围。然而,优秀ScrumMaster除了要为协作态度树立榜样外,还要把协作塑造为团队的行为准则,并且会指出不恰当的行为(如果其他团队成员还没有做到的话)。

承诺

尽管ScrumMaster角色并不总是需要全职、一天八小时的投入,但也确实需要对其工作做出完全承诺。ScrumMaster必须像团队成员对待项目和当前迭代目标一样作出同等程度的承诺。

如果团队提出的障碍没有得到解决,就算是过了很多天,ScrumMaster也不应该就此停止。

不可能在每天结束时就将团队的障碍清单一扫而空,因为有些障碍需要花费时间才能消除。例如,说服管理者将一个全职资源投入到团队中,可能就需要一系列的讨论,其间还需要一些时间。

尽管可能不是全职工作,但ScrumMaster应该按自己是贯穿整个项目周期的ScrumMaster来规划工作。对于团队来说,在中途更换ScrumMasters是非常具有破坏性的 。

有影响力

要想成功,ScrumMaster就需要影响团队内外的其他人员。在初期,ScrumMaster可能需要影响团队成员,给予Scrum一个公平的尝试,或者行为上加强协作;之后,ScrumMaster可能需要影响团队,去尝试新的技术实践,例如测试驱动开发或者结对编程。ScrumMaster应该知晓在不诉诸“因为我这么说”的命令和控制风格情况下如何施加影响的方法。

多数ScrumMaster还会被要求影响团队之外的人员。传统团队可能需要被说服,以便Scrum团队提供部分助力;QA主管可能需要被影响,以便给项目提供全职的测试人员;或者还需要说服副总裁,去尝试下Scrum

虽然所有的ScrumMaster都应该知道如何利用他们的个人影响力,但是理想的ScrumMaster应该具备一定程度的企业政治技能。虽然“公司政治”经常被用作贬义;然而,一个知晓组织中如何做决策、谁做决策以及存在哪些联盟等等情况ScrumMaster,会是团队的优良资产。

知识渊博

最好的ScrumMaster具有技术、市场或其他能帮助团队实现目标的特定知识。拉法斯托(LaFasto)和拉森(Larson)对成功的团队及其领导者进行了研究,并得出结论:“深入而详尽地了解事情如何运作,会增加领导者帮助团队解决那些不易察觉而又必须解决的技术问题的机会。”拉法斯托和拉森注意到,这些知识可能是广而非深的,但团队领导者(比如ScrumMaster)“需要熟悉关键的技术问题。”

无论您的团队能否选择自己的ScrumMaster或者您正在为团队选择一个ScrumMaster,记住这六个关键特质,将有助于您找到最能胜任ScrumMaster角色的人选。

 

Scrum_tp

组织敏捷转型后该如何进行专业能力建设

作者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

 

前几天,与一位兄弟一起吃饭,他聊起了他们公司的敏捷实施情况。

他自豪地说;“我们公司已经完全按照Scrum的形式,对组织结构进行了重组。原先的职能式组织结构已经消失,不再存在产品部、项目管理部、开发部、测试部等职能部门,而是改为清一色的产品事业部。产品事业部由一个个Scrum团队组成,目前所有的研发人员都已经分配到固定的Scrum团队中。各个产品事业部正在热火朝天地赶版本。。。。。。”

听到这里,我问了他一个问题:“你们的专业能力建设,是怎么考虑的,具体由谁来负责?”

他先是一愣,然后告诉我:“目前组织中没有专门的人员负责这件事情,应该是由各个Scrum团队在自己搞。”

O(_)O,告诉他:“这顿饭该你请了!请听我细细道来。。。。。。” Read more

图片2

敏捷团队:被“猪队友”坑,可以投票把TA踢出去吗?

作者:Mike Cohn

译者:李洁(Jerry Li)

原文链接:

https://www.mountaingoatsoftware.com/blog/can-a-team-vote-someone-off-the-team

我们说敏捷团队是自组织的。但自组织到什么程度?团队成员们是否该拥有投票把某人从团队中除名的权力呢?

自从1997年首播以来,电视节目《幸存者》就常常被提到,询问团队是否有权投票将某人淘汰出岛。

回顾敏捷的起源
Read more