一次调整迭代周期的尝试

最新推荐文章于 2024-01-18 20:10:14 发布

卡萨巴

最新推荐文章于 2024-01-18 20:10:14 发布

阅读量1.1k

点赞数

分类专栏：敏捷实践

本文链接：https://blog.csdn.net/zhaoenweiex/article/details/88094602

版权

敏捷实践专栏收录该内容

19 篇文章 1 订阅

订阅专栏

前言

本文主要是记录并分享一次敏捷团队的改进过程以及如何面对和处理不太理想的改进措施。

背景

团队接触敏捷开发已经超过4年了。分为两个相对独立的两个项目团队管理，每个团队有相对成熟的技术负责人带队。

改进的提出

考虑到新年后的第一周，大家显然都无法进入状态，所以第一周就留给大家调整，而没有安排开发周期，最后一天我们还进行了某个领域的全年复盘，复盘具体内容就不提了，最后开发团队成员反馈，每周要花不少时间来准备给用户的进度汇报(周三)以及公司内部的项目进展汇报还有部门的班组报告（周五），表示严重侵占了开发团队的精力。
于是，提出改进计划将用户汇报，公司进展回报以及班组报告都调整到同一个时间节点（周三），这样就能节约大量的时间，该提议得到了大部分人的赞同，于是团队决定对新年后的第一个迭代周期的开始和结束时间进行调整，由原本的周一开始，周五结束调整到周四开始，周三结束，周期长度保持不变。由于没有相关经验，团队也让PO了解有一定的进度损失风险，同时强调这是一个尝试，可能最后还是要回滚。周一本不属于开发周期，但考虑工作的连贯性还是临时把本周期的开发计划会议临时提到了周一，因此第一周实际上是8天的开发周期，周一开始，下周三结束。

改进的执行

周一计划会议还是很梳理的，实际上跟没改进是一样的 - -！，开发计划也是安排了8天的工作量，问题出现在第二周。第二周的周一的站会发现进度明显低于预期，而且大部分人还没有意识到这个问题，仍然习惯性的认为周五是结束日期，经过提醒团队意识到这个问题，于是调整开发节奏，同时请PO进行剩余任务的优先级确认，以备无法完成。
进度到周三还是没有赶上，周三站会时测试人员表示虽然采用了新的模式还是由自动化测试无法跟上开发节奏（本来已经开发完了，但是由于前端周二修复了bug导致部分测试用例失败），造成的结果是到周三下午评审会议时自动化测试部分是无法运行的。虽然没有造成进度明显影响，但开发周期目标还是不能算是完成的。

回顾

评审会议结束后就开始进行回顾会议，首先针对本周期的情况，我们集中回顾了调整迭代周期起始时间的前后以及引起的变化，团队成员表示调整后确实在完成各种报告花费的时间减少了不少，但大家对于周三开始周四结束这个事还是很不适应，甚至开会时都表示感觉明天要放假了，周四周五的状态可想而知也好不到哪里去，周末也要想着工作的事情，也无法彻底休息，于是在最后的改进投票环节，开发周期回滚这个改进基本是全票通过。