敏捷转型历程 - Sprint3 回顾会

我: Tech Leader

团队：团队成员分布在两个城市，我所在的城市包括我有4个成员，另外一个城市包括SM有7个成员。另外由于我们的BA离职了，我暂代IT 的PO 职位.PM和我在一个城市，但他不参于敏捷的运作里面.

迭代: 双周

主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.

现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3开始，外部教练基本上没有看我们的状况，由我指导着团队和远程的SM进行敏捷活动。

－－－－－－－－－－－－－－－－－－－－－－－－－以上是基本背景－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

周五公司有很多培训讲座的，有同事提出回顾会要不要推迟开，但由于昨天演示会的不成功，我还是坚持要开这个回顾会。

参加者：Scrum团队所有成员

开始时间: 3:30 PM

持续时间: 3 hours

主持: 远程的Scrum Master

步骤一：宣读敏捷宣言， 这次由广州的一位不怎么交流的同事读，半推半就，后来还是坚持读了。(明天回去问一下他的感受)

步骤二：Scrum Master总结一下这次Sprint，巴拉巴拉的说了一通，总的来说，讲好的居多，可能报告做多了，出口都是积极性的东西。我由于对此次Sprint不满意，个人还是感觉这个总结不是很到位的，在广州的几位同事也和我一样的感觉。

步骤三：一如既往，这个环节还是很受团队欢迎，大家都表现得非常积极，两个城市的成员都有互相感谢的。这里我重点讲三位同事，一位是QA，他是获得最多认同的，我们的QA尽管每天都会抓同事的bug,还天天催成员们提交代码，从角色上来说，可以说QA和开发人员是对立的，但他还是获得了多位同事的认可的，可见，团队的气氛还是融洽的；另一位是远程的另外一位开发人员，也是我感谢的其中一位，他是唯一一位在写完自己代码后继续写junit test的成员，而且前一天晚上还加班准备这周末的部署上线，虽然后来我们取消了这次上线（周五早上收到高层的邮件取消这次上线，原因是此次的项目改动对业务没有很大关系），他的责任心，承诺，质量，态度都体现了出来；另外一位是上周日回到公司加班解决一个关于导出excel乱码的问题的同事，由于这个UAT的bug已经持续了7天了，我也是下命令在周一前解决掉，所以他周日回公司加班了，他的承诺和责任心也体现了出来，但由于这个bug拖了这么久，我没有选择这位同事，在这里我感谢一下他吧。

最后我观察一下，在最近两个sprint里，我身边的同事都没有互相感谢的，在第一个sprint里有，不过那时我出差到了远程的城市去了，没有看到，希望下次sprint我可以看到本地的成员有互相感谢的情景。

再说一次，感谢环节里，感谢的两个人在致感谢辞时要四目相对，并握手，最后拥抱结束。

步骤四：团队成员每个人思考10分钟，总结一下这次sprint，然后以写纸条的形式，分成两部分，一部分写团队做得好的地方，一部分写做得不好，需改进的地方，但写的纸条必须是具体的事例，不要写抽象性的东西，例如，　写我们这周开始有了代码审查，而不要写我们的质量提高了。代码审查是具体的一项活动，而质量提高了，则很难表述清楚怎么样提高了，具体体现在哪里。

写出来的纸条还是和大家预料的一样，有问题的地方，需改进的纸条占了大多数，这方面还是体现了我们团队还是敞开心菲，敢于大胆说出来的。

写完之后，我们每一条都过一遍，谁写的谁解释，然后进行归类，我们归出来7个分类，分别是团队反馈，流程规则，管理，技术设计，需求评估，计划，沟通，最后每个人对分类进行投票，

然后我们针对前三个分类进行总结并提出改进计划，我们的前三是技术设计，计划和沟通。

关于技术设计，从一开始阶段，我们确实没有怎么做系统设计，由于我们做的系统也比较简单，所以远程SM和我都没有重视这一块。远程SM有10几年的java经验，普通架构师级别问题不大，我8,9年java经验，系统设计也没问题，就我们俩有能力干这事，我们俩都是大忙人，所以忽视了，这次团队提出来，我们俩个也很同意去改进，改进的方案是重新review一下代码的包结构，api的设计，前端的封装，因为我们俩都没写代码，所以我们决定采取pair的形式展开，并且创建一些技术story，宁愿牺牲一下进度（其实我们项目也没进度压力，都是我自己想出来的）。

计划，这方面我觉得主要是在做计划的时候，没有考虑到还没有完成上一个sprint的story,导致团队成员评估过于乐观，而且由于没有做好设计这一块，团队成员在赶story的时候比较急，急于完成功能模块，忽视了代码质量，做起来更加不顺畅，还有就是SM没有将团队完成的东西可视化出来，比如应该将成员做上一个sprint的工作量可视化出来，这样大家就可以知道团队没有完成这个sprint的东西是因为有一些时间是在赶上一个sprint的东西。改进方案，完善可视化，粗暴的将评估放大1.5倍，为设计预留时间。

沟通，这个是团队投票最多的一块，技术人员不善沟通在这里很好的体现出来了，明明需求写得不清晰，就是没有人提问，真急死人。我个人提出强制性解决办法，对于简单的story，个人解决，对于复杂一点的story,实行结对编程。在提出结对方案时，当时团队还投过票，50%赞成，但我还是强制要求试一下，因为我个人还是认为结对能解决沟通的问题，当然我们可能会牺牲一点速率，但是否真的会牺牲速率，未知，我希望尝试一下，第二，结对以后，质量会提高，在这一点上，团队都一致这样认为。

最后总结一下，在第3个sprint里，可以说我们开始遇到了敏捷普遍可能会遇到的问题，

1. 没有文档了，不用设计了，或者是设计的问题怎么做？

我们确实没有做很详细的设计，但我们在第1个sprint是有搭建框架的，但功能的设计确实没有做，我们交给了团队成员去做，我们的团队成员大多数是三年经验以下的，1个毕业两年，2个今年毕业，1个去年毕业，这样的团队搭配不是很合理，我们的解决方案是，一要给设计预留时间，二是对于初级工程师来说，实行结对的方式来进行，让高级的和初级的结对，三是对于复杂一点的设计要进行review。

2. 上一个sprint的story完不了怎么办？下一个sprint的工作量可以减少吗？

这个问题其实不可以简单的回答可以还是不可以，要看具体情况，我觉得对于这样的情况，我们应该可视化出来，有一个报表可以体现团队完成的story point,否则PO或者PM只会一味的埋怨。

我的看法还是能做多少算多少，但一定要可视化出来。

 

好吧，就写到这里吧，下周要实行结对了，看看我们的情况吧。