SM敏捷实践经验总结

部门开展敏捷已经三年有余,我是作为最早一批敏捷实践者,曾经也连续当了两年的SM。期间部门组织过大量的敏捷培训,也专门学习出差到各地的敏捷会议,看了不少相关书籍,对敏捷内容不说熟练,但也是相对比较了解的。也正是因为这场轰轰烈烈的敏捷让我开阔了眼界,增长了格局,影响了我的方方面面。虽然现在已转做BA,在整理资料时t突然发现两年前的敏捷经验总结,呵呵,都不记得是在什么情况下写的,但现在看看还是颇感意外,遂记录之。当然这里仅记录我担SM期间的感悟,对于其他的一些敏捷实践如需求实例化、MFQ、CI、单元测试等后面有机会再具体文章阐述。
一、SCRUM运作
不懂敏捷的人一般认为敏捷就是指四会,虽然不正确,但也恰恰说明四会对敏捷的重要性,而SM就是保证四会按时正常举行的关键人物。
1、计划会:BA需要提前准备好方案、原型设计和接口文档,在会上仅将关键要点陈述清楚,保证方案的可行性。计划会SM需要控制住时间,尽量在2个小时以内,否则人容易分散精力。对于故事估点和迭代故事承诺时间,其实经过团队成员几个迭代尝试可以慢慢量化成模型,比如我们团队承诺故事点数 = 迭代工作日剩余天数*迭代参与人员数*70%。
2、早会:需要制定规则,比如不能迟到等,而且会上要尽量少讲技术细节,多讲困难点,否则早会时间会不断拉长,形成习惯后就很难改变,然后就被认为浪费时间,也就会慢慢被嫌弃。
3、评审会:最好由相关开发人员来演示自己对应模块,将重点难点说清楚,有疑问的地方提出来,这样其他未参与的团队成员也能有针对性的给出建议和答疑。
4、回顾会:这个最好弄的轻松愉悦点,比如买点水果瓜子类的,可以先回顾下团队年度或半年目标的达成情况以及上个迭代的改进跟踪情况,然后让团队成员谈谈对本迭代的一些想法、改进点以及心情曲线。若团队有不擅长表达的,可以让大家用纸写下分享,然后讨论出重点问题的改进措施,设定相应的跟踪人,保证能正常的被实施。
二、团队建设
对于SM来说,团队建设是其关键职责,一些相关的举措会直接关系到团队对问题的重视程度和执行的效果。可以说SM就是一个团队的灵魂人物所在,SM雷厉风行,那么团队也差不到哪里去,如果SM吊儿郎当,那么团队也极有可能一盘散沙。
1、制度和流程很重要。其实制度和流程是一把双刃剑,如果涉及很多,会导致效率降低,团队成员反感,如果没有制度,又会没有边界,当出现问题时,团队可能会责怪没有提醒,所以在团队成立初期,对于一些大的原则和流程需要明确,当项目有新的规定和要求时,要实时的通知到团队,避免团队犯一些低级错误,对于特别重要的,需要不断提醒,让其深入到大家的心中。
2、职责要明确、做事有条理。虽然敏捷讲究主动承担任务,打破壁垒,但是在开始一个新故事时,对于职责分工还是要明确清晰,这样更利于协作,让大家更有责任感,不至于考虑哪个工作更轻松等影响开发效率,保证做事有条理不混乱。
3、各斯其职。目前SM大都是技术出生,如果将团队的方案、技术都囊括的话,那将是个大忙人,会顾此失彼,因此在与BA协作时,尽量要求BA做好他该做的事情,对于一些方案的讨论和确定也尽量让BA拍板确定。SM的职责是尽量服务于团队,保证他们需要的资源能够协调到位,保证团队工作的质量和进度,提升团队的凝聚力。
4、充分授权。人都有一个通病,总担心别人会不会捅出篓子出来,甚至什么事情都想亲力亲为。而我们现在提倡自组织团队,就要首先充分相信每一个人都能将事情做好,需要做的就是调动他们的积极性。
三、团队目标
一个好的团队需要有一个统一的目标,才能将人心凝聚起来,从而达到1+1>2的效果。
1、团队一定要有目标,若只埋头苦干,就很难看到团队的成果产出,看不到特色亮点,无论对于团队评优还是团队士气都是很大的打击,大家会觉得没有成就感。
2、团队目标最好每半年出一个,季度时间太短,频繁调整,容易耗时太多,年度又太长,定义目标无法预估未来变化。
3、目标一定要遵循SMART原则,必须是具体,可量化的,全团队认可达成一致的。
4、目标最好每个迭代末期在团队内进行定期回顾总结,及时调整,以免跑偏方向。
四、沟通协调
协调资源,内联外通也属于SM的一个重要职责,特别是对于大公司,这种异地办公、共同开发统一模块的协调更是难上加难,办法很多种,但需要具体问题具体分析,这里大致列举实践中的心得:
1、迭代任务开启前,确定好团队之间、模块之间的接口。
2、如果做Web开发任务,需要在迭代任务开启前,通过Axure Prototype制作好Web原型图。
3、迭代任务开启前,尽早确立联调时间,可有效的安排自己的时间。
4、联调开始前,通过发送联调日报汇报当前联调进度和效果。
5、如果团队之间碰到疑惑,需要讨论,按照效率由高到低的沟通方式有:电话、IM消息、邮件。本地联调,最好面对面沟通,异地联调,打电话沟通最快,IM其次,邮件最慢。
6、团队站会时,将沟通中碰到的问题汇总起来,然后找个合适的时间与对方团队最好电话会议一下,确定问题的解决方法。
7、讨论过后的变更,需要有图或文字为证,时间久了可以拿出来当做证明。
8、复杂业务,同时协调多个团队时,需要根据完整性、高效性、一致性等多方面考虑,减少交互,配置简化。

原创文章 33 获赞 6 访问量 2万+

猜你喜欢

转载自blog.csdn.net/lanyue1/article/details/88043509