34

谈SAFe规模化敏捷框架助力企业数字化转型(200923)

 3 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102z95z.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

最近听一个企业数字化转型战略的在线课程,听到SAFE规模化敏捷框架这个概念,这个概念说实话第一次听到,因为我原来更加关注的是类似Scrum的敏捷项目管理,即项目管理中的敏捷方法论,而对于SAFE你可以理解为企业层面的敏捷方法论。

为何在企业层面会出现SAFE敏捷方法论,这个和企业数字化转型中的战略规划设计有很大关系,即数字化转型里面本身有一个重点就是要敏捷迭代,但是传统的3到5年战略规划相对来说已经不再适用,必须更加敏捷,更加能够适应变化的企业层面敏捷战略规划。

原来的规划可能是范围已经确定,但是成本投入和时间进度往往具备弹性。但是在新的敏捷规划下往往是预算和时间是确定的,但是范围可以调整为迭代。这个就是最大的一个区别点。

在企业数字化转型里面我们经常会谈到企业数字化中台来支撑企业数字化转型,但是首先你要看到的就是企业本身的业务变革和业务规划要敏捷,业务敏捷后才能够谈得上IT如何来支撑业务的敏捷。那么业务如何做到敏捷?

简单来说企业内的各个价值链和支撑链上的业务组织单元要足够的标准化和可复用,只有这样业务单元间才能够更加灵活的协同。而把这个概念转移到IT支撑上面,自然就是当前我们谈的最多的微服务和DevOps支撑。即:

企业战略和业务的敏捷-》业务能力单元化和模块化-》数字中台-》IT能力支撑上的敏捷

SAFE敏捷框架

把这个梳理清楚后,我们再回来看下SAFE敏捷框架的一些内容:

企业敏捷 Scaled Agile Framework (SAFe) 是一个大规模敏捷框架,它不仅包括团队敏捷,还包括了价值流、投资组合、项目集等层级的敏捷管理方法和架构。常规的敏捷框架适用于中小型项目团队,而且不具有扩展性。基于常规的敏捷框架,SAFe 定义了一个可扩展的敏捷框架模型,它适用于大型团队的合作开发,可以帮助提高团队之间的协作性,降低团队管理的复杂性。

Dean Leffingwell(SAFe创始人)于2011年上线了SAFe1.0,随后根据业务实践以及市场变化,SAFe不断改进和提供软件和系统开发方法,及时上线新版本。

SAFe五个核心能力

  1. 精益敏捷领导力
  2. 团队和技术敏捷
  3. DevOps和Release on Demand
  4. 商业解决方案和精益系统工程
  5. 精益解决方案管理

SAFe希望解决的问题

可以看到SAFe本身也是基于主流的精益和敏捷原则,为为企业价值流、投资组合、项目集和团队提供详细的实施指导,最大限度为企业利益相关者提供价值。SAFe希望融合精益敏捷背后的理念,为以下问题提供答案:

  1. 当管理层仍然负有责任时,他们是如何放弃控制权的?
  2. 如何为成百上千的客户开发产品?
  3. 如何跨团队协调工作,当团队之间存在依赖关系时?
  4. 对于可能要耗时多年的,存在依赖的大型软硬件系统,如何建立/架构设计以及实施?

SAFe敏捷框架的三层架构

再简单点来说SAFe可以看做 是企业级的Srum+Devops+项目组合管理方法论整合 。即通过敏捷的方法从项目组合管理一直拉通到最终的敏捷项目执行。

组合管理层面: 首先,SAFe 框架在投资组合层由投资组合管理委员会(Program portfolio Manager)来负责定义和驱动投资策略如何形成和资金的组合形式,然后将其体现成为叙事诗(Epics)。一个 Epic 可以是一列单独的敏捷火车(Agile Release Train)来执行, 也可以是几个火车的组合。Epic 是直接面向客户的、设计架构级别的业务解决方案。

产品管理层面: 接着,在第二层计划层由产品经理(Product Manager)负责把等待安排的计划(Backlog)进行排序,并且把投资策略转化成具体的新功能(Feature),同时和业务负责人一起设计出项目的愿景和路线。

项目和团队管理层面: 最后,在第三层团队由产品负责人(Product Owner)和团队成员根据上面的定义细化出用户故事(User Story)和验收标准,开发团队可以从候选的用户故事里面优先选择可以提前开始的内容,其余的留到故事池里面等待后续的选择。

由此可见,SAFe 从三个层面保证了团队和企业的投资组合的最终愿景一致。同时,在实施过程中,需要一系列的里程碑事件来保证最终的实现和高层愿景设计的持续一致。而里程碑事件的制定主要通过计划发布(Release planning)和系统的展示(System Demo)来保证。

和传统Scrum的一些差异点

在前面实际上已经谈到了对于SAFe敏捷框架更多的是企业层面的敏捷,而对于Scrum更多的项目层面的敏捷,但是可以看到SAFe敏捷框架的三层架构,分解到第二层和第三层的时候实际上已经就是我们常说的Scrum方法论里面的主要内容,比如从产品规划Product Backlog到每一次Spring Backlog的确定等。

那么在SAFe敏捷框架实际增加的关键内容在哪里?从上面的基础概念了解我们可以看到在实施SAFe敏捷框架的时候你必须要考虑的是:

  1. 组合管理层面敏捷:简单来说就是预算只有这么多,如何效益最大化
  2. 项目群管理敏捷:组合管理分解后形成一个项目群,项目群之间如何敏捷协同

就类似我们进行了一个企业数字中台项目建设的时候,你首先是要规划出来需要做哪几个产品或项目,然后每一个产品或项目都是独立的一个敏捷团队,这个完全可以根据传统的Scrum敏捷方法论进行管理,而站在企业层面你需要考虑的就是多个这种敏捷团队如何更加高效的协同。

再比如一个例子,比如我们的福利平台,可能会涉及到供应商采购溯源团队,运营团队,开发团队,而当我们规划完一个新的产品特性或一个新的商用模式的时候,往往涉及到多个团队之间如何协同,只有多个团队之间能够更加高效的敏捷协同,才能够提升到组织或企业级的协同。

SAFE敏捷框架为何可助力企业数字化转型

实际上在前面很多谈中台,微服务,企业数字化转型的文章里面我都谈到。企业的数字化转型本身首先是业务的变革,其次才是信息化和数字化技术的支撑。如果业务本身不敏捷,很难说通过技术就能够简单额实现敏捷。

即前面谈到的中台建设往往也是企业本身在业务上已经形成了业务中台或共享服务中心,其次才是考虑如何在技术上通过微服务和能力开放平台来支撑中台。对于微服务和DevOps研发运维一体化也是同样的道理,往往是技术开发团队本身就是进行了拆分和微服务化,其次才是技术架构上支撑微服务的开发和集成工作。

而对于数字化转型的本质主要包括三个方面的内容。

  1. 连接:万物互联,解决人和人,人和物,物和物的连接问题
  2. 数据:连接后产生集成和协同,协同过程自然会产生数据
  3. 智能:数据经过加工和提炼,形成智能化分析应用

那么现在我们看到的数字化转型实际是什么呢?从当前看到的信息更多的还是在谈数字化营销,谈消费互联网,谈企业如何做到直达客户,如何形成自己的私域流量,谈当前主流的类似微信,小程序,直播,商城这些信息化工具和应用如何整合等。

当然,上面谈到的内容本身是没有任何问题的,但是这些远不是数字化转型的全部,当你谈全渠道触达,多终端营销和整合,流量私域转化的时候,都需要有一个重点,就是 你当前企业内部的交付效率,交付质量,售后服务能够完全的匹配增加的个性化需求和流量

而要做到这点,其核心就是业务上要足够敏捷和灵活,能够根据最终客户需求和目标灵活的进行动态适应和调整。

其次,我想谈下生态建设方面的话题。在我前面谈数字化的时候,我也经常谈到数字化有一个重点就是要消灭中间商,代理商,同时形成直达最终消费者的营销模式,将很多原来的公有流量转变为私有流量。

而你要做到这点,那么你就必须足够的强大,信息流足够的快速,你自身的连接能力足够强,对市场需求的敏捷响应能力足够快。只有这样你才可能有能力实现或去整合一个生态环境。

正因为如此,我们看到企业要实现数字化转型,业务能力上的敏捷响应能力更加重要,而这正是通过实施规模化敏捷框架希望达到的一个效果。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK