一个实例:敏捷管理中的障碍识别和根因分析

实施敏捷管理之后,团队连续两个迭代的交付没有完成承诺。

在回顾会议中,大家认为是因为开发之后代码缺陷率比较高导致的。

进一步往下追溯,团队认为,代码的缺陷来源主要是系统的架构不够灵活,耦合度高,一个修改可能影响到很多地方,但是这些影响却没有在代码开发时被识别出来,直到功能测试时才暴露。

而这个暴露的是:

1. 业务架构没有预先做好设计,功能的简单堆叠导致页面逻辑复杂。

2. 开发前团队没有做好模块化设计,导致系统的结构越做越烂。

3. 团队没有重构的习惯。

为什么会有这些问题呢:

1. 业务缺乏对产品的整体观。

2. 团队被需求追着跑,更倾向于使用战术开发,短期内让功能跑起来,而不管长期的扩展和复用。逐渐的团队的效率下降,反过来又影响需求的交付。

聊清楚这些问题后,经过和PO的商议,团队做出了以下两个action decision:

1. 每个迭代开始前,在已有的planning会议基础上,增加一个需求梳理会议,理解需求,共同做好业务和技术架构设计。

2. 每个迭代中预留10%~20%的空间用于系统的优化重构。

3. 代码集成前需要经过peer review才能提交。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 敏捷宣言的背后,有一系列先驱们认为团队需要遵循的原则,一共12条,如下: 1. 最优先要做的是尽早、持续地交付有价...
    雷大野阅读 243评论 0 0
  • 写在前面 作为项目经理,我们经历了不同的项目,却总是受限于相似的困局。比如以下三个典型难题: 团队目标不一致 团队...
    ThoughtWorks阅读 6,808评论 3 83
  • 写在前面 6月27日,我在ThoughtWorks PM社区上做了一个直播分享——项目管理标准化。 在这次分享中,...
    万学凡阅读 3,942评论 0 7
  • 概览 1 敏捷革命 团队的成功是从一个演变并适应的过程,而不是先计划再优化的过程。 预测为基础的流程(定义、设计,...
    AgileHouse阅读 4,058评论 1 14
  • 概览 自序 精益原则要求: 企业要将具有最大商业价值作为软件开发的方向 团队拥有自己的系统并持续不断的改进系统 管...
    AgileHouse阅读 2,556评论 0 0