• 注册
    • 总打赏排行
    • 今日收益排行
  • admin
    I'm a Slash!
    打赏了977人参果
    关注
  • 977725219
    太拽了什么都没留下。
    打赏了43人参果
    关注
  • 蔚蓝的海
    太拽了什么都没留下。
    打赏了35人参果
    关注
  • 25℃ 咖啡
    太拽了什么都没留下。
    打赏了13人参果
    关注
  • swallow2009
    太拽了什么都没留下。
    打赏了10人参果
    关注
  • lili1985
    太拽了什么都没留下。
    打赏了10人参果
    关注
  • 斜杠青年
    青岛海尔文化产业发展有限公司
    打赏了8人参果
    关注
  • GOOGOGOGOOG
    太拽了什么都没留下。
    打赏了5人参果
    关注
  • 易赚360
    腾讯计算机系统有限公司
    打赏了3人参果
    关注
  • admin
    I'm a Slash!
    今日获得295人参果
    关注
  • 小虫
    太拽了什么都没留下。
    今日获得210人参果
    关注
  • workdog959
    太拽了什么都没留下。
    今日获得200人参果
    关注
  • 小区区
    太拽了什么都没留下。
    今日获得150人参果
    关注
  • 态度嘛
    太拽了什么都没留下。
    今日获得150人参果
    关注
  • 武汉毅行团建拓展
    毅行拓展(Tel:13100636712)www.yixingok.com
    今日获得121人参果
    关注
  • 搜楼网
    搜楼网的运营者:http://www.soolou.com
    今日获得120人参果
    关注
  • 唯爱之美
    太拽了什么都没留下。
    今日获得110人参果
    关注
  • 餐饮新点子
    赞奇外卖代运营联系微信17333050112
    今日获得110人参果
    关注
  • 跨境电商之家
    Http://adoncn.com/ 跨境电商之家
    今日获得105人参果
    关注
  • 查看作者
  • 身为产品经理,你懂开发团队的交付过程吗?

    作者:有馅儿的丸子,假的产品dog

    全文共 2497 字 1 图,阅读需要 5 分钟

    ———— / BEGIN / ————

    我们都知道,产品交付,是需求实现的“最后一公里”路,但交付不仅仅只是“将代码部署到测试环境,测试通过后,即可上线”一句话这么简单——交付过程涉及到复杂的流程、团队协作和交付工具等等,任何一点都会影响到产品的整个生命周期。

    一般来说,产品经理极少会参与到最后代码交付过程中去,因为交付主要是由研发、测试和运维等角色在负责,产品经理最多参与进测试阶段。

    事实上,所有的产品团队成员,都应该对我们的产品目标负责。

    一名合格的产品经理,切勿从心理上,就将产品、测试甚至是研发、运维的职责都完全割离开来,从需求的诞生到实现,产品经理应该尽可能的了解和知悉每一个过程,才能让需求实现更加的顺畅,促使自己能够换位思考,掌握全局。

    本文主要来讨论一个概念——持续交付,我并非技术出身的产品经理,仅希望通过通俗的语言来分享自己一点关于“持续交付”的认识。

    一、持续交付是什么?

    百度百科上的定义:

    持续交付是一种软件工程手法,让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以释出的状况。

    光看这句话是不是一脸懵逼?

    关于持续交付的定义,其实早有前人给出了很通俗的解释:

    持续交付是软件研发人员,如何将一个好点子,以最快的速度交付给用户的方法。

    感觉还是有点抽象?

    没关系,我们来解读一下这句话:

    上句中“好点子”就是需求;“交付给用户”就是需求上线,这是一个众所周知的过程。其实这句话强调的是:最快的速度,也就是说交付过程的重点是效率。

    这和敏捷开发的概念是不是有点类似?

    二、什么是敏捷开发呢?

    提到敏捷开发,不得不提到与之相对的一种开发流程:瀑布流开发——即严格地将开发分隔成各个阶段:需求分析、要件定义、基本设计、详细设计、编码、单体测试、结合测试、系统测试等。

    有点像工厂流水线:前一阶段的完成才能开始下一个阶段的工作,意味着没有回头路,返工代价很大,用户对需求无法反馈,十分不适应。

    这样的开发方式已经无法适应当前的易变、模糊、不确定的互联网环境了

    就像斯宾塞·约翰逊说过的:

    唯一不变的,就是变化本身。

    所以敏捷开发方法像净化空气的春雨般出现了,敏捷开发方法的核心是迭代,也就是通过2-4周的迭代时间,不断的交付客户的需求。

    每一次迭代都包含需求分析、设计、实现和测试等多个环节,每一次迭代都可以生成一个稳定和被验证过的软件版本。

    敏捷开发是强调敏捷的软件开发项目管理方式,而持续交付是强调效率和灵活的一种软件工程手法,持续交付就可以定义为敏捷开发管理的一个子集。

    三、怎么看待持续交付?

    经过了以上定义,大部分人对持续交付究竟是做什么的,还很茫然。接下来将结合其他概念,让大家更深入理解持续交付。

    提到持续交付,不得不提到持续集成、持续部署,也就是我们常说的CI/CD。

    持续集成:

    我所理解的持续集成是:在进入开发阶段前,会将研发工作进行拆解,可能是拆分成不同的功能模块,也可能是拆分成若干个任务由不同人员来进行开发。

    拆分之后,就一定需要将代码合并起来,形成完整、有效、正常运行的代码,这个过程叫做集成,反复持续,就叫持续集成。

    持续部署:

    持续部署是持续交付的最高阶段,代码在经过自动化测试、单元测试或者评审后,自动的部署到正式(目标)环境中,快速安全的交付给用户使用。

    持续交付则是一个承上启下的过程,它是在持续集成后,通过测试、产品的使用和验证和反馈后,不断地对产品进行优化。

    我们再回顾前面提到的定义:

    持续交付是软件研发人员,如何将一个好点子,以最快的速度交付给用户的方法。

    产品、测试就是所谓的第一个用户,所以这个定义还是很贴切易懂的。

    持续交付,从业务层面来说,其实是存在着决策的过程的,因为它是在部署到正式环境之前,产品经理或领导者需要做业务判断,判断代码是否可正常交付?是否解决业务问题?是否满足业务需求等等?

    那么持续交付从技术层面,是怎么实现呢?

    四、持续交付的实现方向

    持续交付的具体实现方式要从配置管理、环境管理、构建集成和测试管理等几个方面入手,仅仅通过一篇文章是无法讲述清楚的,并且更适合由研发人员去研究和实践,感兴趣的话可以阅读《持续交付-发布可靠软件的系统方法》这本专业书籍来具体学习。

    这里我仅仅从宏观的产品角度,来总结持续交付的实现方向:


    为令人痛苦的手动步骤,建立起可重复、可靠的自动化过程。


    每一次的修改都能够经过一次构建、测试、部署、发布完整高效的自动化验证过程,实现高速频繁验证,快速解决问题的闭环。

    最后的结果就是:小批量/小粒度频繁的进行持续部署或发布,从而得以实现持续交付。

    当然,在前往这个方向的道路上, 一定要有猛药去疴的决心,如:

    (1)技术层面

    • 改变dev/ops团队在PaaS层面所使用的工具和应用方式;

    • 改变系统架构、部署架构等。

    (2)组织层面

    • 优化调整人员结构;

    • 打破耗时、完全人工的流程束缚;

      ……

    产品经理能享受持续交付带来的好处吗?

    持续交付所带来的收益和价值是能覆盖整个产品团队,而不仅仅是开发人员。

    1. 产品的灵活交付、发布可控,随时有一个稳定可发布的版本,产品人员身为产品前进方向上的主导者,可以有效把控版本发布节奏。

    而且,计划是赶不上变化的,代码交付、功能点部署,是可以根据业务要求可灵活变换的。

    2. 产品人员是曝光在大众、用户目光底下的人,是出现问题故障,要首当其冲化解内外矛盾的人,产品人员对整个产品上线能否正常运行负有重要责任。

    同时,产品人员还是“产品的第一个用户”,我们可以享有持续交付的保护,因为持续交付可以保证在迭代中的每个阶段或需求变化时,都能够及时测试验证,获得问题反馈。

    3. 因为持续交付,需要持续构建和集成代码,并且及时部署到测试环境去验证,产品经理以此可知悉当前开发的进度和质量,及时决策或调整,避免开发人员无故拖延工期所导致的扯皮现象。

    4. 在实施持续交付后,可以做到在保证交付质量的前提下,加快交付速度,从而更快地得到市场的反馈,产品经理就可以尽快做出判断,更好的引领产品的方向,最终达到扩大收益、提高价值的终极目的。

    ———— / END / ————

    点击“阅读原文”下载APP

  • 0
  • 0
  • 0
  • 80
  • #人人都是产品经理
  • 单栏布局 侧栏位置: