使用技巧

如何避免敏捷失败?


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

image.png

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