【sprint总结】sprint11-20周期总结

快来打我* 2022-10-15 13:56 143阅读 0赞

时间过得真的好快，转眼间敏捷开发10个sprint周期结束了，从开始的组员到后面的打怪升级到组长，虽然这个组长当得突如其来，从天而降，猝不及防，不过这段经历真的可以称得上是坎坎坷坷，饱经风霜，历经坎坷，历尽苦难，千难万险，含辛茹苦，艰苦卓绝，栉风沐雨，悲欢离合，荣辱浮沉，大起大落，千辛万苦，跋山涉水，翻山越岭，饱经风霜，爬山涉水，千里迢迢，凤凰般涅，起死回生，痛不欲生。。。。。。可以写进个人自传。。。。。。

先来说下在我接手组长职位之前，我是属于不积极主动的那种，各种事情都是听从安排，组长说做什么就做什么，指哪打哪，还可能存在打的不准的状态，，，不会主动去关注其他人的状态，比如说做的什么功能，做到什么程度，有没有遇到什么问题之类的，或者对于整个组来说，任务进行到什么程度，现在项目进展到什么阶段等等

So，当我知道我要接任组长的那一刻，我整个人感觉遭到了五雷轰顶，裂开了，因为以前的不主动，不积极，不了解，导致现在接手手忙脚乱，猝不及防，完全无从下手，无计可施，还好上一任的组长大人就坐在我的旁边，可以随时请教，在此，不点名感激一下上任组长的耐心，细心，解答我的各种奇怪，小到鸡毛蒜皮的小问题。有了上一任组长在旁边的加持，我慌张的心渐渐平稳了一点，暂时可以先把我缝上。不过，俗话说，理想很丰满，现实很骨感，由于我的经验不足，独断专行，导致我带的第一个周期因为任务分配的不具体，不明确，不详细，不均衡，遇到问题处理的也不好，导致项目没有按时完成，没有能够按时验收，被扣了分；第二个周期，汲取上个周期失败的经验，这次的安排听从了大家的各方建议，也进行了任务时长估算，但是最后却因为产品设计的问题要进行紧急修复，最后经过讨论，后端实现可能也不太符合用户需求，最后导致要整体重构；第三个周期，终于终于，验收通过了，但是超时了，继续扣分；现在是第四个周期了，我觉得应该可以吧。。。

经过这三个周期的跌跌撞撞，除了埋怨，更多的是收获：

首先，是关于敏捷开发：

首先，敏捷开发是相对于瀑布模型提出的。

瀑布开发模式的项目周期往往比较长，一般为3-6个月，甚至更长时间，当项目开发完成后，最后交付成果如果不是产品经理或是客户真正想要的，最后只能重新从项目的需求开始，经过一系列的构建、测试、部署等过程，那样的话，项目周期就会更长，不可控的因素和风险很大，最终会偏离最初想法。

而敏捷开发周期很短，一般为2-6周，它将瀑布开发过程切分为多个短的迭代式的增量开发过程。每一个迭代结束，都会产生最终可用的产品，如果需求有变化，可以在下一个迭代周期进行开发，基本不会出现最终交付产品是用户无法接受的，即使要浪费时间的话，最多就是一个迭代周期的时间。

敏捷开发过程：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlamluZ2ZhbmcxMjM_size_16_color_FFFFFF_t_70][]

敏捷开发过程详解：

一， 产品负责人建立条目化的产品待开发项，并进行优先级排序。这个我们可以在上一个sprint的复盘会时和小组人员共同确定，项目组长可以提前准备几个条目，如果没有，可以找产品或测试来提出，会上确定具体要做的开发项，，每个小组成员进行认领并预估时间，如果无法预估，大家可以一起帮助他用扑克牌算法进行估计。

二，在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代

三，团队在迭代内完成所列需求，每天都开每日“立”会以沟通进度和问题。在迭代期内进行每日“立”会，询问每个组员昨天任务的完成情况，和今天的任务安排，还有遇到的问题，这样不仅能清楚地知道自己昨天干了什么，也清楚了今天需要做什么，如果有问题，还方便大家集思广益。也方便组长确认组员任务完成情况，不会出现马上要验收，结果某个人那里好多工作没有做完影响整体的情况

四，在迭代终点的迭代评审会上，团队向产品负责人等展示开发成果。

五，还有一个重要的过程--复盘会，也可以成为反思会，在每个迭代周期结束后召开，总结一下这个周期中哪里做得好，哪里做得不好，好的延续，坏的改进，有什么改进计划，提出解决方案。然后复盘会还有一个任务就是上面提到的确认下一个周期的待开发项。

然后，是关于各种审批：

首先，是sprint开始审批，发送该审批前，我们需要确定本次sprint开发任务和计划，有了计划才能让我们有条不紊的执行嘛，然后就是需要关联我们的上一个sprint的验收审批，上一个周期结束紧接着下一个周期的开始

接下来，是测试审批，测试审批之前，我们已经确保完成了本次sprint周期的计划并进行了自测，完成了测试文档的编写，测试审批关联开始审批。测试组进行测试，提bug，我们解决bug并回测，直到没有bug

下面是生产发版审批，在解决了bug测试组通过之后才能进行发版审批，生产发版之后，因为更改了环境，所以我们还要进行测试，确保没有问题

最后是验收审批，发版后测试没有问题进行验收。

很关键一点是要注意各个审批的时间，我这个糊涂蛋就没搞清楚时间节点，导致延迟的发送审批的时间，因此，深刻反思之后总结了该图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlamluZ2ZhbmcxMjM_size_16_color_FFFFFF_t_70 1][]

最后，是当组长这几个sprint耳濡目染其他组的一些经验：

1.  本组内的产品、架构、运维可以隔一段时间就抽签换一次，大家都了解一下每个职责下做什么
2.  各种审批可以分配下去，大家轮流来发，每个人都深刻认识一下各个流程及时间节点，不要像我一样，到时候手忙脚乱
3.  组长轮流制

总之，这10个sprint周期收获满满，虽然还有些地方会出错，但是也在不断进步中，我可以做的更好，奥利给！！！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlamluZ2ZhbmcxMjM_size_16_color_FFFFFF_t_70]: /images/20221014/7b27e9e48ac34f0a9d00f422105c9a59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlamluZ2ZhbmcxMjM_size_16_color_FFFFFF_t_70 1]: /images/20221014/f3e2533e17804d9b9df115a9bc782526.png