• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

组织敏捷转型常见的六大误解,你知道几个?

组织会出于多种原因而采用敏捷方法。一些组织希望能提高生产率和缩短产品上市时间,另一些组织希望能够获得更成功的产品,还有一些组织希望能增强开发人员与业务人员间的协作,以提升质量或提高团队成员的工作满意度。

当然,还有许多组织采用敏捷是希望能同时实现这些好处的组合。

但是,为了能从敏捷中尽可能多地获得好处,组织似乎也存在很多误解。在本文中,我想谈谈关于敏捷产品开发的六个误解。

误解1:敏捷不是仅适用于软件开发吗?

这个误解很有趣,因为作为最古老的敏捷方法,Scrum起源于实体产品的开发。最初的Scrum项目是复印机、本田汽车和照相机。

如今,敏捷已广泛应用于各种形式的产品开发,从实体产品到基于云的软件即服务(SaaS)。

但除了产品开发(包括硬件和软件)外,敏捷已被成功应用于:

  • 营销团队用来进行活动策划与执行
  • 律师用来管理案件和工作负荷
  • 组织转型(尤其敏捷转型)中的事务管理
  • 高层领导团队管理其组织
  • 家庭用来改进共处时光
  • 夫妻策划婚礼

当然,还有更多。任何比较独特(您之前从未做过十次)且复杂的事项都非常适合于敏捷。如果您因敏捷宣言中采用“软件”一词而感到困扰,只需用“产品”这个词代替即可。例如,可以将“可用的软件”更改为“可用的产品”,然后再重新阅读:[我们倡导]“可用的产品”胜过“完备的文档”。非常适合。为什么?因为敏捷可用于所有类型的产品——软件只是其中之一。

误解2:在敏捷中真的不存在经理角色吗?

我认为这一误解依然存在,因为太多的经理花了大量时间去做他们不该做的事情,而罔顾敏捷与否。

例如,经理经常将工作分解到个人任务级别。当得知在敏捷中这并非其工作时,他们会感到自己的工作被剥夺了。

事实并非如此,并未完全取消这项工作。

首先,诸如分配任务之类的琐事,本来就不该成为工作的一部分。

经理们应当专注于打造团队蓬勃发展所需的环境和文化。他们的时间不应该消耗在诸如谁该干哪个任务的琐事上。

彼得·德鲁克(Peter Drucker或许20世纪的领军管理理论家。他以目标管理思想和为设置目标而创建的SMART首字母缩写(目标必须是具体、可衡量、可达成、相关和有时限的)而闻名。德鲁克说过,经理们有五项工作:

  • 设定目标
  • 组织人和工作
  • 激励与沟通
  • 衡量
  • 培养人

当然,在某些组织中,其中某些责任可能会消弱。但是另一些职责——例如培养人,会变得更加重要。

在我实施敏捷以及与敏捷组织合作的这些年,没有人会决定要解雇所有经理。是的,虽然有些经理已经转换为工作更加聚焦的Scrum Master或产品负责人角色,但是在敏捷中依然存在经理角色。

误解3:干系人不是能随时发起变更吗?

毫不奇怪,最普遍相信这一误解(干系人能随时发起变更)的人群是干系人自身。

开发团队成员们都理解,在错误的时间引入变更是需要花费代价的。

设想一个在餐厅点餐的场景。你告诉服务员你要份鸡肉,随后又立即说:“不,请改为三文鱼

这种变更是没有成本的。

但是,如果您后来才改变主意,就要付出代价。如果在厨房开始煮鸡肉后,你告诉服务员将您的饭菜从鸡肉改三文鱼,就会出现食物浪费成本(餐厅可能会向您收费)。

如果在告诉服务员您想换三文鱼前,您已经吃了一半鸡肉,那花费会更加明显。

干系人把变更引入到迭代,就像吃饭者把鸡肉换成三文鱼一样。如果在正确的时间进行更改,成本可能很小甚至没有。但如果在错误的时间引入,则要付出代价的。

敏捷并不能消除所有干系人引入变更的成本。但是,无论在何时引入变更,优秀的敏捷团队都能降低变更成本。常用的方法是:

  • 短迭代
  • 短小的产品待办项
  • 经常性最小化并行工作数量,以尽可能快地完成每个产品待办项

但这并不是说团队不应该欢迎适当的变更。某些干系人需要的变更可能非常重要。但是,变更成本并不总是零,对于每个变更都应该对照其变更成本评估收益。

误解4:不是敏捷团队中的每个人都应该成为通才吗?

出于某种原因,有个关于敏捷的误解非常流行,即每位团队成员都需要能做所有的工作。

这个误解意味着,如果您聘请了世上最棒Oracle数据库管理员,您还希望这个数据库管理员同时也是名出色的JavaScript开发人员。并且,如果在一个迭代中不需要太多JavaScript开发工作,那么您出色的JavaScript开发人员还应该完全精通安全性测试。

这是完全错误的。

敏捷团队需要的不是每个人都掌握所有技能,而是重视任何确实具备多种专业技能的团队成员。

为了理解这一误解的错误之处,设想有一家运营良好的高档餐厅。从所看的电视烹饪节目中,我了解到这样的餐厅可能有糕点师。糕点师擅长制作糕点、甜点、面包和其他烘焙食品。

这听起来像是一个技艺高超而又专业化的角色。厨房里的另一个特殊角色可能是酱料师,他负责准备酱料、炖菜和其他类似食品。

在这个运作良好的厨房中,如果糕点师能帮助酱料师,例如在突如其来的洋葱短缺情况下时帮忙切一些洋葱,就已经很好了。但无论糕点师或酱料师,都不能期望其能完全胜任对方的工作。

在如今复杂的技术世界中,期望团队成员完全精通团队的所有技能是不现实的。取而代之的是,优秀的敏捷团队要学会重视掌握多种技能的团队成员。

拥有几名具备多种技能的团队成员,会有助于管理工作类型的平衡。比如说,有时团队需要更多的测试职位,如果有一两个团队成员能转做测试工作,就能极大地提供帮助。

但是,大多数团队即使有少数团队成员是真正的专家并且只擅长一门学科,也能做到这一点(即拥有几名具备多种技能的团队成员)。

误解5:我听说敏捷团队不做计划。

大多数优秀的敏捷团队都会做计划。只是,与传统项目相比,这种计划通常不太明显,因为敏捷团队没有一个早期计划阶段。

取而代之的是,优秀的敏捷团队将计划作为一系列小而重复的活动来实施,以确保其计划始终反映当前的实际情况。

这样,通过持续检视和调整,团队就能以开发产品的方式来做计划。

对于任何敏捷团队来说,其计划程度都应只限于重大决策的需要,而不应过于深入到未来。

但大多数组织和团队都会有一个计划,以在某种程度上估计接下来要完成什么以及何时完成。

事实上,尽管存在这种误解,由于能尽早洞察其开发软件的速率,敏捷团队能更容易地制定出可信的计划。

设想一个具有分析、设计、编码和测试阶段的传统团队。如果足够幸运,团队或许能将计划的提交时间推迟到设计阶段结束时。但就算到那时,团队仍不知道他们在编码和测试上能有多快——他们还没有开展过任何此类活动。

相反,敏捷团队每个迭代都会运转整个开发过程。每个迭代都会包含一些分析、设计、编码和测试活动。这就使敏捷团队能尽早地洞察到,其能以多快的速度将想法转化为新特性。

误解6:敏捷团队不是不做架构规划就开发产品吗?

终于到破除最后一个误解的时候了——关于敏捷团队不做架构和产品设计的误解。

敏捷团队肯定会设计他们的产品。敏捷团队以同样的方式,增量地进行计划、架构和设计。

这使得他们能够持续检视和调整其体系结构和设计,从而使其成为最佳方案。

这就意味着不存在前期的、决策所有体系结构的阶段。取而代之的是,产品架构会随着时间而浮现出来。

技术团队成员会首先关注产品中他们认为存有风险的任何方面。例如,如果要交付的产品在所需吞吐量上存在挑战,那么团队和产品负责人就会选择在早期研究如何达到目的,以降低该风险。

同样,敏捷产品的浮现式架构设计也是刻意的。架构不是一天就出现的。它是在技术团队的刻意引导下逐渐浮现的。

这意味着敏捷产品确实拥有基础架构。但是,有关该架构的决策是在项目过程中根据需要而作出的,而不是在项目开始时就完全作出的。

还有其他什么需要破除的敏捷误解吗?

我已经破除了围绕敏捷产品开发的六个误解。您在组织中还遇到了哪些其他误解?请在下面的评论中分享您的想法。

 

 

作者:Mike Cohn

译者:李洁(Jerry Li

原文链接:

https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted

Search
最新敏捷认证课 ~ 火热报名中
3月2-3日
Scrum.org专业Scrum Master (PSM I) 认证课
丁志润 Derek Ding 授课
3月23-24日
高级Scrum Master (A-CSM) 认证课
Ethan Huang 授课
3月30-31号
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280