实施敏捷的四个致命障碍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

……

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

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

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

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

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

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

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

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

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

……

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

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

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