说透敏捷
宋宁
IBM 资深敏捷教练
28764 人已学习
新⼈⾸单¥29
说透敏捷
15
15
1.0x
00:00/00:00
登录|注册

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

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

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

那么其他的团队该怎么使用试点团队的成功经验呢?是不是把它们直接复制过来就大功告成了呢?
在我做咨询的经历中,我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”,但其实这个说法只对了一半。
没错,我们是做了试点,试点中的经验教训也是可以拿来给后面的推广做参考,但如果直接复制未免有点简单粗暴。
举个例子。某个试点团队成功使用了 Scrum,于是领导一拍脑袋,也不管其他团队能不能吃得消,直接让所有团队一股脑儿在一个月内全部上马 Scrum。结果,有的团队导入 Scrum 比较顺利,而有的团队却遇到了很多困难。
其中,一个团队做的是运维类的项目,由于运维类项目开发的内容通常来自客户的建议或生产上的 Bug,比较零散,没有一定的规划性,所以对于他们来说使用 Scrum 并不合适,他们其实更适合使用看板;还有一个近百人的团队,产品本身比较大,团队拆分后有十几个小团队,只使用 Scrum 却没有解决好团队间的协同问题,效果同样不佳。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《说透敏捷》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • 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次,如果团队间的依赖开发有延迟,就会提前预警。

    20
  • 天天铛铛铛
    以项目”为中心的管理和以“产品”为中心的管理,有什么差异,各自侧重点是什么,还请老师指导下

    作者回复: 产品管理强调What,也就是做的什么产品。重点在需求管理,计划管理,发布管理。产品管理既关注产品的具体形式,也关注产品实现的过程,也要对最终使用产品的用户负责。 而项目管理强调How,怎么做,主要是任务管理,侧重的是如何实现这些需求。项目管理更关心达成项目目标实现的过程。

    1
  • Raymond吕
    想请教老师,规模化敏捷和项目集管理是否有相似之处?感觉从单项目敏捷到一些有联系的项目,相互作用共同产生价值,这点和项目集的理念有点相似。

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

    1
  • 姜华梁taric
    我们现在团队有四个敏捷小组,项目负责人 怎么去监控整个项目进度,老师有没有什么好的方法

    作者回复: 首先是这样,可以有在线工具管理起来,比方说Jira,每个小团队每天都会更新,所以进度都可以在工具上显示出来,只要登录在线工具,就可以看到进度情况;再者为了更好地管理风险,以及促进团队之间的协同,可以建立一个小组之间的沟通机制,隔几天让每个小组的负责人碰一下面,沟通一下依赖的进度情况,以及是否有风险等等。

  • Varphp
    感觉业务让开发人员之间协作 和他们自身业务理解透彻程度把控这块很难搞,这个痛点怎么解决才搞?老师

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

  • 吴言乱语
    举一个由我们小团队主导的项目 在业务需求沟通后,我们发现需要ABC三个技术部门同时协同完成,于是 1.在第一时间询问ABC三个团队的产品负责人,了解他们的项目排期,是否有时间支持。其中A团队表示他们在我们的计划时间内目前没有新需求导入,BC均表示已有安排。 2.将技术团队沟通结果反馈我们对接的业务部门,业务部门表示优先级很高,所以请业务中心统一协调BC团队的对应业务部门调整需求优先级。 3.达成一致后,由我方团队发送项目立项邮件,抄送ABC团队产品及业务负责人,约定立项会议召开时间。 4.会议宣讲项目需求,及所需配合事项及我们的各时间节点期望。 5.会议明确我方主导,ABC辅助,明确产品,开发,测试对接负责人,明确沟通交流机制,每天下午5:00-6:00为集中答疑时间;如有优先级更高的问题,反馈至产品负责人协调。 6.会议后,我方团队与A、B、C三方团队分别细致拆分技术方案,达成共识,并共同确定各时间节点。 7.将项目排期邮件抄送全项目组。 8.成立项目组线上沟通群。 9.项目顺利上线
    3
    36
  • escray
    在我的印象里面,敏捷一般只适用于小团队,规模化推广的时候最难的应该就是团队间的敏捷和沟通。不过,我还是认为敏捷开发多少有一点精英倾向,如果人员的素质达不到的话,最好还是放慢节奏,逐步推进。 通过定制度和反馈机制来试图解决业务敏捷的问题,我觉的也是难点。如果业务部门比较强势的话,那么想要把业务拉到 IT 团队的敏捷开发过程中,应该是一件比较困难的事情。 团队间的敏捷实践,需要大量而有效的沟通,这个也不容易,特别是每个团队有不同的利益诉求。 如果将来有机会换工作,那么我也希望能够进入一个采用敏捷开发的团队,同时我更倾向于小团队,而不是大组织。 如果我在一个大型的研发组织,想要做敏捷的规模化推广,我觉的也只能让那些有敏捷意愿的团队去试点并实施,对于一些比较排斥敏捷的部门,那就由他们自己去探索。即使高层领导想敏捷,而一线开发团队不想要,那么也不能强推。如果能把瀑布流做好,其实也没什么不好。当然,比较理想的是,在试点和早期采用敏捷的团队影响下,组织内的人员都能够意识到敏捷的益处,并且在敏捷的基础设施比较齐备的情况下,愿意尝试,有意转型。
    1
    3
  • Jason
    老师,我看到这里我还是不明白为什么不一开始就将所有的坑以及好的方法论告诉大家,而是让团队自己去试错,这样试错的不是会造成成本更高吗?站在巨人的肩膀上在进行迭代不是更好吗?
    3
    2
  • 梁中华
    我遇到过一个master把自己活成了项目管理,例外去协调,结果整个团队特别依赖他,他一走整个团队的工作就很被动,没人愿意主动协调我,推动了。请问这种情况怎么破?
    2
  • 行骏
    规模化推广之前,还是识别哪些业务或者团队是不适合敏捷研发的,不然会形成了无解反馈,容易造成以此举例的反响案例。
    1
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部