研发效能提升之路——从天文学的演进说起| 学习笔记

简介: 快速学习研发效能提升之路——从天文学的演进说起

开发者学堂课程研发效能提升和敏捷实施36计研发效能提升之路——从天文学的演进说起】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/615/detail/9379


研发效能提升之路——从天文学的演进说起

内容介绍:

一、前期课程内容回顾

二、天文学的演进

三、研发效能的提升之路

 

一、前期课程内容回顾

1、精益和敏捷协作

可视化端到端的交付过程

管理价值流动过程

度量反馈和持续改进

image.png

1)让可视化能够看到开发的过程和问题所在

2)需求要流动起来

image.png

(3)通过4步的方法来看怎样可视化的需求交付过程,就是怎样把价值流可视化出来,

分别是:

用户价值驱动、前后拉通职能、左右模块对齐、定义流动规则。

(4)三个标准告诉怎样检验可视化的效果,保证可视化为效能提升,然后建立一个较好的基础。

这是一个理念,更是一个能落实到工具的实践,可视化奠定了一个端到端顺畅流动的一个基础,因为它让我们看到问题,看到流动的过程,我们才能够去管理它,但可视化是手段不是目的。

image.png

(3)怎样让需求流动的更快,所以第一点需要限制在制品的数量

(4)湖水岩石,湖水的水位代表的是地形需要的数目即在制品的数量,也就是减少地形,减少地基或者是缩短周期时间,来暴露问题

image.png

(3)让流动过程有节奏感

8)是一个指导方式,从解决这些问题的方式来保证整体节奏,通过这些节奏,各种实践让价值真正的流动起来

2、研发效能的度量体系

image.png

(1)度量需要回答一个本质的问题:

持续快速、高质量地交付价值能力,这些度量合在一起可以讲述一个完整的故事:分别从资源效率、流动效率、质量保障三个方面来整体度量一个发酵过程

image.png

(1)有了度量,便提出愿景目标,即定义北极星,体现出理想,方向和现状,找到改进机会,然后促进整体的改进。

 

二、天文学的演进

image.png

八大行星是:

水、金、地、木、火、土;中国人讲天圆地方,而罗马人讲地心说,地心说必须解释这些行星的形状为什么是这样?

除了解释以外,我们可以通过行星的规律画出星标图,星标图又可以指导航海,能够让人知道方位,适合预测行星的轨迹

image.png

古罗马人的解释:

行星绕着地球转,称为均轮;行星绕着图中黑点转,称为本轮。

地心说模型:模拟出了水星的轨迹

image.png

托勒密(100AD-168AD

地心说的理论和精确计算体系的构建者其思想统治了后世1500

日心说模型:

地球绕着太阳走,行星也绕着太阳走,看行星投影的位置,因为速度不一样,位置也会由位置差。

image.png

哥白尼(1493-1543

日心说模型的提出者(他认为行星的运行轨道是正圆,建立在地球是自转的基础上 )

开普勒(1571-1630

(他每365天取一个数据发现地球没动而火星在动)

揭示了行星运动规律,被称为天空立法者

第一定律:

行星的运动轨道是一个椭圆,太阳位于椭圆的一个焦点(椭圆有两个焦点,位于一个焦点上)

第二定律:

相同时间内,行星到太阳的连线扫过的面积相等(如图,p3p4p1p2的面积是相等的,而行星离太阳近的时候速度快,所以基本能够确定行星在什么时间到哪个地方)

image.png

7个椭圆完全解释了行星运动的规律,而且是本质上的分秒不差

image.png

回顾:

从托勒密的80多个圆第一次解释并预言了行星运动的轨迹(有一天以内的误差),再到哥白尼,他用34个月提出了更简单的模型日心说,但开普勒用7个椭圆精确地预测了7颗行星的运行轨迹。

这个过程越来越简单、本质、有效。从这三次革命就是一个范式的改变。首先是思想、模型的转变。

 

三、研发效能的提升之路

主要讲产品开发,产品创新的课程

1.  用户-公司:

公司组织-用户 (过去是用户以组织为核心,现在是公司以用户为核心)

2.  组织和资源为核心:

用户价值为核心,需要从以组织和资源为核心转变为以用户价值为核心。

3.  资源效率-流动效率:

资源效率即开发代码的数量,做测试的次数,看各个局部的资源变成效率,流动效率即对用户需求的响应,从需求导出的过程的顺畅程度,周期时间的缩短状况。

4.  产品功能-客户问题:

从关注产品功能转变到关注客户问题,这是讲需求的核心,首先需要去理解需要·解决客户什么问题,接下来讲实现客户问题的过程;倡导企业来满足客户问题,做一个产品功能,最后规划在交付节奏时怎么实现客户的场景,解决客户的问题,最后是否解决客户问题要形成一个反馈。

5.  项目交付-产品沉淀:

在介绍工程的技术部分,代码设计实践的时候,不仅仅是交付项目还有产品的沉淀,同样也是围绕用户;因为项目交付出去不代表成功,需要长期成功,产品有沉淀才能长期服务好客户用户。

6.  局部效率-高效交付-业务成功-持续高效:

(1)局部效率不等于高效交付,即局部效率例如开发、测试、前端、后端或者是产品、运营等;

(2)高效交付了不代表业务成功,因为交付的东西仅仅是交付产品、功能,并不代表解决了客户的问题;

(3)即是高效交付,不等于持续高效,所以一定要有产品的沉淀,所以提出了三个核心的转变:

以流动效率为核心,提升团队交付的能力;

以用户价值为核心规划和探索有效的产品;

③以长期质量为核心沉淀优秀软件资产和工程能力)

7.研发效能提升之道(为了把用户放在核心而不是把组织放在核心)

(1)流动效率:提升团队的持续交付能力

(2)客户价值:规划和探索有效的产品

(3)长期质量:沉淀优质的软件资产和工程能力

8. 以流动效率为核心,提升团队的持续交付能力

image.png

流动效率

(1)可控:管理价流动,让价值流动起来

(2)可见:用户价值流动过程,奠定改进的基础

(3)可度量:度量价值的流动,激发持续改进

9.课程分析:

先讲解决用户的问题究竟是什么;怎么定义用户的成功;目标又是什么,不仅我是功能性的目标、还有情感性的和社会性的目标;怎么来定义目标的成功标准,怎么来实现目标的过程,服务蓝图是什么样;除了用户目标还有业务目标,怎么实现业务目标,实现业务目标会影响用户的行为,为此需要做某个功能让两个目标出发;

澄清了目标,定义了目标怎么来设计产品的方案,并且把它转化为可以迭代交付的产品的规划,也就是应该交付哪些东西;

10.客户价值:

从用户问题出发,设计产品需求(首先要理解用户问题,搞清楚用户问题的本质,然后依据本质去设计产品需求)

基于业务目标,设计产品需求(从业务目标出发,去设计产品需求,找到实现目标的办法,为了使办法有效,我们应该如何设计需求或运营手段)

以业务场景组织和规划需求(组织好需求,并有效快速的迭代)

以终为始,高效分析和澄清需求。

整个太阳系来说,哪里有什么水逆。从来都没有水逆,需要转变的是,看待问题的角度。

image.png

相关文章
|
3月前
|
Cloud Native 持续交付 开发者
"云原生时代,开发者如何坐拥创新利器,秒变技术大牛?揭秘黄金时代背后的秘密武器与无限可能!"
【8月更文挑战第14天】云原生技术的兴起标志着软件开发进入黄金时代。它不仅是一种技术趋势,更是思维的革新,赋予开发者前所未有的灵活性和效率。通过微服务、容器化等技术,云原生加速了创新迭代,提升了资源利用与成本效益,增强了应用的可靠性和韧性,并促进了团队间的协作与知识共享。这一切都为开发者创造了更多机遇与挑战。
38 1
|
3月前
|
机器学习/深度学习 人工智能 运维
运维自动化之路:从传统到现代的演进之旅
【8月更文挑战第13天】在数字化时代的浪潮中,运维领域经历了翻天覆地的变化。从手动执行命令的传统方式,到现如今通过自动化工具和平台实现高效管理的转变,本文将带您领略运维自动化的发展历程、面临的挑战及应对策略,以及未来趋势的展望。
|
3月前
|
人工智能 运维 监控
运维自动化之路:从手动到智能的演变
【8月更文挑战第8天】在数字化时代的浪潮下,运维自动化不再是一个选择,而是企业生存和发展的必由之路。本文将探讨运维自动化的必要性、演变过程以及实施策略,旨在为读者提供一条清晰的路径,以实现从传统手动操作到智能化管理的飞跃。
|
4月前
|
人工智能 监控 前端开发
前端架构(含演进历程、设计内容、AI辅助设计、架构演进历程)
前端架构(含演进历程、设计内容、AI辅助设计、架构演进历程)
77 0
|
6月前
|
人工智能 监控 算法
编程中的解密之路:挑战、创新与技术难题的探索
编程中的解密之路:挑战、创新与技术难题的探索
|
6月前
|
消息中间件 存储 缓存
阿里P8架构师带你“一窥”大型网站架构的主要技术挑战和解决方案
传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非功能性需求;功能性需求也许还有“人月神话”聊以自慰,通过增加人手解决问题,而非功能需求大多是实实在在的技术难题,无论有多少工程师,做不到就是做不到。
|
算法 程序员 数据库
程序员的研发效率破局之道
程序员的研发效率破局之道
77 0
|
程序员 测试技术 开发者
「程序员转型技术管理」必修的 10 个能力提升方向
对许多开发者而言,深耕技术,然后成为技术专家或许是职业发展的唯一答案。但如果你赞同「软件开发只是我众多职业目标中的一个」,也许你可以试试「技术管理之路」。 我原来觉得和计算机打交道比跟人打交道轻松得多,所以我成了一名软件开发者。一段时间后,我发现自己越来越多地在给别人提供帮助;我喜欢领导项目,热衷于推动更好的代码标准。于是,我几乎毫无挣扎地成为了一名技术管理者。
103 0
|
架构师 搜索推荐 IDE
架构师13年经验而成的软件平台架构设计与技术管理之道终于曝光了
计算机技术的发展日新月异,市面上软件架构、项目管理、IT技术类书籍层出不穷,从软件专业和技术视角进行阐述的居多,但对技术烂熟于胸,还是无法保证你能成为优秀架构师或驾驭平台的技术负责人。
《研发效能36计:研发效能提升之路,从天文学的演进说起》电子版地址
研发效能36计:研发效能提升之路,从天文学的演进说起
147 0
《研发效能36计:研发效能提升之路,从天文学的演进说起》电子版地址
下一篇
无影云桌面