持续交付2.0(一至三章)
一、持续交付2.01.1 软件工程发展1、瀑布软件开发传统的瀑布软件开发模型每个阶段都花费属于的实际那,需要花费大量的经历确定需求的范围,审核繁杂的需求规格说明书,确定需求范围复杂。2、敏捷软件开发提倡面对面沟通,拥抱变化,提倡通过迭代和增量开发今早交付有价值的软件,软件开发实际是一个不断迭代学习的阶段。瀑布只有在项目交付后期才可以看到软件的实际运行。敏捷开发采用迭代模型,但是软件发布之间的间隔较
读乔梁先生《持续交付2.0》摘要,前三章持续交付、价值探索环、快速验证环。
一、持续交付2.0
1.1 软件工程发展
1、瀑布软件开发
传统的瀑布软件开发模型每个阶段都花费属于的实际那,需要花费大量的经历确定需求的范围,审核繁杂的需求规格说明书,确定需求范围复杂。
2、敏捷软件开发
提倡面对面沟通,拥抱变化,提倡通过迭代和增量开发今早交付有价值的软件,软件开发实际是一个不断迭代学习的阶段。
- 瀑布只有在项目交付后期才可以看到软件的实际运行。
- 敏捷开发采用迭代模型,但是软件发布之间的间隔较长。需求变更&研发效率是主要矛盾,部署发布&运维矛盾较小。
3、DevOps发展
DevOps目前没有统一的定义,正如每个人理解敏捷是不一样的。目标是缩短开发周期,提高部署频率和刚可靠的发布,与业务目标一致。
4、持续交付1.0
部署流水线:
- 每个隔间阶段都应该交付可工作的软件,中间产物的生成不应该是独立的阶段。(绿厂互联网的流水线建设)
- 同一个制品向不同类型的环境部署,且运行时的配置分开管理。(Apollo)
- 自动化测试和部署,根据测试的目的,分为几个独立的质量关卡。(流水线测试卡点)
- 部署生产线设计应随着应用程序的发展而不断演进。
组织角色触达:
5、持续交付与持续部署。部署是技术领域的,交付是业务决策。交付可理解为上线、发布,部署可能有多次,而在业务需要时,才会交付。
1.2 持续交付2.0
1、精益思想
《精益创业》线产生最小化的可行性产品,而非玩么牛的产品,在经过快速迭代与持续修正,资源耗尽前实现市场需求。
- 精益创业是“开发–测量–认知”的验证学习过程。
- 按照价值流来组织全部生产活动是价值在生产活动之间流动,需求拉动产品的生产,识别生产过程中不经意间的浪费产生。
- 业务生产活动分为增加价值的活动和不增加价值的活动,后者归为“浪费”活动中,浪费活动分为必要的增值活动和纯粹的浪费。{有价值,无价值[必要浪费,不必要浪费]}。EG:流水线上的装配工作是增值活动,质量检查是非增值活动,因材料不足而生产等待和质量缺陷的返工都是不必要的浪费。
2、双环模型【★】
-
产品研发管理思维框架,是产品与研发的快速闭环,以“精益思想”为指导,全面贯彻“识别和消除一切浪费”的理念。有可持续方式、高质量、低成本、无风险的快速交付客户价值。
-
”8“字环,第一个为**“探索环”,目标为识别和定义业务问题,制定最小可行解决方案;第二个为“验证环”**,目标为一最快速度交付最小可行环,可靠的收集真实反馈,并分析和验证业务问题的解决效果。,以确定下一步的行动。
探索环:
- 提问,即定义问题。通过有针对性行的提问,找出用户具体需求,并找出具体需求后的原因,即要解决的根本问题。
- 锚定,即定义结果目标指示器。经过分析,去除干扰信息,得到适当的衡量指标,并表述现在的状况和行动预期的结果。
- 共创,制定目标后,团队设法验证或者达成目标,而探索多种可行性解决方案。
- 精炼,即对所有的可行方案进行选择,找到最小可行性解决方案(单个或者多个混合)。
验证环:
- 构建,最小可行性解决方案转化为符合质量需求的软件包。
- 运行,部署到生产环境或者交到用户手中,并使之为用户提供服务。
- 检测,生产系统的系统和数据监控,保证运行,并将业务数据以适当的形式展示。
- 决策,数据分析与目标对比,决策下一步方向。
3、四个核心原则:
- 坚持少做。想做的事情永远超出自己的交付能力,即使在微软,也只有1/3的新特性成功改进了关键指标。
- 持续分解问题。
- 坚持快速反馈。快速反馈工作的结果。
- 持续改进并衡量。
二、价值探索环
2.1 探索环的意义
1、探索环的目标与价值假设
就是持续事变和定义这些有价值的假设,选择并验证其中风险最高的或者最易验证的价值假设,并截止价值验证环得到数据反馈,以便深入理解用户需求,把我业务前进方向。假设来源:
- 用户假设:潜在用户的需求假设
- 问题假设:问题点痛点的需求假设
- 解决方案假设:提供的方案可以解决这些痛点或问题点,且比其他方案高效
EG:持续交付工具GoDC,设计200多个功能特性,一半都废弃掉,说明假设的不成立。该产品实际一直秉承“持续交付2.0”,调整功能策略,实现成功。
2.2 探索环的四个关键
1、提问
不断提问,澄清客户需求背后真正要实现的目标。
EG:举办DevOps的沙龙,客户要咖啡。问了一堆要什么口味的咖啡、多热的咖啡、什么时间、中杯大杯。
其实问的都是“做什么”和“怎么做”,而没有去问及原因。客户真正的诉求是担心困意而错过听讲。此时,我们的解决方案有多种,比如录制视频,即使参与者中途离场,也可以回顾内容。
2、锚定
-
避免模糊不清的目标,这样会影响团队的交流。清晰的描述目标让我们知道自己当前的位置,清晰的目标是具体且可衡量的,有时间限定。若没有时间限定,则将会成为一个愿景,无法直接知道企业日常生产管理的活动。
EG:某App用户量当前为20万,年底愿景为200万。
所以我们可以根据新闻信息流服务(Feed流),我们期望用户喜欢该App,那么可以推断:
- 用户会阅读更多的内容,花费更长的时间
- 用户会将该产品推荐给朋友,而朋友也会喜欢并成为该产品的用户。
-
根据分析可以得出三个衡量指标:推荐朋友数、单位时间内的用户数、单个用户的平均使用时长。制定指标后,各个团队根据自身职责制定目标如:提高API的请求响应速度、后台稳定性等等。
-
目标选择应该尊新:
- 识别价值目标而非虚荣目标。
- 指标应该是可衡量且可获取,易于客观对比。
3、共创
解决方案基于假定条件或者猜想,提供两种分析方法:
-
量化式影响地图(目标–角色–影响–方案–量化、Why-Who-How-What)。
EG:以20万到200万为例。涉及到的角色有App使用者、推广渠道、客服团队、产品研发和运营、内容提供商及更多角色。
以推广渠道商为例
- 影响:App的展示位置、App的曝光量、App审核速度
- 方案:购买展位、搜索优化、规范更新
- 量化:App的下载指标
-
用户陆行地图(可视化的方式,讲用户与产品或服务之间的活动按照业务流进行展示)
- 地图包含:用户接触点、接触阶段、用户痛点、用户情绪
- 制作步骤:定义用户、定义任务或阶段、用户与服务接触点的互动行为、用户的动机、用户心理
共创的两周
共创的两个陷阱、极端:分析瘫痪(过度分析,无法决策)、直觉决策(匆忙判断,直觉反应)
4、精炼
筛选最小可行性方案。
2.3 工作原则
1、分解快速验试错
与“一次到位式”的解决方式不同。采用低成本的快速验证,多次尝试,多种方法,多种成功方式。
2、一次只验证一点
验证方案只是手段,非目标。
3、允许失败
2.4、共创和精炼常用方法
1、装饰窗方法
EG:提现的功能,产品为评估到实现周期较长,则可以线用一个虚假的按钮,如用户点击“提现”时,提示“功能未实现,请预留手机信息,实现后第一时间提心您”,从而收集用户点击意愿,快速收集用户反馈,决定是否做该功能。
2、最小可行特性法
EG:还是提现的功能,可以提示“功能开通成功”,后台收集用户信息,通过人工财务方式,实现该功能,并不涉及到系统的开发。用来短时间内收集用户意愿,验证用户是否喜欢该功能。
3、特区法
制定用户范围内进行试验,验证某个功能是否有效,不会影响特区意外的用户体验。一般用于资源有限、成本敏感的场景。
EG:还是提现的功能,按照装饰窗方法,若120个用户提交手机信息,功能实现后,可以根据120用户手机号发送短信,包含提现的连接,查看用户点击该链接完成提现的人数(如:33个商户提现成功,7个商户提现1次,1个商户提现8次)。
4、定向探索法
是指某种特定行为的特定用户群体,依据改用户的具体行为模式,设计调查提纲,针对性探索其背后的动机。根据特区法的不同商户提现结果,分别设计调查问卷,理解用户行为。
5、稻草人法
与装饰窗方法的区别是不开发任何真实功能,假装该功能已经实现。采用人工或其他方式,模拟实现,获得用户反馈。
6、最小可行产品法
通常在产品0-1的过程中使用。如Zappos最早就是开发一个UI界面,然后用户下单后,手工发货。
三、快速验证环
3.1 验证环的目标
借助各种方法和工具,让质量可靠的解决方案以最快的速度达到客户手中,收集分析真实的反馈。
3.2 验证环的四个关键
1、构建:讲自然语言描述转换为计算机可以执行的软件。
- “时间盒”管理法。涉及交付物、交付质量、截止时间,了解项目状态,风险并解决。
- 任务分解。持续交付2.0核心工作原则,包含需求拆分和开发任务拆分。
- 持续验证。每当完成意一项开发任务或者需求,立即对交付质量进行验证,而非多项交付一起验证。持续验证会耗费较高成本,可以采用“持续集成”或者“自动化测试”方式,降低回归成本。
2、运行:将软件包部署生产环境,并对外提供服务。
- 如何无感的升级版本是重要课题,主要矛盾在开发和运维之间。
3、监控:收集数据源并统计展示,及时发现生产问题和业务指标异常的数据。
4、决策:收集真实的业务数据反馈结果之后,根据探索环中确定的相应指标进行分析对比,验证是否符合最初预期。
3.3 工作原则
包含:质量内建、消除等待、尽量并行、检测一切。
1、质量内建。从生产过程的第一个环节开始,就注重产出物的质量,并在每个环节开展质量保证。与后期大规模检查概念完全相反。
2、消除等待。精益思想中关于“浪费”有定义,“等待”的本质就是非必要浪费。正确做法是扩大“瓶颈”的处理能力,本质解决为需求颗粒均匀化,构建各环节工作量相近的需求。 同时进行任务的自动化建设。
3、重复任务自动化。如测试环境搭建、回归测试、应用发布和部署,都可以通过优化流程和自动化措施降低事物性成本和人为造成的失误。
4、检测一切。检测收集数据,便于确认生产环境软件正常运行(应用健康检测),也便于收集有效业务数据,验证探索环的假设(业务健康假设)。
更多推荐
所有评论(0)