一次敏捷Retro的会议记录
您目前处于:敏捷  2017年11月23日

为什么要将这次敏捷Retro会议记录拿出来说说呢?因为发现,这次会议的内容真的反映出大多数团队面临的问题和痛点,并经过这么多年的敏捷实践,真的有所思有所悟,所以用这一次敏捷Retro来说说问题。


背景

刚刚团队经历过一个项目,这个项目的结果是成功的,但是整个过程是非常痛苦的。

这个项目的特点非常显明:

1. Deadline已经固定,而且非常紧

2. 多个团队协作开发,沟通成本非常高

3. 团队新人多,对业务不熟悉

4. 系统腐化严重,代码混乱

由此产生的问题:

1. 新人很努力,但对系统不熟悉,对业务不熟悉,干着急,帮不上忙,很无助

2. 一线研发很辛苦,没有足够的backup,今天晚上熬完,明天晚上继续熬,精神和肉体都面临极大挑战,时刻处于崩溃的边缘,很无助

其实你可能会说一次、二次面临突发情况,加班加点搞下,是无可厚非的。但是我想说的是,某些业务线,尤其是业务强主导的业务线,突发情况已经是家常便饭了,因为这是其最大的特性。我现在面临的就是这样的场景。

我们是无法改变这个特性的,无论是否使用敏捷。我们要改变的是,一次比一次改变应该更加的迅捷,从每次痛苦中获得成长,通过不断自省进行自我改进。


敏捷模式

我们最早使用的Scrum模式,有计划会议、站会、演示和回顾会,但是这种时间盒的模式,会在Sprint限定Story,所以后期变成了ScrumBan,取消了计划会议、演示和规划会,这种模式更适合价值流的推动。

随着团队的变大,采用了SOS模式,拆分了目标团队,并为了责任到人,在团队内指派专人跟进专门业务。


敏捷走样

走样1:由于实施了责任到人,专人负责专门业务,但是造成了一些固步自封的人,只了解自己这块的业务,不去了解别人的业务,也不让别人了解自己的业务。

走样2:由于敏捷推崇高效沟通,但ScrumBan没有了计划会议,所以团队接需求比较乱,没有整体规划就接了需求,这也侧面加重了越没时间越敢需求,越敢需求越没时间。


敏捷决议

所以,在敏捷Retro上,我们通过对上述问题的分析,进行了总结,并进行了一些决议改变。

1. 切回Scrum模式,并轻量化,重点是要有计划会议、演示和回顾会议。需求一律从计划发布会产生,临时需求只对接研发负责人。

2. 线上问题和BUG一律汇总到测试,优先进行线上验证,确认后提BUG处理。(严厉禁止产品、运营谁谁谁发现一个问题或BUG,就直接找到某位研发处理。这种方式不仅影响了正常任务的研发进度,造成研发风险,还会造成问题不同步)

3. 专人负责QQ群和咚咚群,整理问题列表并跟进,是问题或BUG的汇总到测试,是需求和功能优化的汇总的产品。

4. 团队每个人要深挖自己负责的业务,同时也要充分了解其他人的业务。每个人都是团队Backup,当出现突发事件时,所有人都能聚焦在一个点上,每个人都能发挥出自己的力量。

5. 树立团队痛点驱动文化,每个人要积极主动了解产品全貌,你要想了解别人负责的事情,你就应该主动去问,不要当大爷还等着别人给你讲,你不了解是你的问题,不是别人的问题。

6. SCM一定要起到作用,推动团队内部的技术分享和交流,打破业务技术壁垒,坚决杜绝围城现象,陷入业务的人成为单点出不来,外面的人干跺脚进不去。


SCM的问题

1. 团队交流沟通出现壁垒,每个人只了解自己负责的业务,没有即时沟通和内部交流,总以加班时间太紧为借口,不解决问题,这是SCM的问题

2. 需求混乱,没有收口,放任团队随意接纳需求,自己总处于一线的业务紧张研发工作中,没有时间协调团队问题,帮助团队排除阻碍,这是SCM的问题


SCM的职责

做好各方沟通纽带,帮助团队排除阻碍。

解释:阻碍包括需求不明确时,联系产品确认阐述。技术架构有问题,进行技术问题排雷。项目进度风险预警,迅速升级解决问题。等等。


总结

这次的Retro还是感悟很多,总结就是:打破业务技术壁垒,坚决杜绝围城现象。只有这样,在每次风起云涌之时,所有人都能帮上忙出把力,大家会拧成一根绳,团队的凝聚力才会愈加强大。这里SCM要充分发挥作用,做好各方沟通纽带,帮助团队排除阻碍。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)