扫码阅读
手机扫码阅读

敏捷方法(实践)有哪些?

250 2023-08-26

随着敏捷项目管理模式在国内的流行,各流派敏捷实践培训风起云涌,Scrum框架的相关实践和案例最多,也最为国内推崇。然而在实际应用中,我们会遇到怎么样的阻碍?如何突破这些阻碍,让客户满意,提升客户交付价值?

我们通过敏捷圈内人士的问卷调查,获取了一手的最新各类企业关于敏捷转型中的成与败,选取几个案例进行剖析进而阐明不同组织中,要想实现敏捷转型,我们应该如何避坑。

敏捷转型实例

以下企业和人名出于隐私保护,具体信息都已隐去。

姓名(职务)

公司性质

实施方式

实施时间

结果

David,Scrum Master

某知名大型互联网公司

自底向上

2018年05月

成功

Robin ,CTO

某创业型公司

自顶向下

2018年09月

成功

叶胜,Scrum Master

某大型互联网公司

自顶向下

2018年02月

失败

胡天天,Scrum Master

某知名大型软件公司

全面推进

2019年03月

失败

陈凯陆,Senior Engineer

某创业型公司

自顶向下

2020年2月

成功

与以上专家沟通中,主要谈到以下几个问题:

1)为什么使用Scrum进行项目管理?

2)实施Scrum过程中采取什么的路线,选择的原因?

3)实施中最大障碍是什么,如何解决的?

4)实施Scrum带来了哪些收益?

5)Scrum实施是如何失败的?

1)为什么使用Scrum进行项目管理?

Robin:客户需求变化实在太快了,产品经理在控制客户需求上经常会产生矛盾,使得双方经常合作的不愉快,影响客户满意度,也严重损耗公司项目团队的自信心,为了更好响应客户,让项目团队有更开放的心态拥抱变化,引进了Scrum框架进行项目管理。

叶胜:我进公司的时候,公司已经有一套完整的传统项目管理流程在跑,由于效率比较低,交付周期过长,经常引发客户的不满,我进来后,劝说部门领导可以在小范围实施Scrum敏捷开发,并告知他我这边有很多成功经验,可以帮助现有团队做到快速交付,提高整体绩效,部门领导很审慎的态度接受了。

2)实施Scrum过程中采取什么的路线,选择的原因?

David:我们不是简单的照猫画虎,而是从Aglie中的很多理念贯彻到团队日常工作中,例如:XP的核心做法,再结合我们实际环境所具备的条件,采用Scrum的几个回顾会议来帮助团队做改进,团队逐渐磨合默契后,沉淀出一套适合我们自己的敏捷方法。每次在Sprint迭代的回顾会议上,我们对当前Sprint中做的不好的地方拎出来,作为下一次Sprint的重点改进内容,几个Sprint之后,整个团队的效率都提高了。同时我们采用自底向上的方式,从一个项目团队试点,获得成功后,逐渐推广到项目集的相关团队,最终实现了整个研发部Scrum框架的全面落地实施。

叶胜:公司太大,一个业务线的研发团队就有1000多人,是否采用敏捷或采用其它方式,都是老板说了算的,我充其量是个执行者,用自己已经具备经验和技能帮助团队做好Scrum转型。

3)实施中最大障碍是什么,如何解决的?

胡天天:先别说实施敏捷的障碍,就是我们传统PMP的做法,都会有很多问题,Scrum这种框架的引入本就是为了更高效交付客户价值的一套理念,以下障碍,大部分研发团队都会遇到:

1. “需求太模糊,造成后期开发沟通成本巨大,反复和产品经理沟通花了太多时间。”

2. “发布周期太长,一个 Sprint 要做 3、4 周才能上线,产品经理希望每周都能上两次线。”

3. “由于 Scrum 过程的特点,我们不能很系统地把握历史需求和整个产品的架构。”

4. “上线时间被业务拍死了,哪儿有时间做单元测试,连代码 Review 的时间都挤不出来。”

5. “目前的 Backlog,人和人之间的协调,任务之间的瓶颈什么的都看不大清楚。”

6. “需求上线,至少 1 周才能分析数据看结果,没法在这个 Sprint 一做完就提出新的改进方案。”

7. “开发节奏太快,产品开发测试都没有时间停下来仔细考虑,历史需求没有善加利用。”

陈凯陆:我觉得最大障碍还是团队成员对这个概念的理解不够,没有接触过相关实践,在前期的实施过程中,只有其形,没有其实,对于为什么这么做,都无法有清楚的认识。那我作为团队的高级工程师,其实是负担了部分架构责任的,为了更好交付功能,会利用业余实践去学习下相关知识,理解后,在与团队成员配合中,通过实际例子讲解,逐渐消除大家的疑虑,经过几次Sprint之后,大家都能对Scrum有一定认识了,然后会觉得自己确实从中受益了,会更好的朝着自组织团队的方向发展。

David:我这边最大的障碍主要还是来自于高层的支持以及团队对于Scrum流程的认识。我们的领导幸好还算开放,对于先进管理模式的引入虽然比较谨慎,但是还是给了不少支持,放手让我在实际项目中去尝试,成功后再去推广;团队成员大多偏向于传统的开发模式,对Scrum并没有多少认识,所以为了解决认知问题,我在前期组织过Scrum的相关培训,通过一些场景小视频,以及提炼的重点内容,让团队成员在进行Scrum敏捷开发之前就已经知道自己的角色,以及自己要做什么了,所以推广起来也还算顺利。

在与胡天天的深入沟通中,他解释道,为了解决需求模糊问题,帮助产品经理整理需求模板,在进入计划会议前,增加内部评审环境,参与角色有产品、测试和研发;针对第二和第三个问题,我们对需求进行排序后,讲产品经理关心的可见部分需求,安排特定迭代优先级,在每周的固定时间进行开发转测和演示;

4)实施Scrum带来了哪些收益?

David:收益应该是几部分,一方面对公司来说,不太容易衡量,只能感性认知,通过对客户的回访收集客户满意度,迭代周期的缩短肯定是可以为公司交付能力的提升塑造口碑的,但是需求的及时响应,可能也增加了公司的研发成本,研发模式的引入,并无法解决成本问题,只能通过效率提升抵消这部分损耗。一方面对于团队来说,确实是提高了整体研发交付能力,但也带来不好的一面就是受到公司企业文化影响,sprint之间的间隙很短,长期都处以一种上战场状态,容易产生疲怠感;

Robin:我们老板比价开放,第一个项目Sprin看到成果后,就要求全公司采用Scrum敏捷式管理,甚至销售、HR都要遵守Scrum规则。所以整个公司在很短的时间内适应了Scrum规则。新人入司第一件事就是Scrum培训,然后在项目中进行锻炼,逐渐习惯Scrum规则。目前公司通过Scrum方式已经交付了两个客户项目,收到不错的反馈,所以我们正在研究大规模敏捷的做法,讲研发团队关联的项目纳入体系,提升整体战斗力。虽然遇到很多障碍,但因为是初创公司,团队规模不大不小,调整适应的能力还是不错的。

5)Scrum实施是如何失败的?

叶胜:我们的问题在于,有些高层错误理解了 Scrum 和 Agile,导致歪曲了某些东西,使得 Agile 变得形式化。举个简单的例子,当时的 Scrum Master 负责一个大项目的开发,走的比较顺利,然后有个项目经理发现这个东西挺好,就单独把 Daily Scrum 拿来进行推广;结果,这个经理并不理解什么是 Scrum,他把 Daily Scrum 变成了 Daily Report,而其他 Scrum 的精华部分都没有推广。

每个员工都要在早上固定时间开 Daily Scrum,然后把当天的任务告诉给他,让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了,引起很多人反感;另一点就是很多人认为这样的 Daily Report 太频繁太低效,而且还有压榨员工的嫌疑。所以逐渐大家谈起 Daily Scrum 来都是恶心的不得了,于是经理也知趣地取消了 Daily Scrum,再到后来在公司内部就没有人谈什么 Agile 了。

胡天天:我们是分布式开发,当时中方的团队对于敏捷开发只是一知半解的水平(当然,我们都确定外方团队也好不到哪里去)。某一天,国外的 PM 突然发来几个链接,一看讲的是一个闻所未闻的词,就是 Scrum 了。好像就给了一两天的时间去看 Scrum 的介绍文档,然后就开 Stand-up Meeting(站立会议)。其实大家都知道沟通进度的重要性,但我们双方 7、8 个小时时差,那边一上班这边就快收拾东西走人了,就这样还要讲自己今天要做些啥,遇到啥困难,一点意思都没有。而且最关键的问题在于双方文化差异,语言差异,还有项目的整体规划协调。很快 Stand-up Meeting 就成了形式。后来,我们又间歇性地在自己团队内部做 Standup,但最后还是因为不能带给我们太大价值,流于形式,就放弃了。

再说其他方面,我们没有计划会议,有名义上的 Product Owner,但是他不跟我们解释每一个 Story 具体的细节,也不说如何定义这个 Story 的完成状态。我们自己搞过 Retrospective(回顾),但总结出来的看法反馈到那边就没动静,后来也不做了。在第一次使用 ScrumWorks 的时候,好歹 Product Owner 还能来设置优先级,我们估算时间,最后决定哪些故事放到下一个 Sprint 里面。到后来就只要是人,就能往 Scrumworks 上扔任务,也不 知道哪些重要哪些不重要,我们自己开发人员看着办,最后剩下几百个小时完不成再扔到下一个 Sprint 里面去。后来公司里又搞 CMMI 认证,把我们项目作为 Pilot(试验),名义上是改善流程,但实际做法就是为了应付拿证,那就是一强制推行啊,把人搞得想辞职的心都有了。这个项目中间发生的事情太多了,反正磕磕碰碰的还在往前走,但现在我听见公司里有人提到敏捷就犯恶心。

Scrum有三大精髓内容:

1.解决客户问题

Scrum是通过交付产品的方式,解决客户的问题,这一条主要是站在Scrum Master的角度来说的。如果Scrum转型组织一味追求度量的数字,那么敏捷这条路走错了,因为Scrum最终的目标就是一定要让客户满意,要让客户的最终用户满意,帮助客户解决他的问题。

2.重在关系

这个关系包含团队成员之间的关系,团队与客户之间的关系,处理好关系,是正确做事的前提,对于Scrum来说,精髓的内容就是帮助客户真正的提高交付速度。只有提高了交付速度,才能不断尝试探索,如果交付速度不行,谈何快速应对变化呢?

3.重视反思

每天作为Scrum Master应该反问自己、反问团队,我们现在是否帮助客户解决问题了,我们和客户的关系怎么样?通过每天不断的反思,不断的问这些问题来促进团队成长。

以上三点如果做不到,最好不要硬上Scrum,上了也解决不了啥问题。因为采用Scrum以后,不断暴露的团队问题或是问题被隐藏,没人愿意接受,也没人愿意改进,那么我们上Scrum的意义在哪里?

Scrum有三大反模式:

1)以流程为中心

搞质量体系的和做开发的同学都不适合制定流程,流程要以提高工作效率为前提,因公司企业文化团队文化不同而有所不同,更重要的是团队一起反思如何更快的进行产品交付。而不是如何制定一个更完美的流程。

2)以考核绩效为中心

以绩效来考核团队的时候,团队会受到激励也可能受到打击,因为绩效本身就是双刃剑,不同企业文化有不同的绩效考核方式。没有正确的绩效也没有不变的绩效。所以还是回到Scrum精髓的本质,把团队的注意力拉回到正确的路上。

3)组织“推动”敏捷转型

很多的组织都是“推”敏捷,员工是被推着走,管理层也是被老板推着走。没有人愿意主动寻求改变。既然如此,你还折腾啥呢?大家都累,结局只能是:失败。Scrum转型,需要是团队、管理层、老板都一致认为,我们需要改,我们能改好。

总结下,本文主要通过对敏捷圈子的几位大佬的“访谈”,对为什么转型,怎么转,成功和失败的比较,以及对Scrum 框架的三个精髓和三打反模式进行了对比分析,希望对想要做敏捷转型,以及正在做敏捷实施的小伙伴有些实质性的帮助。

想要了解更多,点击 查看原文

公众号全新升级,专注PMO项目管理、技术开发经验,提供各类学习资料下载,杂谈社会百态,传播正能量!

52 篇文章
浏览 9143
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线