澳门新葡亰www3522vip - 知识共享 - 文章分享

澳门新葡亰www3522vip



您好!欢迎来到澳门新葡亰www3522vip!

加入收藏

登录注册

400-676-1955

实施敏捷的四个致命障碍

编辑日期 2019-04-17  阅读次数:1120 次

敏捷方法在中国推行的如火如荼,我也为多家公司做了敏捷的导入咨询,在实践中遇到了几个致命障碍,限制甚至阻止了敏捷方法的推行,我把有深刻体会的障碍总结出来,供大家在实践中规避之。


障碍一:没有建立组织级的敏捷价值观与环境。

很多公司在导入敏捷时,先从一个项目开始尝试敏捷方法,试图在单项目内成功了,再推广到其他项目。这种初衷是好的,但是往往事与愿违,为什么呢?因为缺乏组织级的敏捷环境,敏捷的价值观并没有在组织内得到从上到下的认可,尤其是领导们对敏捷的误解。是领导首先提出来要导入敏捷,在推行中也往往是领导先破坏了敏捷的原则,比如:

强加给项目组不合理的工期;

要求项目组为了工期牺牲质量;

在项目进展过程中随意抽调项目组成员做其他非目标范围内的任务;

不能保证Product owner的参与时间,对需求有决策权的人员不能全程参与项目;

要求项目填写一些没有产生直接价值的记录以便于给领导汇报工作;

不能为敏捷团队提供所需的集中办公环境、缺少足够的白板等。

要建立敏捷的价值观与环境,需要先从领导改起,需要领导认可敏捷的价值观、践行敏捷的价值观,为敏捷团队配备好资源、环境,提供好服务。


障碍二:团队人员的能力不足。

敏捷团队小而精,精,才能保证小,精,意味着需要全栈工程师,在分配任务时是按需求为单位,而不是以专业技能来分工,要求开发人员具备实现某个需求的所有技能,包括前端、后端的开发、界面的设计、数据库的设计、单元测试等等,而不是需要前端工程师、后端工程师、美工、数据库专家等等多个岗位、多个专业技能的人员协同才能完成一个需求。一个敏捷团队中应该包含了完成目标范围的所有技能的人员,这样的团队与成员才能最小限度的降低沟通成本,提倡充分沟通,但不是人为地增加沟通的成本。全栈工程师、跨职能团队是我们的理想,现实中往往做不到,而且还存在:

程序的个人技能比较低,写出的程序错误多、很脆弱;

开发人员的程序中有很多低级错误;

程序员在做单元测试时,不会编写完备的测试程序,往往只测happy的路径,异常、边界通通不测;

程序员承诺的工期往往无法兑现,在开发过程中总是遇到一些意料之外的难题;

PO对需求的陈述、描述需要花费很多时间才能沟通清楚;

测试人员对需求的理解不透彻,漏测的现象比较多;

Scrum Master不能根据本项目的特征制定出合理的工作流程与工作方法;

……

不重视对员工的基本能力的建设与培养,所谓的敏捷就是无源之水,无本之木!




障碍三:牺牲了质量追求速度。

有质量才有效率,一定是在保证了质量的前提下追求高效!很多管理者、团队成员都没有意识到在敏捷原则中隐藏的这个思想,只看到了快,而忽略了好,保证质量是前提,没有这个前提就是快而脏的模式,根本不是敏捷。典型的现象有:

明知需求太多,无法正常工期内实现,也不敢或舍不得砍需求!

测试发现的缺陷,不及时修改,攒到项目后期再修改缺陷;

不舍得花时间做单元测试,认为单元测试耽误了项目的工期;

迭代结束时,每个需求都没有达到DoD的要求;

只追求代码能完成需求,不关注代码的内部质量,后期难以修改,别人无法看懂;

对包含坏味道的代码不做重构;   

……

Kent Beck一再强调极限编程的12条实践必须一起执行,不能断章取义,12条实践互相支持,互相补充,是很有道理的!因为在极限编程中有一半的实践聚焦在代码质量上!


障碍四:在资源绝对匮乏的场景下,实施敏捷。

敏捷不是银弹,企业经营策略的问题,不是靠敏捷开发能够解决的。公司为了短期经营目标,拼命承接新项目,明知人员不足,也要倒排工期,勉强承诺,不砍项目,不砍需求,多个项目并行,一个人同时做多个项目,团队天天加班,996工作制,即使采用敏捷也无济于事,最终就会为了速度牺牲质量。敏捷方法是基于团队自己的估算来平衡团队的能力与项目的需求,如果不顾团队的开发能力,在资源绝对匮乏时实施敏捷,团队疲于奔命,总不能兑现自己的承诺,就会形成恶性循环,不可能敏捷起来,试想一下,你头上顶着三座大山,能跑起来吗?


Baidu
sogou