精华内容
下载资源
问答
  • 导读 腾讯到底是怎么进行敏捷研发和极速产品交付的呢?腾讯研发管理部高级产品经理、敏捷教练张贺,受邀在DevOpsDays深圳站中进行了相关分享。他从“道、法、术、器”四...

     导读 


    腾讯到底是怎么进行敏捷研发和极速产品交付的呢?


    腾讯研发管理部高级产品经理、敏捷教练张贺,受邀在DevOpsDays深圳站中进行了相关分享。


    他从“道、法、术、器”四个方面揭秘了腾讯当年面对研发方面挑战时的破局之道,并结合实践介绍了腾讯的三种研发模型及典型案例。


    快来一起看看吧~


    大家好!


    首先做一下自我介绍,我叫张贺,来自腾讯研发管理部,目前主要负责腾讯敏捷研发体系和敏捷研发平台TAPD的建设工作,同时我个人也是一名敏捷教练,指导了腾讯内部很多业务团队的敏捷实施,也帮助了许多腾讯合作企业完成了研发转型和敏捷落地。


    640?wx_fmt=jpeg


    大家都知道,在腾讯的发展历程中孵化了众多的优秀产品,QQ、微信、视频、音乐等等都服务在我们的生活当中。


    这些产品背后,有着不同规模、不同成熟度的产品研发团队在进行着持续创新。那么支撑这些创新的研发体系是怎样的?腾讯的产品研发过程有哪些特色?


    今天我会和大家聊一聊,企业在产品研发过程中面临的各种挑战,以及腾讯是如何解决这背后的问题,并与大家一起探讨企业数字化敏捷转型,怎样更快更好地落地。


    640?wx_fmt=gif


     

    困惑到破局


     企业研发面临的敏捷挑战 


    在腾讯的这么多年里,我见证了众多业务的孵化,参与了许多研发团队从组建、成长到成熟的过程,尽管业务领域各有不同,但是研发团队所面临的问题却有很多相似之处,其中最为普遍的一点,就是随着业务扩展、技术栈的更新、团队规模的增长,研发模式怎样随团队一起升级。


    不知道在座的各位,有没有遇到过下面这些情况。比如因为人员变多带来的信息逐层衰减,导致团队沟通效率降低。因为风险没有及时同步,造成的版本不能按时交付,从而影响到业务的整体推广计划。这些都是摆在团队面前实实在在的挑战。


    640?wx_fmt=gif


    具体到腾讯的情况来看,目前腾讯有超过2W的产品研发人员,业务覆盖社交、广告、金融、娱乐等数十个行业,超过400款产品,每月有数千个项目在持续运转。


    640?wx_fmt=gif


    在这些数据的背后,不同的业务场景下,他们的研发模式有什么差异;流程管理怎样做到自适应和定制化?


    如果团队内部存在多元的技术栈,那么研发效能如何度量和改善呢?


    这里和大家分享一下腾讯的破局之道。

     

    十年磨一剑


     腾讯敏捷研发体系 


    首先,给大家介绍下腾讯敏捷研发体系。这个体系是怎样的一套框架呢?在腾讯内部,我们把它概括为:道法术器四个方面。


    所谓,是指腾讯研发的核心思想和理念;所谓,是指腾讯研发文化和组织则包含了腾讯研发体系的最佳实践,则是承载这些思想和实践的平台


    640?wx_fmt=gif


    敏捷思想是腾讯产品研发的核心理念。说到腾讯敏捷的起源,时间要回到2006年,当时的腾讯的联合创始人,前CTO张志东先生,前往美国与Google、Yahoo等公司进行交流,并将敏捷思想带回腾讯,十二年来,敏捷在腾讯落地、生根、发芽,并沉淀为了这样一套成熟的敏捷思想——以用户价值为依归,敏捷迭代,小步快跑,鼓励用户参与,持续交付和灰度验证。


    640?wx_fmt=gif


    仅仅有思想还不够,在腾讯,我们打造了一系列的敏捷培训课程,进行了四百多场的敏捷培训,组建了敏捷教练团队,来指导业务团队的敏捷实施,同时在公司内组织了线上和线下敏捷实践交流,去帮助团队进行敏捷的经验交流和分享,营造敏捷氛围。


    640?wx_fmt=gif


    组织结构方面,腾讯在职能组织的基础之上,引入Feature Team。Feature Team是一种按照敏捷的交付模式,以用户为中心,按照用户场景作为边界来组织团队的做法,是业务的最小作战单元


    640?wx_fmt=gif


    有了思想、文化和组织,就到了实践环节。


    在实践方面,腾讯的敏捷有两部分构成,项目管理实践和研发工程实践。项目管理实践提炼并融合了Scrum、XP、FDD等主流的敏捷研发思想;研发工程实践,则是从研发、交付等视角,持续进行CI、CD的建设。之所以将项目管理与工程管理并称为腾讯敏捷,是因为他们有一个共同的目标——快速高质量地交付用户价值


    640?wx_fmt=gif


    说到工具,正所谓“工欲善其事,必先利其器”,基于腾讯的敏捷实践的落地需要,我们从06年开始,打造了高化”的腾讯敏捷研发工具平台——TAPD


    640?wx_fmt=png


    正是基于刚刚提到的公司内部研发场景复杂化的特点,我们要求这个平台必须具备一体化、敏捷化、自动化、智能化的特点,用以支撑不同团队研发过程管理的差异化。很高兴的是,我们最终做到了这点,腾讯的敏捷研发平台TAPD已经成为业界极具竞争力的研发工具平台。


    640?wx_fmt=gif


    可以说,腾讯的敏捷思想、文化、实践和平台,道法术器四个方面,共同构成了腾讯敏捷研发体系

     

    敏捷化驱动


     腾讯项目管理与研发工程实践 


    了解完研发体系,相信大家一定对腾讯的研发实践和案例更为感兴趣,下面带大家一起了解下腾讯敏捷研发的经典模型和典型案例。


    刚才有讲到,腾讯敏捷实践的目标是交付用户价值,这种交付我们要求它能从端到端拉通敏捷项目管理和研发工程管理,同时我们希望这种交付是快速的、可靠的。


    640?wx_fmt=gif


     1 

    腾讯项目管理实践的三种模型


    这里我们先来了解一下腾讯敏捷项目管理的经典实践,我们把它抽象成三个模型,分别是:迭代模型、极速模型、大象模型


    迭代模型被腾讯80%团队所采用,是最主流的敏捷模式。极速模型则主要适用于需要快速响应市场变化的业务,以运营类团队居多。大象模型则更适合跨组织、跨地域的大型团队采用。


    640?wx_fmt=gif


    那我们首先来看下迭代模型,迭代模型是基于Scrum思想的敏捷实践,他的特点是具有相对稳定的迭代周期,每个迭代周期至少有一次交付。


    这种模型是以需求为始,产品负责人会结合各个渠道的反馈,整理分析成产品的Backlog。团队成员会通过迭代计划会议,选择高价值的需求,分解后纳入迭代。


    迭代是产品研发的心跳,迭代周期会根据团队的实际情况决定,一般不会超过4周。迭代过程中,Scrum Master会组织团队通过每日站立会议、迭代燃烧图等方式透明迭代进展,并通过持续集成等方式确保迭代成果快速交付。


    迭代完成后,团队成员会通过迭代回顾会议进行总结和改进。这就是一个完整的迭代过程。


    640?wx_fmt=gif


    接下来我们来看极速模型,它是以需求为粒度的拉动式交付,通常是单周迭代,可以做到最快每天多次发布。


    640?wx_fmt=gif


    这里我们以QQ音乐的运营团队为例,在遇到节假日,或者市场热点需要举办运营活动,或者对于产品功能进行调整的时候,他们会把这次运营活动作为独立的需求进行跟踪,完成后立即交付,以便做到最极速的响应。


    第三种模型是大象模型,它常见于百人以上的团队,这种团队有多个Feature Team构成,跨组织跨地域,一般的交付周期大于2个月。


    640?wx_fmt=png


    这里一个案例就是手机QQ,手机QQ是超过1500人的复杂团队,会接入腾讯各种业务,比如QQ会员、QQ支付等,这些业务都属于不同的部门,每一个部门都会有一个Feature Team,跟手机QQ的基础平台进行协作,采取拉取代码分支的方式进行独立开发。


    手机QQ建立了统一的迭代计划,进行跟踪管理,迭代周期通常为三个月。设计到需求的变更都进行了严格的控制,让整个迭代计划在所有业务团队都透明,做到项目计划一致。同时在TAPD建立了需求评审流程,所有变更都要经过评审通过后再去实施。通过TAPD平台的使用,做到进一步的透明和精细化管理。


    腾讯的三大敏捷研发模型具有很好的灵活性适应性,在腾讯十余年的敏捷实践过程中,不管是小团队,中型团队还是大型团队,都可以根据团队的成员能力与研发情况选择最适合的敏捷模型,并且随着业务发展持续扩展与升级,这些自适应的实践都可以借助腾讯敏捷研发平台实现。


     2 

    腾讯敏捷研发的工程实践


    接下来为大家介绍腾讯在研发工程方面的敏捷实践


    腾讯敏捷研发实践有三大特点,分别是多元化、定制化和分布式,通俗讲就是工具多、个性化和度量难。那我们是如何解决这个问题的呢?


    640?wx_fmt=gif


    腾讯敏捷研发平台提供了持续交付数据总线的解决方案。通过数据总线,拉通产品研发的全过程,覆盖项目管理、代码管理、持续集成、测试管理、交付部署,运营反馈各个阶段。


    640?wx_fmt=gif


    同时,数据总线支持在各个环节,接入腾讯内部多样化研发工具,比如腾讯工蜂Git代码管理、代码检查工具、自动化测试工具、RDM、织云等集成和部署工具。


    数据总线提供了可视化的流水线管理,并落地了各环节的研发数据,帮助团队进行多维度的研发效能度量,实现一站式研发过程管理和改进。


    640?wx_fmt=gif


    持续交付数据总线可以将项目管理和工程实践数据无缝打通,支持标准化的工具集成方案,提供丰富的研发效能度量,使整个研发生命周期可知可溯。


    640?wx_fmt=gif


    具体来看这些实践:


    开发人员可以将每次的代码提交,和产品需求或缺陷进行关联,使代码更加场景化,实现Issue和代码双向追溯。


    640?wx_fmt=gif


    构建信息嵌入在项目管理中,拉通项目管理和工程实践。所有的构建任务、构建过程和构建结果都会在平台可视化展示和管理。


    640?wx_fmt=gif


    聚焦到单次构建,可以获取到这次构建范围内涉及的需求和缺陷。开发运维同事,可以关注到这次构建包含的产品特性;同时,产品运营同事,可以感知每天的开发进度和交付情况。


    640?wx_fmt=gif


    对于客户端类型的产品,测试、体验相关人员,可以快速获得每次构建的制品产物,并对构建产物进行版本化管理,开展质量验证工作。


    640?wx_fmt=gif


    如果团队有做静态代码检查、自动化测试相关的实践,数据总线可以对质量报告进行分析与可视化展示。对报告中的问题,支持一键录入缺陷单,实现缺陷的全程跟踪管理。


    640?wx_fmt=gif


    除了CI、CD实践外,研发效能的统计与度量也是驱动持续改进的重要因素。


    TAPD数据总线提供了多维度统计和度量能力,以迭代为例,通过迭代的Dashboard,可以统计到当前迭代的需求完成情况、缺陷新增和解决情况、代码提交与关联趋势、每日构建统计、构建产物版本情况、自动化测试、部署等全过程数据。


    640?wx_fmt=gif


    TAPD数据总线能够全方位、多角度、立体化进行研发效能度量,解决企业交付面临的研发效能难度量问题,驱动研发效率持续改进。


     

    开放与助力


    企业数字化敏捷方案落地


    随着腾讯“开放 连接 生态”建设的深入,腾讯的敏捷研发平台TAPD也向外界进行了开放,携腾讯敏捷的经典实践与十二年来的敏捷服务经验,助力各行各业的企业提升研发效能,落地数字化敏捷方案。


    开放一年多的时间来,腾讯敏捷研发平台已经服务超过40W研发项目,覆盖电商、企业、金融等20多个行业领域,获得良好的用户反馈和评价。


    640?wx_fmt=gif


    我们将腾讯十二年来的敏捷实践进行了提炼,结合腾讯敏捷研发平台的产品优势,推出了轻量协作、敏捷研发、DevOps持续交付三大解决方案,满足不同行业、不同规模、不同成熟度团队的项目协作与研发管理需要,并且支持无缝扩展升级,与团队共同成长。


    640?wx_fmt=gif


    同时,在工程实践环节,我们整合了业内主流研发协作工具,并和项目管理过程进行了无缝打通。针对企业自建平台的接入,我们的开放平台也提供了标准化的接入流程,助力团队打造贯穿产品研发全生命周期一站式交付能力。


    640?wx_fmt=gif


    截至目前,腾讯的敏捷研发平台TAPD已经服务了超过10W家企业,并得到了各个行业标杆客户的认可。


    640?wx_fmt=gif


    未来的腾讯敏捷研发,希望和在座的各位,以及各位所代表的企业一起,探索更多的可能,一起打造更加开放的敏捷研发生态。


    最后,如果大家希望了解腾讯敏捷的更多信息,可以等会后在外面TAPD的体验区进行体验与交流。


    谢谢大家!


    640?wx_fmt=png

    展开全文
  • 文 / 王不留(微信公众号:程序员生存指南) 《漫谈公司定期组织的几场会议》、《软件企业区域月度交付会议的改进方式》分别介绍了公司的几个重要...公司研发部门可细分为五大产品线,每个产品线相当于一个二级...

    文 / 王不留(微信公众号:程序员生存指南)

     

     

    漫谈公司定期组织的几场会议》、《软件企业区域月度交付会议的改进方式》分别介绍了公司的几个重要会议,以及项目管理工作会议是如何召开的。

     

    本文继续介绍产品交付联席会议的内容。

     

    如前文所说,公司大了,部门多了,各部门之间的沟通会变得不通畅。然而公司的运转又是一个有机整体,产品和交付之间需要一个有效的沟通机制。

     

    这个会议,主要是由研发部门、项目管理部、市场部参与组成。公司研发部门可细分为五大产品线,每个产品线相当于一个二级部门。

     

    项目管理工作会议早于这个会议。项目管理部会收集各区域对产品的反馈意见,以及客户所提需求,对这些内容进行梳理后,在本次会议与研发负责人集中讨论解决。

     

    会议汇报材料统一采用EXCEL,省去PPT美化时间,把精力用在其它工作上。

     

    会议主要议程为:

     

    1、市场部介绍行业市场形势和分析,为产品研发动态调整提供决策依据;反馈当月项目机会跟踪情况;上月问题解决情况,待协调问题,和下月的市场计划。

     

    2、各产品线分别介绍当月的研发工作。汇报模板包含:

     

    1)概述

     

    2)本月投入情况

     

    3)本月版本发布情况。版本发布含所有产品,不限于战略级产品。产品发布指符合公司产品版本发布要求、可以交付给现场的版本,包括产品、组件、规范和可复用的核心技术等。

     

    4)本月战略产品研发情况

     

    5)本月战略项目支撑情况

     

    6)本月项目管理部反映问题的解决情况

     

    7)本月新增的知识产权。只填写专利(本月新申请或新下证的)、著作权(本月新下证的)、期刊(新发表的),已申请未下证的著作权和待发表的期刊文章都不必写

     

    8)本月创新情况。描述创新的成果或重要进展,一般性进度不必填写。

     

    9)本月待协调问题

     

    10)本月行业及技术趋势分析

     

    11)本月竞品情况分析

     

    12)下月版本发布计划

     

    13)下月战略产品研发计划

     

    14)下月战略项目支撑计划

     

    15)其它工作事宜

     

    3、项目管理部汇报上月的交付情况,重点介绍需要产品协调的问题及客户的需求想法。

     

    产品交付联席会议每月一次,为产品、市场与区域建立了良好的沟通桥梁。

     

    1、让市场部门知道产品的研发情况,在做售前咨询时可以有的放矢;

     

    2、让交付部门了解产品的研发情况,知道项目实施的演进思路,了解区域关注的产品解决进展;

     

    3、让研发部门知道市场形势和项目情况,以便在产品的研发投入上分清主次。

     

    后来为了让各部门将更多精力放在解决实际问题和了解具体产品上,会议内容调整为“大小月”交替进行:

     

    1. 大月需各部门产品经理及以上成员参会,同时邀请1-2个区域代表。增加“十分钟产品课堂”环节。产品线进行十分钟的产品介绍与演示,以覆盖面广,便于为其他部门赋能的产品为讲解重点,助力解决用户痛难点。

     

    2. 小月仅需各部门的部门负责人参会。重点过问题。会议要求各部门每期会议汇报新问题不得超过3个。

     

    会议时长控制在1.5小时,最长不超过2小时。 

     

    * 作者简介:王不留(微信: wbliu85),早晨四点开启奔跑人生的一枚非典型程序员。

    展开全文
  • 11月28日晚,Adapt 规模化敏捷框架系列直播&共创计划正式开始。Agilean 咨询顾问李黄容为大家带来了干货满满的首期直播分享,她结合实践分析盘点的金融组织研发交付过程七...

    11月28日晚,Adapt 规模化敏捷框架系列直播&共创计划正式开始。Agilean 咨询顾问李黄容为大家带来了干货满满的首期直播分享,她结合实践分析盘点的金融组织研发交付过程七大痛点,更是引发了直播观众的共鸣。本文将结合Adapt 直播群中,以及直播过程中征集的问题,以及第一期直播内容进行总结,便于读者更好的理解 Adapt 框架及后续直播分享。

    文末「阅读原文」,获取首期直播分享 PPT 。第一期直播回放地址,扫描文末 B 站二维码查看。

    1

    Adapt 是什么,有什么优势

    过去十几年间,Agilean 在帮助中国金融组织进行数字化落地和敏捷转型过程中,逐渐意识到 SAFe、LeSS、Scrum 等框架在金融组织落地时,都面对着不同的阻力和困惑。想要更好的帮助中国企业,就必须找出一套完全适应中国国情和金融组织特点的框架和方法论。于是,Adapt 诞生了。

    Adapt 框架章程图

    产品部落敏捷研发章程,Agile Development Agenda for Product Tribe,简称「Adapt」,是 Agilean 团队将多年实战经验融汇出的,适合中国金融组织的规模化敏捷框架。

    金融组织根据自身特点适应性地运用Adapt框架,建设敏捷型组织,在科技侧建立与业务对齐的敏捷产品部落,助推业务价值端到端的高质量敏捷快速交付,实现组织数字化战略转型落地。

    在此之前,我们有一篇关于 Adapt 框架的全方位介绍文章,点击下图阅读:

    2

    Adapt 在非金融行业的适用性

    这是直播前大家问的较多的问题之一,Adapt 诞生于中国金融行业的数字化落地和规模化敏捷转型实践,可以说 Adapt 框架为中国金融行业而生,但并不意味着只能应用于金融行业。

    Adapt 框架六要素

    正相反,由于中国金融行业有着非常复杂、高度严谨、大量创新等特点,能够解决金融行业问题、且天生拥有大量成功落地实施案例的 Adapt ,在不超过金融行业规模的其他领域,也能表现出优秀的适应性。对于百人千人规模的团队,Adapt 基本是拿来即用的。

    3

    Adapt 与其他框架的区别

    虚拟部落制是 Adapt 的核心之一,其脱胎于 Spotify 的部落制。与 Spotify Model 主要有两点差异:

    Adapt 补充了 Spotify Model 缺失的落地细节

    Spotify Model 实际上没有太多细节,特别是落地细节。Adapt 在保持部落制这一思想的基础上,补充了大量的落地细节,使之最终成为一个更具可操作性的方法框架。

    Adapt 更强调相对的标准化

    Spotify Model 强调每个小队的自治性,即部落中每个小队都可以用不同的方法,可以用看板,可以用 Scrum,或自己能想到的任何方法。但在 Adapt 中,更强调定义的相对标准化,使得 Adapt 在组织级运作上有更好的一致性。

    与 Scrum 相比,Adapt 在底层替换了 Scrum 框架。例如,Adapt 的角色体系中,没有 Scrum Master 这个在中国极难落地,且不对交付负责的方法论专家&传教士。

    Adapt 采用了分工更合理、更容易理解、更加可执行的 「5+3」角色体系:

    在角色方面,Adapt 拆分为一个授权结构,即将业务负责人抽出,与部长对齐;产品经理下沉到小队或部落级,使其可以参与到小队的日常活动。产品经理负责产品需求端到端交付,小队长负责交付进度与质量,业务负责人负责产品需求范围与优先级,等等。

    与其他框架的区别,点击下图,吴穹博士在 DOD 大咖说访谈中有过更详细解读:

    4

    Adapt如何解决金融研发交付七大痛点

    在本次直播中,李黄容顾问详细介绍了 Adapt 的实施路线图,以及在中国多个大型团队的落地实施案例。

    Adapt 实施路线图

    谈到在金融行业落地问题时,针对许多小伙伴有关规模化敏捷落地实施过程遇到的问题和痛点,她带来了多家国内金融组织的一线实战经验分享,剖析了金融组织敏捷研发交付过程的七大痛点:

    针对这七个痛点,Adapt 框架一一给出了解决方案:

    组织部门墙,沟通依赖流程和文档的问题,虚拟部落化组织打造对齐业务领域的纵向交付单元,打破原有部门墙的鸿沟,减少过程中不必要的浪费,降低沟通成本,聚焦业务价值端到端的交付,加强组织快速响应市场变化的能力;同时保留了专业职能的横向实体线,侧重提升组织人才专业化能力。

    两家国内金融组织产品部落划分示意

    需求交付进展不透明问题,Adapt框架对于需求颗粒度提出要求,以需求-系统任务-个人任务3层需求体系,更好地帮助团队整体把控交付进度和风险,也建立起研发效能管理基础。由于本次直播时间有限,给出了部分拆分建议如利用实例化需求建模或用户故事地图等工具辅助需求拆分,并简单分享Agilean团队辅导某银行快启工作坊案例。我们也将在后续Adapt系列直播中带来具体实际操作案例。

    Adapt 三层需求体系的实际运用

    金融行业业务需求通常跨多系统跨多团队,沟通协作效率是一大痛点,我们观察到大多团队间的协作全凭你我关系好不好,很多时候处于一个互损状态,导致交付延期等问题。Adapt框架提供了3行动层级20个活动,规范协作机制帮助多小队高效沟通对齐,来保障双方互赢互利,顺利“西天取经”。第二期直播即深入各角色协同实例。

    Adapt 框架三层级 20 个活动

    金融业务需求的复杂性利用双周迭代即发布难以实现,可能会造成研发团队不分白昼黑夜的加班或者折损质量来完成,并造成恶性循环,从而带来团队士气低落,人员不稳定等一系列问题。如何破局?Adapt框架提供了迭代版本双亡管理思路,解耦小队迭代和系统版本,迭代中不同角色各有侧重不同层级,产品经理即准备下一迭代需求工作,研发小队专注系统任务研发交付,版本经理按需发布之前迭代的产品增量。迭代聚集目标进度管理,版本聚焦交付发布,保证速度和质量的平衡。直播中分享的迭代版本日历可以更好的帮助团队把控整体进度和交付节奏和关键节点。

    Adapt 迭代日历

    容量和规划不合理的问题,需求漏斗分析模型能够帮助部落和小队规模化规划更加合理和有效,以部落或小队的上月需求吞吐量或更多月份吞吐量的平均值为基准值T,来分析在价值流动的各阶段需求量是否超过上限最大值或低于下限最小值,以迅速应对潜在存在的风险。如当在途研发测试的需求数超过小队T值1.5倍时,可能会造成并行量过高而带来浪费。

    Adapt 需求漏斗分析模型

    团队风险/阻碍/进展不透明的问题,Adapt 采用需求系统任务双层看板,可视化价值流动,透明识别的阻碍和风险,以及时跟进和清除,把控整体进度;同时,利用看板可视化资源忙闲程度,帮助管理者合理调配资源。需求层面能直观了解到单个需求的具体进度,关联的系统任务进度也一目了然。

    某城商行双层嵌套看板运行实例

    大家都很关心的效能症结定位和度量等问题,Adapt框架提供了部落小队度量体系,从“多快好赞”四个维度分别设置了核心指标和观察指标,搭建起组织研发效能数据,帮助团队及时发现交付过程瓶颈点,并不断改进持续优化,为组织推行数字化研发效能管理打下基础。

    Adapt 研发效能度量案例

    本次直播完整拆解了 Adapt 在两家国内银行的落地全过程,其中一个银行案例,我们也曾专文介绍过,点击下图,详细了解 Adapt 在该城商行的落地案例:

    5

    其他问题 Q&A

    1. 双周迭代如何运行?

    我们此前深度剖析过一个失败的双周迭代案例,点击下图查看:

    2. 需求颗粒度过大还怕拆错,怎么办?

    关键:先整流后细粒,拆错总比不拆强。FLEET 框架完整解答了这个问题,点击下图查看:

    3. 怎么兼顾质量?现在都在呼吁质量

    答:关键是靠质量左移,测试左移,质量不能完全依赖测试。

    什么叫「质量左移」?看完下面这篇文章你就明白了:

    4. 关心角色的职责,参与的活动,输入/输出,以及标准

    角色是 Adapt 框架核心六要素之一,限于直播时长,本次直播未展开介绍角色等核心要素,下周六(12月5日)晚 20:30 ,第二期 Adapt 直播,就是关于角色体系的全面介绍,届时我们将详细解答该问题。

    6

    第二期直播预告

    Adapt 第二期线上直播,由 Agilean 资深咨询顾问郭阳出品,主题为 Adapt 框架的「5+3」角色体系,敬请期待:

    附:Adapt 系列直播分享计划

    点「阅读原文」,获取直播 PPT

    展开全文
  • 在软件研发思维中,痛点的挖掘消除,也能成就研发交付能力的提升,让做研发执行的用户也能感到组织的良好成长氛围自我的进步。通过多次观察不同研发团队负责人谈论痛点的思路痛点挖掘结果,本文想对研发团队中...

    “ 痛点,在产品思维中是一个频繁被提及的高价值关键词,能挖掘出并消除用户的痛点,就有可能成就一家独角兽企业,比如消除“最后一公里”交通不便痛点的共享单车企业,让用户体验到出行的便利;在软件研发思维中,痛点的挖掘和消除,也能成就研发交付能力的提升,让做研发执行的用户也能感到组织的良好成长氛围和自我的进步。通过多次观察不同研发团队负责人谈论痛点的思路和痛点挖掘结果,本文想对研发团队中为什么要挖掘痛点和如何挖掘痛点做出分析和总结。”

    01

    为什么要挖掘痛点

    软件研发活动,涉及研发流程、规范、团队协作、专业技能要求等多方面的组成因素,各方面也需要持续改进才能匹配软件这样需求变化快和技能变化快这样的现状要求。而纵观各方面持续改进的手段,一般都是在原有基础上做加法操作,大动骨架的操作比较少,也不好实施。这种改进方式,随之带来的,就是流程的臃肿、规范的多而杂散、协作方的增多、专业技能要求增高等问题,这些问题经常也会是调研一线开发人员的意见反馈时,他们提的较为频繁的问题。如果不去改善这些问题,那么研发组织的交付能力只会逐渐恶化,最终交付不顺畅、无法快速响应客户诉求而错失良机。

    但所有问题并不都是痛点,痛点是问题背后的本质原因,针对研发组织而言,无法及时交付高质量软件的本质原因就是研发组织的痛点,所以问题背后的痛点挖掘,是学习型组织必须持续进行的一项改进活动。

    当然,痛点挖掘再重要,也得有前序和后序动作相互作用,才能产生价值和收益。一般的动作步骤如下图描述,先找到痛点挖掘的出发点,再采用合理的方法进行痛点挖掘,再针对性给出改善方案,进而对方案进行效果评估验证,最后将验证通过的方案举措规范化到研发活动或研发流程当中,作为固化的动作来执行,让痛点挖掘和改善的价值最大化被利用。
    痛点挖掘和改善实施的步骤

    02

    从何处挖掘痛点

    痛点的挖掘,从出发来源上讲,分为主动式被动式
    主动式主要是研发组织当中的积极者,凭借着对未来更优工作方式和工作环境的期望,来持续寻求改进。例如,研发流程相对顺畅,但交付效率期望再提升30%,这时就需要主动从交付效率维度深入分析,找到阻碍效率提高的因素,“如何消除阻碍因素的影响”就成为痛点挖掘的切入点。

    被动式主要是当前组织已经面临交付能力问题,前行受阻,需要直面问题做改进,才能让恢复组织的生产力。例如,交付给系统测试部门的软件,频繁被提严重故障单,质量表现很差,这时就需要被动的从质量交付出发,分析哪一类故障泄露占比高、哪一类功能的故障泄露占比高或哪些人或团队的故障泄露多,以此作为痛点挖掘的切入点。

    对于主动式或被动式的痛点挖掘来源,挖掘方法上基本类似。

    03

    如何去做痛点挖掘

    痛点来源于问题,属于问题的本质性描述。从问题出发挖掘痛点是首要的,挖掘出的是否是痛点需要验证,痛点挖的是否到位也需要有准则来验证,一般步骤如下。
    痛点挖掘步骤
    3.1 从问题表象切入
    **问题并不能和痛点直接等同,因为有些问题可能只描述了一个不理想状态的表象。但痛点的挖掘,又是来源于问题的表象。**从问题表象做切入,寻找问题背后的本质原因之后才有可能挖掘到痛点。比如所在的研发组织连续几个迭代都无法按期交付需求,这其实就是个不理想的问题表象,这个问题背后,是因为交付流程某个环节频频阻塞造成的,还是因为流程整体的不合理导致?有了这些WHY,就算是走到了问题本质挖掘的环节。研发活动中的问题表象比较多,比如无法按期交付需求、任务多却成就感低、工作效率低下、故障泄露多、资源浪费严重等。

    3.2 通过找问题本质挖掘痛点
    继续刚才的例子,所在的研发组织连续几个迭代都无法按期交付需求,分析数据后,发现是因为交付流程某个环节频频阻塞造成的;再次分析,这个环节的阻塞又是因为有协作方的介入,但协作方又在节奏上和资源投入上不能与协作的期望相匹配而造成的。到这里,已经走在找问题本质的路上了。挖掘本质的方法总结如下:

    (1)放眼全局,找聚焦点
    连续几个迭代无法按期交付需求的问题要分析,需要将整个交付流程摊开去面对,从整个流程的全局去分析,会发现阻塞环节是在不同协作团队的功能集成上,功能集成环节作为分析的聚焦点被关注。

    (2)聚焦局部,分析本质
    聚焦到功能集成环节后,做深入分析,发现最本质的原因是某个协作团队在大多时候都无法按期交付自己的功能,导致整个功能的集成进度受阻。

    (3)扩散到关联因素,做全面分析
    如果只关注到某个团队的参与力度不充分的因素上,那么可能仅仅只分析到了局部的原因,需要扩散到关联因素。关联因素,包含需求的计划制定、人力资源的投入、协作方的任务优先级等,这些也是直接影响能否按期做功能集成的重要因素。

    3.3 验证痛点挖掘到位
    挖掘到的是否是痛点?是痛点,但是否挖掘到位?也是执行过程中必须要面对的疑虑。继续刚才的例子,“连续几个迭代无法按期交付需求”问题的本质分析为“协作方在节奏上和资源投入上不能与协作的期望相匹配”,这是否就算是找到了问题的本质原因并挖掘到痛点了吗?

    若肯定的回答“是”,那么“如何提升协作方的参与力度”就作为痛点,来被讨论和制定改善方案。在讨论改善方案时,就会有人提出“为何协作方不愿意及时配合?”这种发散性疑问,这个疑问足以说明问题的本质原因还是挖的不够到位,这样就难以让讨论者的思路直接聚焦到改善方案上,而是仍然在是否是痛点的疑问上徘徊。
    
    若否定的回答“不是”,那么意味着问题的本质还可以分析的更加深入。再仔细分析,协作方的参与力度不够,是因为交付的目标在协作方那里的优先级并没有高到值得去投入充分的资源来保证交付不受阻,说简单点,就是交付方和协作方的目标和计划上未达成共识,那么痛点就变成了“如何保证交付方和协作方在目标和计划上达成共识”,此痛点的描述,很自然地就会让讨论者去直接思考如何针对达成共识做改善,从而,也才有可能讨论和制定出贴切的解决方案。
    

    无论找出的痛点是“协作方在节奏上和资源投入上不能与协作的期望相匹配”还是“被协作方和协作方的目标和计划上未达成共识”,想判断是否是痛点,可以反向的思考这两个“痛点”给研发交付带来的影响是什么?显然它们两者都能影响到需求是否能按期交付,所以它们都是痛点,只是对于改善方案的制定来讲,挖掘的到位程度不一样。

    所以,是否是痛点,痛点挖掘是否到位,都应该有个验收准则才能更客观的去评估。是否是痛点,总结为一句话:去反向思考挖掘出的痛点是否会造成问题表象的发生。痛点挖掘是否到位,总结为一句话:挖掘出的痛点,能否让人看到后就能沿着习惯性思维去想改善方案是什么,而不是还停留在这是否是痛点的疑问思考上,那么,这时挖掘出的就是较为到位的痛点。

    04

    痛点的改善和效果验证

    痛点挖掘有出发点,也有了体系的挖掘方法,只要做到位,对于研发组织的交付能力提升来讲,输出的痛点结果就是组织的基本改进目标了。有了改进目标,就方便去聚焦想法和资源进行改善方案的输出,以求达成目标。由于针对不同的具体问题,改善方案可能相差甚远,需要展开篇幅去专门讨论,此次不做简单讨论。但改善方案的效果验证却是相当关键的动作。

    总体来讲,可从方案实现视角用户视角两方面来验证。继续用本文的例子来说明,“保证被协作方和协作方在目标和计划上达成共识”的改善方案是从需求规划优先级一致、版本节奏匹配、开发计划和功能集成计划同步几个方面合力矫正,那么,从方案实现视角看,改善效果验证通过的完成定义,就是方案中设定的优先级是否一致的指标、版本节奏是否匹配的指标、开发计划和功能集成计划是否同步的指标表现符合预期;从用户视角看,改善效果验证通过的完成定义,就是研发的交付顺畅程度所对应的指标有所增加、交付效率对应的指标有所提升,研发组织的交付是否进入到一个顺畅且持续产生提效增益的发展状态。

    将验证通过后的改善方案中的举措规范化到日常的研发流程或活动中是极其必要的动作,也是让挖掘出的痛点不再表现出“痛”的最彻底的手段,充分体现痛点挖掘的意义和价值。

    作者个人公众号:
    在这里插入图片描述
    https://mp.weixin.qq.com/s/hXz9J_jIdOldULbjzHwoKg

    展开全文
  • 不懂技术 如何管理好研发部门

    万次阅读 2011-03-06 18:34:00
    ——“最佳提问者与解答者”评选各位职场高手,我在一家中小企业工作,从销售员做到了副总,目前主要负责销售部技术部的管理工作,这两个部门是公司最主要的两大部门,技术部负责公司的新产品开发,但长年以来管理...
  • 任何的业务需求实现都会包括大量接口的开发,但这些不同业务间差异性较大的接口又不具备可复用性,因此不断的造接口带来的是研发、测试到交付上线一整套的人员投入。 对个人来说开发CRUD是几乎没有技术成长的,开
  • 内容主要整理自 阿里巴巴新零售淘系技术部 出品《为什么你的高效交付,却没有好的业绩》 + 【个人解读】 目录 持续需求交付的痛点 打造持续交付的价值交付 持续价值交付的敏捷价值观 持续需求交付的痛点 1. ...
  • CSDL 团队已经为各种 i386、x86_64、ia32e  ppc64 硬件平台上的不同 Linux 分发版交付了 CSM。  * BladeCenter  StorageBlade 的管理模块(MM)— CSDL MM 团队与 Raleigh BladeCenter ...
  • CSDL 团队已经为各种 i386、x86_64、ia32e ppc64 硬件平台上的不同 Linux 分发版交付了 CSM。  * BladeCenter StorageBlade 的管理模块(MM)— CSDL MM 团队与 Raleigh BladeCenter 软件团队合作开发管理...
  • 一个互联网研发团队的标准配置

    万次阅读 2016-07-10 21:22:03
    产品是否是咱们需要的,UI是否漂亮,做出来的APP网站,能否按时交付,推动公司业务发展! 部门负责人、产品、UI设计,是开发阶段,上级老板所关注的。 APPWeb网站,是交付阶段,老板关注的。 业务、架构、...
  • 产品部业务部门的利益之争

    千次阅读 2011-11-10 16:28:05
    产品部业务部门的利益之争   出于好奇,我问周扬是怎么在很短的时间内对产品管理有了如此深刻的理解的,他嘻嘻哈哈地应付道,要是自己不努力点,怎么能够大家把产品部一同做好呢。 问了几次,他都是这个态度...
  • 一.背景 自动驾驶在软件侧是一个超高维度的系统。 自动驾驶本身的感知、控制...研发部门和研发流程的目的就是在硬件平台上开发出符合业务功能需求的软件系统,通过合适的流程设计和管理、明确的交付设计和标准来 ...
  • 项目交付体系

    千次阅读 2020-08-05 13:56:46
    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付...
  • 交付型项目经理

    2021-08-07 08:41:25
    如果你在后台部门做项目经理,那么你就是研发项目经理; 如果你在中台部门做项目经理,那么你就是交付型项目经理; 如果你在前台部门,那么你就是售前项目经理 交付项目经理的工作内容定义: 当销售...
  • CI与CD--从持续集成到持续交付

    千次阅读 2018-09-06 22:19:03
    产品研发生命周期演化史: 1 纯人肉构建 这是发生在我身上的7年前的故事,我们的项目每周四会发布一个新版本,大家在每周四的晚上买好干粮饮料熬夜苦战。研发人员先提交代码,你...凌晨3点,整个研发部门终于发布...
  • 在深入探讨持续交付之前,我们先来看一个典型的场景:A公司最近很苦恼。...研发同学只关注代码编写,很少考虑线上部署的规范设计,全靠运维同学自己把关,结果各个系统的维护自成一套;新旧系统越来越
  • 获取支持完美落地更是难题,研发全生命周期,是一个横向可拓展,纵向可延伸的工作。本次话题希望从讲好故事做好事两个方面聊工程效能部门如何开展工作。 本文适合那些在大环境低迷,出资方不见兔子不撒鹰,苦于不好...
  • 如何搭建测试团队(研发同理)

    千次阅读 2019-04-11 16:20:33
    前言 总结数年测试团队搭建经验,为大家搭建...测试技术的负责人,主要承担教练职责,是测试部门的技术核心,涵盖产品测试技术、自动化测试技术、专项测试技术、交付测试技术等方向。 主要负责:测试技术管理、测...
  • 持续交付话题的一些讨论心得

    千次阅读 2013-05-25 23:43:42
    周末参加了在杭州举行的持续交付话题沙龙的讨论,将这次活动中的一些精彩问答经验警句记录下来供大家参考: ”持续交付如何让老板看到价值?“,这是当时讨论的比较激烈的话题,大家形成的基本结论是可以通过...
  • 中央软件院是造轮子的,云平台,平台类 2012中央研究院,一堆做不同的东西的实验室,...消费者,待遇最好,交付压力最大,研究现在的技术 不同的研发地点是否对应于不同的研发领域: 否,每个bg都是什么都做的
  • 本文基于精益思想精益软件开发,针对研发过程中的“浪费现象”进行深入分析。浪费分成存粹的浪费必要的浪费,其中存粹的浪费需要消除,而必要的浪费可以进行压缩。结合日常研发过程,本文对如何识别这些浪费、...
  • 数据研发团队; 研发/执行 分析师辅助; 纯粹技术需求,ETL之类; 分析做实施执行工作; 工程化团队; ...
  • 这里所指的研发特指可重复产生价值的产品/解决方案的研发,不包含面向客户交付的项目型开发。 而产品/解决方案的研发,又可以分为两种情况,一种是完全没有业务基础的探索型研发,一种是基于现有业务的增值型研发。...
  • 1.技术中心所有岗位的设置都实行一人多岗、岗位随项目管理需要动态变动绩效考核。 2.除日常岗位职责外,同时兼任技术人员,并纳入项目责任考核。 3.技术中心岗位分为管理岗技术岗,管理岗指主管级以上岗位。...
  • 研发管理心得整理

    千次阅读 2019-02-20 12:34:36
      2019-02-16 11:37:55 研发管理心得整理 在现在的公司工作了快5年了。陪伴着公司从创业初期一直走... 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来,从高级研发到架构师,从架构师到项目总监的...
  • 如何让销售开发部门团结协作

    千次阅读 2009-05-03 14:53:00
    如何让销售开发部门团结协作 尽管在销售开发部门之间存在着文化背景等各个方面的差异,但是只有让这两个部门紧密的联系在一起才能够让他们发挥出最大的功效。一个产品从概念阶段到变成现实创造利润需要这两个...
  • 作者简介:胡砥峰,现任北京文思海辉金信软件有限公司高级产品经理、高级架构师、福建区交付总监,具备14年软件行业经验,主要服务于金融IT类公司,服务银行、证券等客户项目。2003年入职三五互联,2004年入职东南...
  • 安全公司一般都会有一下三个部门,(当然了安全公司还有很多产品线,这些产品线主要是生产安全相关的产品比如:waf、防火墙、准入等,就不多介绍了,如果你是做研发的可能只是语言不一样的问题了,其他软件公司...
  • 对多项目、多平台下研发信息的透明性,本文从两个角度进行了梳理抽象:首先项目线-研发线协作流程为不同工作线上的团队提供统一的项目研发视图工作模式,围绕完成目标版本这一项目实施目的展开具体工作,确保...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,053
精华内容 6,421
关键字:

交付部门和研发部门