从发展社会主义到外企进入，无数的案例告诉我们，照猫画虎，原样照搬在这里是很难行得通，需要进一步特色化，才能更好的发挥作用。
敏捷开发也是同样如此。
敏捷开发是一种轻量敏捷，第一原则是快，何谓快呢？不是大家误认为的那样，加班加点，那就是快。快是指节奏，开发，测试，同步介入，快速产出可交付的产品，可大可小，重点是确保高质量的交付。\
什么是轻呢？这个好理解，抗战时期我们优秀的战士们，发明了游击队五，队伍人少，灵活，但每一位战士都是钢铁战士，可独当一面，敏捷也是一样，团队成员有着基本配置，可快速反应，进入开发节奏，交付产品。
敏捷方法并不是一个低门槛的方法，相反，它的实施有一定的门槛和难度，**鲸舟**在实施敏捷实践中发现一些问题，应该算得上实施敏捷方法的一些挑战。
挑战一：团队成员的能力不足。
敏捷团队如我前面所讲的那样，小而精，精干，才能保证小，每一个团队成员所掌握的技术技能能够确保他们承接任何任务需求，即敏捷团队成员需要全栈工程师。
在敏捷团队中分配任务时，是以需求为单位，而不是专业技能来分工，这就要求开发人员具备实现某个需求的所有技能，包括后端的开发、界面设计、数据库的设计、单元测试等等，而是不是需要多个岗位支持协同才能够完成一个需求。
敏捷团队中应该包含了完成目标范围内所有技能的人员，这样的团队才能最大限度的降低沟通成本，充分沟通、理解需求，而不是因为人为的原因而增加沟通成本。
全栈工程师、跨职能团队是我们的理想，可现实因为种种原因往往很难组建出一个这样的团队，比如：
- 开发人员的个人技能比较低，程序错误低，适配性差
- 开发人员做单元测试时，不会编写完备的测试程序
- 承诺的工时往往无法兑现，开发过程出现一些意料之外的难题
- 产品负责人对需求的陈述、描述不清，造成沟通不畅，团队成员对需求理解不一致
- 测试人员对需求理解不透彻，漏测的现象比较多
- Scrum Master水平较低，不能根据项目特征制定合理工作流程和工作方法
挑战二：牺牲质量追求速度
质量和效率，是一对好兄弟啊。有质量才有效率，保证了交付质量，再谈效率的提升才有意义！在实施敏捷转型过程中，发现很多管理者、团队成员都没有意识到在实施敏捷，一味求快，而忽略了质量问题，先快速交付，出现问题，再返工修复，这不是真正的敏捷，而是典型假敏捷。典型的情况比如有：
- 追求代码完成需求，不关注代码质量，后期难以修改，别人无法看懂；
- 不舍得花费时间做单元测试，认为单元测试耽误了项目工期
- 发现缺陷，不及时修改
- 遇到临时变更或者加塞需求，不对原迭代需求列表进行重新梳理，导致迭代容量过大
诸如此类，不胜枚举。
挑战三：资源匮乏的场景下，实施敏捷
敏捷不是万能良药，企业经营策略的问题，不是靠敏捷开发能够解决的。
这一点在中小型公司尤为常见，公司为了短期经营目标，拼命承接项目，明知人员不足，也要倒排工期，勉强承诺，不砍项目，不砍需求，多个项目并行，一个人同时做很多个项目，团队天天加班，996工作制，即使采用敏捷也无济于事，最终就会为了速度而牺牲质量。
敏捷方法是基于团队自己的估算来平衡团队的能力与项目的需求，如果不顾团队的开发能力，在资源绝对匮乏时实施敏捷，团队疲于奔命，总不能兑现自己的承诺，就会形成恶性循环，不可能敏捷起来。
挑战四：没有建立组织级的敏捷价值观与环境
企业组织在采用敏捷时，先从一个项目开始尝试敏捷方法，视图在单项目内成功了，再推广到其他项目。这种初衷是好的，但往往事与愿违，为什么呢？\
因为缺乏组织级的敏捷环境，敏捷的价值观并没有在组织内得到从上到下的认可，尤其市领导对敏捷的误解。是领导首先提出来要采用敏捷，在推行中也往往是领导先破坏了敏捷原则。比如：
- 在项目进展过程中随意抽调项目组成员做其他非目标范围内的任务；
- 强加给项目组不合理的工期；
- 要求项目组为了工期牺牲质量；
- 不能保证Product owner的参与实践，对需求有决策权的人员不能全程参与项目；
- 不能为敏捷团队提供所需的集中办公环境、缺少足够的白板等
- 要求项目填写一些没有产生直接价值的记录以便于给领导汇报工作；
因此，要建立敏捷的价值观与环境，需要先从领导做起，需要领导认可敏捷的价值观、践行敏捷的价值管，为敏捷团队配备好资源、环境、提供好服务。
以上！
最后推荐一个我们自研的精益敏捷研发管理工具——鲸舟。如果您刚好需要寻找敏捷研发管理工具，欢迎关注试用。
鲸舟 | 数智化精益敏捷研发管理平台 现在注册试用，30人以下团队，永久免费。
