专栏首页敏捷开发团队转型,Scrum与DevOps要如何取舍?
原创

团队转型,Scrum与DevOps要如何取舍?

来自敏捷开发社区。

团队在践行敏捷的过程中,会有多种选择:Scrum、XP、Kanban、Crystal、精益生产、规模化敏捷等,其中最流行的敏捷开发方法当属Scrum。正因如此,大部分人对其产生了刻板印象: 认为敏捷就是Scrum,实施敏捷就是套用Scrum方法

而产生在敏捷之后的DevOps集文化理念、实践和工具于一身,可以提高组织高速交付应用程序和服务的能力,与传统的软件开发和基础设施管理流程相比,能够帮助组织更快地发展和改进产品,也逐渐成为衔接开发团队和运维团队的胶合剂。在这种情况下,大家反而会常常限制在一个 思维困境中: 团队转型,是选择Scrum还是DevOps

在这里,有必要纠正一下人们的思维误区。首先,敏捷并非等于Scrum,敏捷作为一种软件开发运动,其发起人试图以一种更为敏捷的新方式来思考软件开发、方法论以及组织架构,从而帮助行业中的人们。Scrum作为一种方法论,并不是详细的操作规范,而是一套行为框架,在此框架基础上,各团队根据自己团队实际情况制定合适的迭代任务。

而DevOps关注的不只是开发阶段的内容,它关注的是整个系统,以促进端到端的价值流动为目的。从客户提出需求,到进入开发阶段,再到交付客户成果,价值的流动并非局限于某一阶段中。整套系统中各个单元都相辅相成,因此某一部分的改变会影响其他部分,为了使价值顺利地流动出去,需要系统中各个单元的相互配合。

因此,当人们对Scrum和DevOps并不了解时,常常会陷入二选一的误区。实际上,Scrum与DevOps并不冲突,从性质上来讲, Sc rum偏向于基础框架,DevOps偏向于文化理念从另一个角度来讲,Scrum与DevOps是局部与整体的关系:Scrum更注重每一sprint结束后的成果交付,DevOps则注重构建、开发、运维等阶段的整体运行、前后的衔接与持续交付。

在Scrum团队中,除却原Scrum团队中的开发人员,还包括架构人员、分析人员、销售人员等,团队下一步要考虑的问题是如何将将各职能成员联系在一起。部分已经意识到此问题的团队为了解决单一的Scrum方法论仅注重开发阶段这一弊端,开始寻求DevOps的支持。

1.持续交付

在Scrum中引入DevOps的持续交付概念,强调每个sprint的完成应以产品增量为目标。

  • 首先,在sprint期间,Scrum Master不会制定详实的sprint计划,而是 仅制定sprint中前几日的计划,之后便随着冲刺期间的工作改进、调整灵活变动计划内容;
  • 其次, 每日召开Scrum会议,同步团队中成员计划,提高成员之间的协作效率;
  • 最后,在sprint结束后, 团队需要召开回顾会议来汇总这一阶段所做的工作,反思这次冲刺中的不足之处及应该注意的事项,以便在下次sprint中调整团队的整体方向。

在sprint阶段里,Scrum团队不断地进行学习、获取反馈,努力提高改进、产出速度,使产品尽可能多地发布到交付环境中。随后Scrum Master 通过这一期的目标完成情况决定下一期的sprint目标,在这一期间仍要注意的是,尽量减少过程中的人为干预,从而减少发布过程的周期。

2.扩大反馈

Scrum团队通过验收会议、回顾会议以及每日Scrum同步团队成员的任务进度,以及时获取上一sprint成果的反馈。与单一的Scrum不同,应用DevOps的Scrum验收已经处于生产环境中的sprint成果,验收标准也不再是单一的性能测试,而是围绕产品本身、部署架构、市场等方面进行多方位评审,从而制定下一期sprint计划。

扩大反馈的方式有很多,总的来说首要步骤就是如何提高生产效率。有以下几种方法: 可以利用结对编程来增加工作效率,使产品尽可能多地交付到环境中。 也可以统一代码规范,减少额外成本的增加:当团队拥有良好且统一的代码规范时,会有效规避因某个成员的缺席造成团队工作停滞的风险,也能够提升代码的可读性,从而提高工作效率、扩大反馈。

Scrum的仪式感常常表现在 迭代计划会议每日站立会议回顾会议等方面。而DevOps更注重在整个价值流中快速并持续交付价值,这种价值的快速流动需要产品发布过程中每个人的参与;同时,透过自动化“软件交付”和“架构变更”的流程,逐渐消除人为干预,使得构建、测试、发布软件更加地快捷、频繁和可靠。

DevOps文化倡导 “共同责任”,也就是在产品发布全流程中,所有成员通过协作确保产品有价值,因此,在Scrum框架基础上应用DevOps能够帮助Scrum团队更好地进行知识学习和创新。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 极限编程:价值观、原则和实践

    在软件工程这样一个快节奏的环境中,传统的项目管理方法不再可行。这意味着IT从业者必须找到新的方法来处理经常变化的开发任务。

    敏捷开发
  • 敏捷史话(三):笃定前行的勇者——Ken Schwaber

    很多人之所以平凡,并不在于能力的缺失,而是因为缺乏迈出一步的勇气。只有少部分的人可以带着勇气和坚持,走向不凡。Ken Schwaber 就是这样的人,他带着他的...

    敏捷开发
  • 敏捷开发 | DSDM 在非 IT 领域也同样适用?

    动态系统开发方法(Dynamic Systems Development Method:DSDM)是在快速应用程序开发(RAD)方法的基础上改进的。作为敏捷方法...

    敏捷开发
  • 为什么我讨厌 Scrum?

    众所周知,Scrum 是一种敏捷实践,很多团队在敏捷转型时都采用了它,但是在我看来,Scrum 并不那么敏捷,甚至它提倡的有些价值观和做法是有悖于敏捷原则的,所...

    深度学习与Python
  • ​深度解读最新版 Scrum 指南

    11 月 18 日晚,Scrum 框架的创始人 Jeff Sutherland 和 Ken Schwaber 联手发布了最新版 Scrum 指南。作为 Scru...

    CODING
  • 如何实现Scrum敏捷转型?

    随着敏捷项目管理模式在国内的流行,各流派敏捷实践培训风起云涌,Scrum框架的相关实践和案例最多,也最为国内推崇。然而在实际应用中,我们会遇到怎么样的阻碍?如何...

    砖家认证
  • 【科普】Scrum——从橄榄球争球到敏捷开发

    对敏捷开发Scrum稍有了解的都知道Scrum来源于橄榄球,但你知道为何要以这项球类运动的术语来命名这个敏捷开发方法论吗?

    爱撸猫的杰
  • 07.【Kevin聊敏捷】敏捷项目管理之Scrum

    Scrum不是敏捷,它只是实现敏捷管理的方法之一。敏捷项目管理方法还有:极限编程(XP),水晶(Crystal),Kanban,特性驱动开发(FDD)、动态系统...

    开心的Kevin
  • 万字长文,Thread 类源码解析!

    金九银十,很多小伙伴都打算跳槽。而多线程是面试必问的,给大家分享下 Thread 源码解析,也算是我自己的笔记整理、思维复盘。学习的同时,顺便留下点什么~

    一个优秀的废人
  • CODING DevOps 微服务项目实战系列第二课来啦!

    近年来,工程项目的结构越来越复杂,需要接入合适的持续集成流水线形式,才能满足更多变的需求,那么如何优雅地使用 CI 能力提升生产效率呢?CODING DevOp...

    CODING

扫码关注云+社区

领取腾讯云代金券