CSM|在企业中推行敏捷，这些常见的问题你遇到过吗？

无论你的公司是在做敏捷转型还是一开始就使用敏捷，在推进敏捷的过程中往往都碰到了很多的问题。下面列举四个常见的问题，看看你是否有遇到过？

敏捷团队中应该包含了完成目标范围内所有技能的人员，这样的团队才能最大限度的降低沟通成本，充分沟通、理解需求，而不是因为人为的原因而增加沟通成本。全栈工程师、跨职能团队是我们的理想，可现实因为种种原因往往很难组建出一个这样的团队，比如：

开发人员的个人技能比较低，程序错误低，适配性差；

开发人员做单元测试时，不会编写完备的测试程序；

承诺的工时往往无法兑现，开发过程出现一些意料之外的难题；

产品负责人对需求的陈述、描述不清，造成沟通不畅，团队成员对需求理解不一致；

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

典型的情况比如有：

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

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

发现缺陷，不及时修改；

遇到临时变更或者加塞需求，不对原迭代需求列表进行重新梳理，导致迭代容量过大；

这一点在中小型公司尤为常见，公司为了短期经营目标，拼命承接项目，明知人员不足，也要倒排工期，勉强承诺，不砍项目，不砍需求，多个项目并行，一个人同时做很多个项目，团队天天加班，996工作制，即使采用敏捷也无济于事，最终就会为了速度而牺牲质量。

敏捷方法是基于团队自己的估算来平衡团队的能力与项目的需求，如果不顾团队的开发能力，在资源绝对匮乏时实施敏捷，团队疲于奔命，总不能兑现自己的承诺，就会形成恶性循环，不可能敏捷起来。

因为缺乏组织级的敏捷环境，敏捷的价值观并没有在组织内得到从上到下的认可，尤其是领导对敏捷的误解。

是领导首先提出来要采用敏捷，在推行中也往往是领导先破坏了敏捷原则。比如：

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

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

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

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

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

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