很值得回味的第一个冲刺

时间:2021-06-08 16:30:42

  做了这么长时间的敏捷开发,第一次对一个冲刺有这么刻骨铭心的印象。我想主要有以下几点造成的。第一,是有一个全新的团队,非常年轻几乎没有经历过任何正规化流程的人员构成的团队。第二,是*把很多基础性的工作拉进来还不得显性的列在backlog中。第三是,从需求到技术再到部署,都没有在一开始就定好准备好,都是随着时间在迭代。

  团队。和任何一个经验丰富的scrum master聊天,我想都会感觉到不是每个人都是和做敏捷的。敏捷对人的要求是很高。以前我自己在做传统过程的时候,通常的感觉是自己挖坑,然后再把萝卜往里面填。萝卜只负责在某一个坑里面默默成长;而做敏捷,是整个团队在挖坑,谁合适谁就主动跳进去填坑,长的不错了,再跳出来接着找一个合适的坑。做敏捷对沟通的时效性非常讲究,一个问题,你决定在什么时间点抛出来,如何选择最佳的沟通方式,邮件还是电话还是IM,都是判断。还有就是表达的准确性,如果一个问题你无法表达清楚,那么团队就无法帮你去解决,久而久之,你就会更习惯于自己去闷头解决。不知不觉形成了孤立。

  隐性任务。敏捷的burndown chat是非常有益的。因为敏捷的理念是只有时间固定的,那么应该将在某一时间内做的事情完全的可视化。这不仅是让所有项目干系人都清楚的认识到你在做什么,也让每件事情更易于管理。否则,每个冲刺积累下来的数据对以后的计划是无意义的。

  变化与迭代。我想选择敏捷就必须拥抱变化。如何在一个冲刺中管理好变化实在是太重要了。面对任何变化,任何外在的冲击,我想我们必须牢牢记住一个核心目标,那就是接收故事。我们需要开动脑筋认真分析,想出一个能在最短时间内完成任务的工作方式。比如说如果一些基础组件还在同步开发中,那我们就需要在日常开发中,锁定这些组件的版本,隔离其不稳定的部分,用各种假对象等方式作出必要的封装。对于需求的变化,也需要和PO认真讨论,看是否是即时修改还是可以放到以后再做。这里面都是大有学问的。我想,这不是文字可以说清楚的,是随着项目的推进经验的积累所带来的。玩敏捷真的是一个经验活。因为敏捷本身是没有方法学的。它只有几个核心概念,如何去理解全看个人。

   明天要开回顾会议了,我想每个人都一定有很多话要说。我很喜欢这种碰撞,因为这对我来说,可以更全面的了解敏捷在各种生态环境下的运行情况。