如何避免敏捷失败？

很多人都听说敏捷，有些人知道敏捷是什么，有些人也尝试过敏捷，本章中将列举出一些常见的错误敏捷实践，如果想要避免敏捷失败，建议还是要对照下你所在的敏捷团队中有没有类似的敏捷实践，这对于你的敏捷成功是很有帮助意义的。

敏捷错误实践一： 没有或者糟糕的项目回顾会

回顾会的目的在于总结和发现问题，一句话——继往开来，团队中的每个人都可以想一想在过去的这个迭代冲刺中，哪些方面做的很好，哪些方面可以做的更好，哪些方面做的不足，从中我们可以吸取哪些教训，如果迭代回顾会无法做到这边方面，那么我们称这样的回顾会是无效的。

敏捷错误实践二： 糟糕的PO(Product Owner)

PO 应该深切参与敏捷中的每个重要环节：每日站会、迭代回顾会、迭代计划会，当然了PO并不需要参与到迭代计会中的任务划分，迭代计划会中的任务划分是项目团队的工作职责。PO要负责按业务价值对积压工作项—backlog进行任务优先级划分，比如，定义业务计划、产品发布路线图，为项目组定义清晰的用户故事，进行中的变更不属于迭代积压工作项—backlog。

敏捷错误实践三： 糟糕的敏捷教练

敏捷教练不应该成为团队管理者，敏捷团队本身应该是自我管理的，对于敏捷团队来讲，敏捷教练应该是引导者角色而非领导者角色。当团队成员出现分歧时，敏捷教练要负责做最终决定，敏捷教练应具备识别团队障碍优先级的能力，并且尽速消除团队障碍，敏捷教练应确保整个团队目标一致，并且通过不断的改进来达到最终的目标。敏捷教练要确保团队任务并不是由管理者来分配的，而是由团队成员主动领取的。

敏捷错误实践四： 每日站会耗时太长

在每日的项目站会上，团队成员应该简要陈述三点：昨天我做了什么，今天准备做什么，目前存在哪些阻塞。站会切记不能长篇大论，具体细节可以会后讨论，根据实际团队规模大小，站会不宜超过10到15分钟。迭代回顾会和迭代计划会同样也应该有时间限制，敏捷会议应严肃活泼，轻松却不偏离会议主题。

敏捷错误实践五： 错误定义已完成项

在每次迭代结束，迭代完成产生的软件应该是满足产品定义级别，因此也必须是可以演示的，话句话说，迭代所产生的软件产品应充分测试、包括单元测试、集成测试以及必要的人工确认测试。软件开发人员充分了解并知晓软件测试人员的测试退出标准。

敏捷错误实践六： 没有团队速度跟踪

当整个项目团队速度出现下降，敏捷教练必须采取一些措施来改善这些状况，他可以通过5问法方法或者鱼骨图法来确认问题根本原因

敏捷错误实践七： 冲刺内采用瀑布开发

在每个冲刺迭代中，75%的用户故事100%完成要好于100%的用户故事都完成了，但每个用户故事的完成度只有75%，谨记：用户故事并不属于单独的个人，而是属于整个项目团队，这个团队包含所有的开发人员和项目测试人员

敏捷错误实践八： 遗留过多技术债务

每次冲刺迭代中，应尽可能的避免产生技术债务，技术债务的增多则会带来更多的缺陷，当需要重构时，应立即重构，因为时间越久，花费的代价也就越长，BUG也应该立即处理。

敏捷错误实践九： 过多打扰或者新增功能特性直接绕过PO

项目团队应该全神贯注，避免都多打扰或者中断，项目PO应负责将新增功能需求特性添加到项目积压工作项中，并对工作项进行优先级排队，如果功能特性比较重要，那么团队可以选择在下个迭代进行交付，应尽可能的避免直接将新增功能需求发送给团队成员。

敏捷错误实践十： 没有分析或者没有文档

敏捷并不意味者完全没有分析或者没有文档说明，只是分析或者文档的方式与传统略有不同：它是一个持续性的过程。积压工作项中的用户故事应足够清晰明了，确保团队成员可以很方便的进行任务拆分和工作量评估，这也就是说，用户故事在项目初期并不需要十分详尽但需清晰明了。

落地敏捷可以使用Worktile，从需求管理、迭代管理、版本管理、缺陷管理、统计报表等多方面实现敏捷开发，覆盖标准Scrum流程，即开即用。

原文链接：https://dzone.com/articles/how-make-scrum-fail
翻译：@ HelloWorld