敏捷转型历程(1)

我: Tech Leader

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

迭代: 双周

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

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

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

今天的早会一如既往的开了有半个小时到四十分钟， 说真的，早会真的太长了，有几个问题，一是我们的看板上的Story太多了，二是大家是按Story说的，不是按人说的，导致一个人可能会说几次, 三是现在团队问题不少，在早会上可能针对问题点多说一点， 四是我们团队的人数的确有点多，再加上教练有时会提点一下，相当于12个人的团队。

说说今天的变化，其实我们应该先联想一下昨天，昨天是星期四，按例，迭代的第二周的周四，我们会举行 show case(就是所谓的review meeting), 昨天的show case包括早会进行了一个小时，结果非常不成功，有没有提交代码的（原因是周三环境问题，说怕提交代码后弄坏环境，影响第二天的show case）， 有演示时出现严重bug的（从演示的现场来看，根本开发人员就没有自己好好测试过，测试人员工作忙，还没来得及测试这个story）， 有说需求不明确的（都到演示会了，这个时候才说需求不明确，早干嘛去了），总之一大堆的问题，非常的失败，教练和我对团队的表演非常失望，当时在会上也表达了强烈的不满（当然我们两个有料到这个演示会一定不成功，但没想到这么不成功），由于第二天有retrospective meeting,我们决定show case 的总结放在retro meeting上说。今天的情况看起来好了一些，团队成员比之前努力了，我可以感觉到他们比以前更紧张了，（我是每天都非常非常忙的那一种，他们有问题也不容易找到我来问，当然，我会挤出时间来回信息或者回邮件，但通过电话或内部即时通讯能立马回答他们，还是比较难的，以后会讲述为什么我会如此的忙，当然可能我的工作方法或者效率有问题）今天下午两点钟，本来我是要整理下个sprint的需求，准备回顾会议等等之类的东西，我立马被一个团队成员抓住了，说他们有需求疑问，要拉上几个人和我一起搞清楚需求先，我二话不说，立马同意了，于是我们就开了半小时的会，电话里，他们问的问题比以前更仔细了，态度比以前更认真了。

好，开始说retro吧， 三点开 retro(我不是订了四点到六点吗),那个说很难订会议室，就订了三点开始，好，那就三点开始吧。

1. 读敏捷宣言，这个还是蛮振奋人心的，大家对这个还是给予热烈鼓掌，今天是SM读，我个人比较倾向于团队成员读，算了，反正是轮读的，下次就换一个。

2. Sprint总结， 我的总结能力还是有待提高呀，我说的不是很顺，下次我应该提前准备一下的。说了些好的地方和不足的地方。

3. 感谢环节， 由于是第一次发，就说一下我们的做法吧，做法就是团队的每一个成员挑选其中的一位在这个sprint里面对其帮助最大的成员进行感谢，表达时，两个成员四目相对，感谢的一方致辞，另一方在看着，表达完后，两人握手，并拥抱，至此，感谢结束。

这个是retro最令人开心的一个环节，由于公司的保密原因，就不发图片了。在这个环节里，两个城市的团队成员都非常活跃的气氛，我们是用视频会议开的 retro,所以尽管是异地团队，但我们还是做到面对面的开retro的。团队有一位成员是比较少说话的，技术不错，在上一次感谢环节里，他没有成员要感谢，但今天，他有感谢的人了，令我有些意外，同时也验证着我们的改进是有效的，我们的改进方案是让另外一位成员和这位不喜欢交谈的成员一起做story或者让他们的工作更有交流性，这样达到交流的目的。但今天，又有一位成员感觉自己很孤独，没有要感谢的人，看来，下个sprint在挑story的时候，我们得留意一下这方面了，尽量不要让团队成员单打独斗。

4. 总结， 团队每个成员拿post-tip写上在这个sprint里面，我们做得好的地方，和要改进的地方，时间8分钟，写完后，SM将tips贴在墙上，并进行分类，分类后每一下都过一遍，然后让大家对tip上的分类进行投票，每个人投三票，对前三票的进行讨论，并得出改进的action,记录下来，并做为改进项进行追踪。

说真的，今天的讨论进行得比较激烈，教练和我都对show case和产出质量差投票，但团队比较倾向于敏捷流程（会太多）和需求不清晰进行投票。

会上有成员提出如果团队觉得不满意的话，能不能推迟演示会，教练很强烈的表达了不能推迟的做法，当然我也很支持不能推迟，我们给出的方案是，有10个story,做完了5个就演示5个，而不是说推迟演示，因为推迟的话会导致团队不注重承诺完成率，而且这样会养成一个习惯，久而久之，演示会就会变成不开了，开不成了，或者是开了也没有意义，反正不完成也不怕。

对于需求不清晰的问题，我们给出的方案是，在sprint planning meeting 之前，我们会开一个grooming的会议，而且这两个会至少隔一天，也就是说，开完grooming后，成员有一天时间去想一想需求的问题，当然，这个一天并不是所有成员停下来就专想这个事情，这个是要和工作并行进行的，等到开sprint planning的时候，我们再回答有关需求的问题，同时在开早会的时候，也要尽量暴露出问题，再就是平时可以选一个时间点，大家一起讨论需求。

对于show case 和质量差的问题，我们在会上给出了 Definition of Show Case, 就是

 1) 一定要在SIT环境上面 show case

 2) 一定要经过测试才可以show case

 3) Junit class 覆盖率要达到50%, 我们对新代码执行不定期抽查，因为确实没有工具可以检测出来

 4) Sonar上面的report不能出现 blocker 和 critical

 5) 不能有严重的bug, 这个没有定义严重的标准，靠人为判断了。

 

总算开完了一次retro了，出完这个show case标准后，相信大家不会再这么随意了，看看以后的情况吧，两点多了，睡觉吧。