组织会出于多种原因而采用敏捷方法。一些组织希望能提高生产率和缩短产品上市时间,另一些组织希望能够获得更成功的产品,还有一些组织希望能增强开发人员与业务人员间的协作,以提升质量或提高团队成员的工作满意度。
当然,还有许多组织采用敏捷是希望能同时实现这些好处的组合。
但是,为了能从敏捷中尽可能多地获得好处,组织似乎也存在很多误解。在本文中,我想谈谈关于敏捷产品开发的六个误解。
误解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
敏捷企业内训推荐: