说透敏捷
宋宁
IBM资深敏捷教练
立即订阅
6218 人已学习
课程目录
已完结 12 讲
开篇词 (1讲)
开篇词 | 重识敏捷,让你的研发管理少走一些弯路
免费
原理篇 (2讲)
01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?
02 | 老生常谈:你真的知道敏捷到底是什么吗?
实战篇 (4讲)
03 | 评估诊断:成功迈出敏捷推进的第一步
04 | 团队试点(一):让你的敏捷实践“事半功倍”
05 | 团队试点(二):打造一支无往不胜的敏捷团队
06 | 规模化推广:复制粘贴试点的经验就够了吗?
策略篇 (2讲)
07 | 填坑指南:填好这4个坑,快速做对敏捷
08 | 避雷策略:如何防止你的敏捷变为“小瀑布”?
管理篇 (2讲)
09 | 内部教练:守护敏捷实践,求人不如求己
10 | 服务型领导:在敏捷中你该怎样提升自己的领导力?
结束语 (1讲)
结束语 | 用敏捷提升自己,从敏捷走向未来
说透敏捷
登录|注册

06 | 规模化推广:复制粘贴试点的经验就够了吗?

宋宁 2020-01-06
你好,我是宋宁。
在前两节课中我讲到了如何做团队敏捷试点,这节课我就给你说说如何把敏捷试点成功的经验做规模化推广。
团队敏捷试点不是目的,做试点是为了在我们的环境中探索敏捷实践的可行性,积累经验,若是确认敏捷在我们的环境中是好用的,我们就要根据试点结果,把试点过程中积累的成功方法推广到更多团队中。

规模化推广≠直接复制试点经验

那么其他的团队该怎么使用试点团队的成功经验呢?是不是把它们直接复制过来就大功告成了呢?
在做敏捷咨询的经历中,我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”,但其实这个说法只对了一半。
没错,我们是做了试点,试点中的经验教训也是可以拿来给后面推广做参考的,但如果直接复制未免有点简单粗暴。
举个例子。某个试点团队成功使用了 Scrum,于是领导一拍脑袋,也不管其他团队能不能吃得消,直接让所有团队一股脑儿在一个月内全部上马 Scrum。结果,有的团队导入 Scrum 比较顺利,而有的团队却遇到了很多困难。其中,一个团队做的是运维类的项目,由于运维类项目开发的内容通常来自客户的建议或生产上的 Bug,比较零散,没有一定的规划性,所以对于他们来说使用 Scrum 并不合适,他们其实更适合使用看板;还有一个近百人的团队,产品本身比较大,团队拆分后有十几个小团队,只使用 Scrum 却没有解决好团队间的协同,效果同样不佳。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《说透敏捷》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 吴言乱语
    举一个由我们小团队主导的项目
    在业务需求沟通后,我们发现需要ABC三个技术部门同时协同完成,于是
    1.在第一时间询问ABC三个团队的产品负责人,了解他们的项目排期,是否有时间支持。其中A团队表示他们在我们的计划时间内目前没有新需求导入,BC均表示已有安排。
    2.将技术团队沟通结果反馈我们对接的业务部门,业务部门表示优先级很高,所以请业务中心统一协调BC团队的对应业务部门调整需求优先级。
    3.达成一致后,由我方团队发送项目立项邮件,抄送ABC团队产品及业务负责人,约定立项会议召开时间。
    4.会议宣讲项目需求,及所需配合事项及我们的各时间节点期望。
    5.会议明确我方主导,ABC辅助,明确产品,开发,测试对接负责人,明确沟通交流机制,每天下午5:00-6:00为集中答疑时间;如有优先级更高的问题,反馈至产品负责人协调。
    6.会议后,我方团队与A、B、C三方团队分别细致拆分技术方案,达成共识,并共同确定各时间节点。
    7.将项目排期邮件抄送全项目组。
    8.成立项目组线上沟通群。
    9.项目顺利上线
    2020-01-07
    12
  • bentley
    请教,老师能讲一下针对问题3,制定的具体沟通策略、沟通机制吗?

    作者回复: 因为管理实践是后面一切具体技术实践的基础,基于篇幅原因,我在这里就只展开谈如何在管理实践上探索团队间的敏捷。具体到怎么做上,主要有下面几个方面。

     定义了一系列关于业务分析师的沟通策略和沟通机制,来在“做什么”上的目标对齐,即产品目标对齐。例如产品团队中,业务分析师每天有自己的站立会议,沟通各自的产品工作,这样来保证不同团队间的产品工作内容是可以协同的,既不会让目标分解后有产品内容落掉,也不会有做重复的;而到Scrum团队中,业务分析师会定期跟团队开需求梳理会议,也会有需求做完后的评审会议,平时也有跟团队成员的不定时沟通,例如沟通用户故事的内容和验收准则等。

    这是因为,在组织中,业务分析师在产品管理中起到了承上启下的作用。他承担了两部分工作,一个是在产品团队里,定期聚在一起来看各自的产品目标分解,来完善自己小团队需要做的产品细节内容,另一个是要到各自的Scrum团队去,给Scrum团队成员讲解需求细节等等,以便于团队能够正确理解需求细节并在此基础上正确实施。

     定期的产品集体计划会议,保证在“怎么做”上的目标对齐。在这个会议上,产品负责人来给大家宣讲未来两个月的产品目标,并简单介绍产品主要要完成的功能;各个业务分析师把各自团队需要的做的细化需求展示给他们各自的团队,该需求列表是排好优先级的;Scrum团队对需求条目进行粗略估算,估算完毕大家根据各自的产能来进行4个迭代的需求排步,在排布的过程中,识别各个团队之间的依赖;在做排布的过程中,各团队的Scrum Master要聚到一起来看依赖的情况,并一起做一张依赖关系表和依赖的开发安排。在会议结束的时候,大家一起制定了未来2个月的迭代计划,识别了各个团队之间的依赖,并在会议结束的时候将团队依赖做到看板上,以便后续管理依赖。
     
    我们的产品集体计划会议,类似于Safe的增量计划会(PI Planning),不过,我们没有做3个月长度的计划,而是缩短为2个月,因为团队还没有能力做更长时间的规划和预判。我们也没有全盘复制SaFe里的关于这个会议的全部内容,而是根据实际情况做了一些修改。例如我们没有选择集体澄清需求,而是在正式开这个会议的时间之前,让各个小团队自己先理解各个小团队的需求,这样我们整体会议就不需要2天的时间,而是缩短为1天。

     定期的团队的Scrum Master之间的Scrum of Scrum会议,来沟通大家各自的进展。只将团队间的依赖关系做到看板上,这是不够的,更多的还需要在开发过程中,及时地跟进依赖的开发进度。所以我们安排了定期的团队的Scrum Master之间的Scrum of Scrum会议来沟通大家各自的进展,这个会议一般在一周中安排2-3次,如果团队间的依赖开发有延迟,就会提前预警。

    2020-01-14
    4
  • escray
    在我的印象里面,敏捷一般只适用于小团队,规模化推广的时候最难的应该就是团队间的敏捷和沟通。不过,我还是认为敏捷开发多少有一点精英倾向,如果人员的素质达不到的话,最好还是放慢节奏,逐步推进。

    通过定制度和反馈机制来试图解决业务敏捷的问题,我觉的也是难点。如果业务部门比较强势的话,那么想要把业务拉到 IT 团队的敏捷开发过程中,应该是一件比较困难的事情。

    团队间的敏捷实践,需要大量而有效的沟通,这个也不容易,特别是每个团队有不同的利益诉求。

    如果将来有机会换工作,那么我也希望能够进入一个采用敏捷开发的团队,同时我更倾向于小团队,而不是大组织。

    如果我在一个大型的研发组织,想要做敏捷的规模化推广,我觉的也只能让那些有敏捷意愿的团队去试点并实施,对于一些比较排斥敏捷的部门,那就由他们自己去探索。即使高层领导想敏捷,而一线开发团队不想要,那么也不能强推。如果能把瀑布流做好,其实也没什么不好。当然,比较理想的是,在试点和早期采用敏捷的团队影响下,组织内的人员都能够意识到敏捷的益处,并且在敏捷的基础设施比较齐备的情况下,愿意尝试,有意转型。
    2020-01-15
    1
    2
  • Raymond吕
    想请教老师,规模化敏捷和项目集管理是否有相似之处?感觉从单项目敏捷到一些有联系的项目,相互作用共同产生价值,这点和项目集的理念有点相似。

    作者回复: 有些基本点是相似的,因为都要解决团队间的沟通问题等等。

    2020-01-09
    1
  • 咖啡
    我们公司有140的研发 有 6 7 个业务团队 我们团队直接经常英文业务这些不对齐 迭代不一样 出现问题
    2020-02-02
  • 镜花水月
    我们是500人的研发团队规模化敏捷,团队间的依赖主要在需求收集阶段识别出来并提给相关方。
    2020-01-28
  • Jeff.Smile
    今天学习有感:
    从小团队试点到团队之间协同,我相信通过敏捷教练或者专家的指导可以建立起来一套机制,但是我担忧这套机制如何长久维持,如何被监督执行下去?毕竟世界趋于不确定性(熵)
    2020-01-27
  • 小老鼠
    敏捷与DevOps关系?
    2020-01-15
  • enjoylearning
    没有规模化过
    2020-01-13
  • 李永智
    敏捷推广时确实是忽略了业务敏捷和团队间敏捷,造成项目落地效果不佳。当时为了让业务人员参与,确定每个业务有人员参与站立会议,但实际执行时业务人员参与度不高造成开发的预期有出入。团队间当时也安排定期回顾参与,但实际大家都是走了形式,造成团队间目标不一致,进而交付的东西业务团队不是很关心。
    2020-01-12
  • Varphp
    感觉业务让开发人员之间协作 和他们自身业务理解透彻程度把控这块很难搞,这个痛点怎么解决才搞?老师

    作者回复: 抱歉,这个问题我有点没搞明白,“和他们自身业务理解透彻程度把控这块很难搞”这个是指什么?

    2020-01-12
收起评论
11
返回
顶部