一次敏捷Retro的会议记录
|
为什么要将这次敏捷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 (文／张松然) ©著作权归作者所有 |
