敏捷转型有很多坑，今天你跳了没有？

1、敏捷和瀑布式只能二选一？×

1、敏捷开发和瀑布式开发是有结合的可能的，举一个例子，当有一个新的项目创意时，我们可以采用敏捷的方式快速试错，快速获得市场反馈，产出符合客户和市场需求的产品，但是如果后续的市场和需求比较稳定，我们完全可以回归的瀑布式开发的模式。
2、另一方面如果一个组织原有的模式是瀑布式开发，现在要转型为敏捷模式，那一定会有一个过渡期，这个转变的过程绝不是“一刀切”，会有很长一段时间采用混合模式！

2、项目敏捷就够了（有项目就申请资源，结束了就回到资源池）；×

这是非常欠妥的做法，这种模式是希望做到项目敏捷，而不是组织敏捷，理想的认为项目采用敏捷管理方式即可，项目结束了就回到职能团队，所以每当有新的项目都要有一个磨合期，要重新确定项目角色，而职能组织并不能有效的给予支持，这样的结果是组织永远停留在原有的模式，项目敏捷也最终会变为伪敏捷。

3、TDD和ATDD是测试团队的实践；×

不管TDD还是ATDD都是团队整体的实践，TDD让测试与开发界限模糊，ATDD让需求与测试界限模糊；所以归根结底都是各个角色间合作的实践，而不是测试自己的变革；

4、价值驱动；×

价值驱动其实是没有错的，这正是敏捷提倡的交付原则，但是只有价值驱动吗，如果一切的情况只考虑价值，那就会带来很多问题，价值高的风险低，价值低的风险高，这样的情况一定是先做价值高的吗？好像不一定，所以归根结底需求的优先级是受到价值、风险、市场窗口、成本等多个因素的影响，价值驱动没错但是不是全部，不要只顾着喊口号而被“价值”带偏！

5、我们有SA、BA，他们负责PO的工作；×

现有的角色转型为产品负责人是完全没有问题的，但是如果在中间多加一个角色就会引入很多问题，比如让SA做PO和研发团队的桥梁，这个假PO（SA）就成为了有责无权的产品负责人，真正的产品负责人并没有和研发一起工作；所以，SA能做的就是传话筒，既不能代替PO决策，也不能给予团队必要的指导，而真正的产品负责人只会说：“欢迎你们采用敏捷开发模式，你们一定能变的更高效，让我也参与吗？这个可能很难，还是让SA代替我吧！”，欲哭无泪！

6、质量经理制定DOD标准；×

如果你的团队是由质量经理制定DOD的标准并要求各个团队遵照执行，那你们就还不够敏捷，DOD应该是有团队来制定的，是团队内各个角色协商的结果，质量经理也许经验丰富，但是永远不能代表团队的自管理意愿，并且我们期望每个工作交接的节点都应该有明确的DOD标准！

7、敏捷教练是团队的联络人！×

敏捷教练永远不能成为团队的联络人或者代表，沟通应该是团队自己的事儿；协调和促进协调是有区别的；敏捷教练要做的是促进沟通和协调，如果团队完全依赖敏捷教练负责沟通，团队的沟通能力就会退化，比如SOS会议由scrum master代表团队参加就是明显的错误做法！这里再多说一句，SOS会议也不应该把团队站会的问题再重复一遍，而应该把重点放在影响团队间相关联的问题上，比如：我们近期做了哪些功能会影响其他团队，我们计划做什么功能会影响其他团队，有没有需要各团队配合解决的问题？

8、团队速率大比拼！×

我们知道敏捷推荐进行规模估计，所以会采用故事点进行估算，但是每个团队的故事点选择标准是没人任何相关性的，也自然没有可比性，所以如果你的团队再搞团队迭代速率大比拼，那不仅没有价值还会伤了某些团队的心！

9、持续集成就是用最好的工具！×

持续集成绝不是工具而是实践，而且非常核心的一点是需要研发人员改变工作习惯；所以如果你的团队花了很多钱上了好用的工具，但是却做不到短周期的集成，那工具就没有发挥价值，并且持续集成还有很多方面需要关注，比如：快速修复问题（安灯拉绳）、小批量变更、每日集成、自动化测试的支持、可视化管理；以上内容都不是工具层面的问题，而是团队策略、流程改进的关注点！

10、外来的和尚会念经！×

首先，我们承认外部教练的价值，但是如果一味的信奉外部教练能够帮我们解决所有问题，恐怕最后的结果会让你大失所望，外部教练应该是与内部教练相辅相成的 如果外部教练只帮助你推动实践和工具的落地，而不注重内部教练的培养，那您可能上当了！