×

微信扫一扫,快捷登录!

标签: 暂无标签


管理价值流动的三个实践,本篇介绍发布规划会议

看板方法中管理价值流动,具体包含管理价值的输入、流动过程和输出。前两篇介绍了管理价值输入——[  /s?__biz=MzI0NDQyNzczMg==&mid=2247484343&idx=1&sn=0b1be5343cb4c0823bb738aebfe5aadc&chksm=e95cbd0cde2b341a03d607b575b6517598c460b8abae7056416249ecdcb149530f9095097da5&scene=21#wechat_redirect]就绪队列填充会议[/url],管理价值流动过程——[  /s?__biz=MzI0NDQyNzczMg==&mid=2247484330&idx=1&sn=410c10d3368551955ba77daae42c06ff&chksm=e95cbd11de2b34076f5d849e6b9b9c5b6a62af447fc247b68fa6fa6419df770f73261f7d6d56&scene=21#wechat_redirect]看板站会[/url]。本篇介绍管理价值输出——发布规划会议。

一、发布规划会议的内容和节奏

1.1 发布规划会议的内容

发布规划会议的目标是确定发布哪些需求,并安排与之相关的工作,典型内容包括:

  • 确认哪些需求已经具备发布条件
  • 确定发布哪些需求,评估它们在业务上的完整性
  • 如果涉及软件部署,还要安排与之相关的工作
  • 评估发布风险,并做出针对性的规避和缓解方案
  • 安排发布前后的相关事务,比如:版本说明(Release Note)的编写,运营工作的协调等
  • 确定与发布活动相关的责任人和跟踪事项

1.2 发布规划会议的节奏

除非可以做到持续发布,团队应尽量形成发布节奏,如每周、每月或每季度发布一次。固定的发布节奏可以降低召发布规划会议和安排交付活动的协调成本,并更好地管理外部期望。确定合适的发布节奏,需要综合考虑频繁发布的要求和每次发布的成本,并在两者之间做出平衡。

频繁发布的要求来自业务和开发两个方面:

  • 业务对频繁发布的要求:更频繁的发布,即时将需求推向用户,可以更好地响应市场需求。越是多变和激烈竞争的环境越需要频繁发布,以掌握市场先机,赢得竞争优势
  • 开发和产品团队对频繁发布的需求。及早发布、获取即时反馈,能够 技术及业务问题和风险。技术和产品的不确定性越高,越需要频繁发布,以支持快速试错和产品创新。


发布越频繁,对外响应的灵活性越好、越敏捷,持续发布则是最敏捷的。但,确定合理的发布节奏还要考虑额外的成本,包括组织内部的开销和给用户带来的负担:

  • 组织内部的开销:每次发布都给团队带来额外工作,如发布前的打包、测试验证、部署及其它工作。非本地部署系统时,软件分发的成本还会更高。
  • 对外部用户的负担:发布也可能给用户带来负担,如移动应用的每一次发布都需要用户做版本升级;传统电信软件的发布则带来很大的系统升级成本,甚至需要中断线上业务。


确定发布节奏的基本原则

上图总结了确定发布节奏的原则:

频繁地发布,带来更好的敏捷性,而持续发布(单个需求完成后即刻发布)带来最大的敏捷性。但是合理的发布节奏应该是业务和开发团队的要求,与内部和外部开销之间的平衡。


二. 解耦部署和发布

2.1 部署和发布应该是两个不同概念和操作

很多组织把部署等同于发布,认为发布就是在生产系统中部署软件。这带来负面作用,既降低的部署的灵活性,让部署不能随时进行;也增加了发布的风险,可能因技术问题导致发布失败。

为更好的管理发布,团队应该区分发布和部署。部署是属于技术范畴的概念,发布是属于市场范畴的概念。它们的意义分别是:
部署(deployment):将软件安装到一个特定的环境。
发布(release):让一个或一组特性对用户可见和可用。

部署是一个技术决定,而发布则是业务决定

分清并区别对待发布和部署,对提升组织交付能力至关重要。让我们看上图的例子。我写下这些文字是在1月22日,离过年还有5天。支付宝除夕夜红包的功能,大部分应该已经开发完毕,并部署在服务器上了。但是这些功能用户还看不到、用不了,它们部署了,但还没有发布

发布要等到年30当天,分次进行,用户在不同时刻,如18:00和24:00看到的功能是不同的。这些功能都已经提前部署好,即时再通过特性开关之类的机制发布。

部署的功能也并非一定发布。比如,关键节点上可能有多套预案,并根据实际效果和竞争对手的策略,适当调整决定发布什么、不发布什么。

通过上述案例我们知道,部署是技术决策——功能开发和验收完毕就可以部署;而发布则是业务决策——业务需要时才发布。把两者混在一起,就会相互牵扯,想要更持续地部署,却被业务约束及决策拖慢;而业务上更灵活发布也受制于部署能力。

2.2 解耦部署和发布

部署和发布是分属于技术和业务范畴。然而,相当多的产品开发组织还停留在“以部署实现发布”的阶段。为了更持续地部署和更灵活地发布,组织必须解耦部署和发布,也就是:让部署可以独立于发布单独进行;而特性部署后,业务部门可以灵活决定何时发布,向谁发布。

解耦部署和发布是指,让部署可以独立于发布单独进行;特性部署后,业务部门可以单独决定是否要发布、何时发布、向谁发布。

解耦部署和发布是实现持续部署的重要前提,是几乎所有领先的互联网企业的标准实践,它也应该是大部分组织的目标。以下是业界常用的解耦发布与部署的实践。
2.2.1 蓝绿部署

所谓蓝绿部署[1]是指,维护两套尽可能独立的生产环境,一个蓝区,一个绿区。同一时刻其中一个环境在线,用户的访问被路由到这个在线环境。

蓝绿部署

如上图所示,完成的特性先部署到离线环境(图中的蓝区),并做充分验证。一组特性部署完毕后,通过切换路由,变更离线环境和在线环境,就可以发布已部署的特性。而之前的在线环境转换成为离线环境,可以接受接下来的部署。蓝绿部署解耦了部署和发布,通过它团队得到以下好处:

  • 让部署可以持续进行,并在发布前对部署的需求做充分测试
  • 避免部署只能在业务量低潮时集中进行的限制,极大减少凌晨加班部署的痛苦
  • 发布时机的选择更加灵活,不再受制于部署计划
  • 极大降低了发布的风险,出现问题时,可以迅速回滚到先前的生产环境


蓝绿部署是解耦部署与发布较为安全和低成本的方法,它非常实用,但也有局限性,通常只能一次发布所有已部署的功能,灵活性不足。
2.2.2 特性开关

通过特性开关解耦部署与发布

特性开关[2]是提高发布灵活性的常用实践。如上图所示,它包含三个要素。

1)决策点:在业务代码中加入特性开关决策点,根据开关状态,决定启用新的特性,或是维持原先的行为;
2)开关配置区:在集中的配置区设置特性开关,比如某个特性对某类用户是否开启,通常可以通过脚本或图形界面进行特性开关配置;
3)开关路由:用户访问系统时,开关路由会获取用户的属性和特性开关的配置,并由此决策特性是否对该用户开启

应用特性开关,团队可以更持续地部署,并在需要的时候灵活发布,团队得到以下好处:

  • 持续部署并验证特性:可以将特性持续部署到生产环境。特性对用户不可见时,开发团队却可以做线上验证。
  • 大特性分次部署:需要较长时间才能开发完成的特性,可以在整个开发过程中,实现分次的持续部署,全部特性部署完毕后再一次性发布。
  • 针对不同用户灵活发布:可以在单个特性上决定何时发布,以及发布给哪个用户群。有效地支持A/B测试[3]和灰度发布[4],支持产品的实验和创新的同时,降低发布的业务风险。
  • 动态调整特性可见性:特性发布后,可以再行关闭,动态调整特性的可见性。这一功能也可以用于用户权限管理。

2.2.3 模拟环境

蓝绿部署和特性开关适用于本地部署的系统,如:互联网应用和SaaS服务等。需要分发和异地部署的软件则没有这么灵活,比如电信软件要分发并部署到不同运营商的设备当中。

针对非本地部署的软件,创建模拟真实应用场景的环境,并在模拟环境中更持续地部署,可以很大程度上降低发布的风险,并提高组织的交付能力。以下是一些实例:

  • 某微型无线基站团队,每半年对外发布一次正式版本。但产品开发部门,每周都会将最新的软件版本部署到公司食堂的基站中,并称其为“食堂验证”,如果软件版本出现问题,则整个公司员工就餐时就无法刷朋友圈。
  • 某企业网交换机开发团队,每天都将最新软件版本,自动部署到办公环境当中,版本有问题,第一个影响到的是开发团队自己的办公环境。
  • 某提供企业私有云盘的产品团队,每两周会将最新的版本部署到自己公司的办公系统,而他们对外的版本发布是每个季度一次。


尽管模拟部署与真实部署有区别,这些团队还是一定程度实现了部署和发布的解耦。在模拟环境的部署和验证,提供你了尽可能真实的反馈,让产品随时处于接近可发布的状态,为更灵活发布成打下基础。蓝绿部署和特性开关等技术也可以用在虚拟环境中。

蓝绿部署、特性开关和模拟环境,都是解耦部署与发布的有力工具,它们可以独立使用,也可以混合使用,共同提高团队持续部署和灵活发布的能力。
2.2.4 在看板系统中区分部署和发布

在看板系统上解耦

部署和发布解耦后,在看板系统中,应该把它们区分为独立的阶段。如上图所示,开发完成后团队可以自主决定,尽快完成部署,而发布则有业务决定。部署和发布相互独立,可以各自改进。

部署的频率,只由团队当前的技术水平决定,如:单次部署的成本等。持续部署应该是大部分团队的最终目标,团队应该建立软件部署的管道(Pipeline),消除管道中不畅通的节点,并通过自动化等手段不断降低单次部署的成本,为持续部署创造条件。实现持续部署后,部署的节奏也就不存在了。

发布是一个业务决策,持续部署为更灵活发布创造了条件。灵活的发布已经越来越成为竞争优势,最终应该由市场的实际要求和产品的特征决定发布的节奏,而非受制于部署能力。

三. 完美的敏捷愿景


至此,我们用三篇文章介绍了就绪队列填充、看板站会和发布规划会议,它们分别对应着价值的输入、流动过程和输出。通过它们,更好地管理价值流动,也是实现业务敏捷的有效手段。

敏捷交付的完美愿景
从业务视角看,敏捷指:更早地交付价值和更灵活地响应变化。如上图所示,对应价值流动管理,一个组织要达成业务敏捷的最佳状态,需要做到三点:

1)按需填充,以终为始

“按需填充”指:在需要的时候,也就是团队可以投入开发时,才填充需求,此时决策的信息最充分,能够响应最新的业务变化。我们之前建议的每周需求填充,在实践上接近按需填充。

“以终为始”指的是:需求填充时要明确最终的交付和验收标准,确保交付有用的需求,”实例化需求“实践就很好贯彻了以终为始的目标。

2)聚焦价值,快速完成

“聚焦价值”是指:应该按用户价值来组织开发任务,按用户价值限制并行的工作,确保整个团队协调一致,协作完成业务价值;

“快速完成”指的是,在操作上限制过多并行,并即时发现和处理价值流动中不顺畅的地方,确保价值顺畅流动,快速付用户价值。

3)持续部署,灵活发布

“持续部署”是指价值完成后,能够在第一时间部署到生产环境。对分发型软件系统,可以尝试部署到接近真实的模拟环境当中,为灵活的发布创造条件。

“灵活发布”是指:在持续部署的前提下,根据用户的要求和产品的特征,决定何时发布、发布什么、向谁发布。

“按需填充、以终为始;聚焦价值、快速完成;持续部署、灵活发布”,这三点分别对应看板方法中管理价值流动的三个具体实践,也是达成业务敏捷的三个重要方面。

“按需填充、以终为始;聚焦价值、快速完成;持续部署、灵活发布”,从价值交付角度看,这是业务敏捷的完美愿景。团队敏捷和精益实施,应逐步向这个目标靠近。

总结(Take Away)

  • 发布规划会议的目的是规划发布活动,如规划需求的部署或发布,以及安排相关的工作;
  • 为发布规划建立节奏,需要平衡频繁发布的要求和每次发布的成本;
  • 区分部署和发布,部署是一个技术决策和活动,发布是一个业务的决策和活动。区分它们才能更好地管理和改进它们;
  • 应用蓝绿部署、特性开关、模拟环境等技术,解耦部署与发布提高持续部署的能力,根据业务的需要和特征,灵活决定发布的节奏;
  • “ 按需填充,以终为始;聚焦价值,快速完成;持续部署,灵活发布”,从交付视角看,这是支持业务敏捷的完美愿景和目标。




原创:何勉

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:精益看板方法从理论到实战之精益度量体系
下一篇:欢迎你加入iTop社区版主团队
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部