6从2019年6月份开始，团队开始进行敏捷转型，在此期间，团队主推了每日站会，看板使用和showcase三项工作。关于前两者，简单表述一下个人看法。
关于站会，团队规则的制定蛮重要。刚开始没有制定规则，部分小伙伴经常卡着点上班，经常有人迟到5-10分钟，关键信息需要重讲一遍，站会经常持续30分钟。后来，敏捷教练提出，需要建立明确的团队规则，对于迟到者，男生惩罚20个俯卧撑，女生惩罚20个深蹲，并发送到微信群。第二天开始，迟到者明显减少，持续一周后几乎没有，可以看出，制定明确的团队规则是有必要的。
关于站会，建议小伙伴们站会前对齐状态。有些小伙伴没有提前同步信息，例如开发反馈bug已修复，测试同事反馈不知情，开发同事说XX时候发过邮件，测试同事已经下班了。一方面，来回沟通浪费大家时间，另外，也没有起到同步信息的效果，会后还得双方确认，并将结果同步给其它同事。基于此，建议站会前小伙伴们对齐信息状态，会上只同步一下进展，风险与问题。
关于看板在项目中的使用，建议每个故事拆分成10人天以内的颗粒度。刚开始使用看板时，没有明确卡片上故事的工作量，要求小伙伴们将工作可视化，如实反馈团队实际工作即可。过了两周，观察发现部分卡片还在原来状态，询问项目是否存在风险，开发同事支支吾吾说没有，线下了解到一张卡片代表一个需求，项目周期为一个半月。开发时长预估20天，测试20天，其它准备投产工作。用户故事一两周内处于同一状态，无法向测试状态交付，测试同事处于等待状态，资源没有合理使用。作为管理者，希望通过看板了解项目，故事卡片一直停滞，不清楚项目进展，也无法判断项目是否错误风险。对于业务而言，需求从提出到上线需要45天，如果业务需要提前占领市场，需求迟迟无法交付，会影响业务收益，久而久之，业务会断定开发能力不足，信任度降低，业务满意度也不尽人意。为积极响应业务需求，建立良好的互动关系，建议项目经理将需求拆小，优先实现重要功能，分批次交付投产，同样，看板故事拆分到10人天以内的颗粒度，用于团队项目管理。
网友评论