【软件工程，GJB5000∶研发效能模型】
零. 研发效能模型是什么？
研发效能模型定义了从研发过程→领域模型→指标体系→数据模型的标准设计体系，它的目的是可以用数据来的刻画真实研发过程，研发效能模型总体分为三部分：
研发过程：观察研发实际情况，定义我们要刻画的软件研发过程的核心概念，转化为研发活动和原子指标（也称为“度量”）。
领域模型&指标体系：基于我们的分析目的（比如评估研发效能评估、效能诊断等等）、结合软件工程领域知识，对研发过程抽象、建模，再依据模型，把一个或多个具体研发活动中需要关注的信息整合起来，提炼出关键的指标，输出指标体系。
数据模型：依照大数据设计体系，将上述交付件进行数据设计，转化物理表，输出数据模型。
一、研发效能模型基础概念理解
1、“效能”是什么？
“效能”这个词的原意是指事物所蕴藏的有利的效用能量，主要从能力、效率、质量、效益这四个方面体现出来。简单的说，是“做正确的事情，正确的做事”。首先确保做的事情有价值，其次再确保做的事情能够多、快、好、省，即最短的时间用更少的成本做更多的事情。
2、“度量”是什么？
度量是在一个特定组织上下文中形成的一系列共识。它的本质是组织内部对要实现的目标量化之后，形成的一种内部统一的术语。在语言一致的情况下，才可以用度量来量化设定的目标并观察目标的达成情况。
度量是什么：
在组织上下文中形成的一系列共识。
将经验性模型向量化模型进行的匹配。
包括人、流程、组织和工具的一个动态系统。
度量不是什么：
软件开发固有的活动。
跟绩效直接相关。
免费的。
3、软件领域“效能度量”如何做？
引用《精益软件度量》一书中对软件效能度量的解读：
我们假设业务策略能够准确、及时的传递到研发组织，那么业务对开发组织的期望可分为四类：
价值：交付产出物带来的业务价值。常用指标有价值命中率，用户满意度等。
质量（好）：过程表现以及线上表现。
效率：包括对市场的响应速度和单位规模开发组织的产能。
响应速度（快）：意味着先发优势，尽快响应客户，同时又能确保更早的收集反馈，验证判断、做出调整。常用指标有版本发布频率、平均交付周期、研发前置时间、客户前置时间等。
团队产能（多）：是指单位工作时间内的良品的产出数。在软件领域，把研发过程比作管道，产能就是管道的吞吐率，即单位时间内所能交付的软件规模（也成为单位时间内的产量）。常用指标如需求吞吐量。
能力：对上述因素的直接影响要素。比如个人开发能力（人均代码量、人均缺陷率等）、工程能力（流水线平均时长）、团队作战能力（团队负载度、团队并发度）、环境使用效率（环境使用率、机器配置使用水位）等等。
这几个维度具有一定的平衡性，但是也存在优先级，一般来说：
价值是最优先的，然后依次是质量、效率，最后评估能力。
原因很容易理解，如果价值低，说明没有做正确的事情，做的再快也没有好的结果。如果质量差，效率则没有意义，也就是说必须做到“有质量的快”。最后，如果价值、质量、效率都能达到一定的水平，再去评估能力，能力强，说明人或者团队或者工具具备每一次都能做好的基础。
二、研发效能评估思路
既然要提效，那么我们首先要回答三个问题：什么是研发效能、研发效能如何评估、如何先找到问题并持续调优。
1、什么是研发效能？
“效能”这个概念本身有很多解释，比如字面理解就是“效率*能力”或者“做正确的事+正确的做事”，比如《精益软件度量》中总结的“价值、质量、效率、能力”。但是映射到实际情况，从业务对软件研发团队的“效能”的感知的角度看，我们认为比较契合的还是Capital one的这句口号——“Deliver High Quality Working Software Faster”。试想一下，如果把研发团队整体看做是一个“生产工厂”，业务方最关心的就是你的这家工厂，能否持续的满足业务需求，能否持续的做到“有质量的快”，如果能做到，那么在此基础上，可以再看下你的投入，自然是越低越好。
2、研发效能如何评估？
（1）流动效率：结合业务架构、软件架构和研发组织架构，把研发过程抽象并“具象化”，我们会得到一个类似管道一样的模型，输入就是原始的“业务需求”，它经过设计&拆解变为“应用需求”（也可叫微服务需求），再经过开发人员编码实现、构建成可运行的软件包，最后发布到线上。按照精益的定义，我们首先要关心“流动效率”，围绕它定义关键指标。
（这里有一个点要澄清一下，在精益的理论中，流动时间（Flow time，一个工作单元从管道一端流动到另一端的时间）和吞吐率（Throughput，单位时间内通过管道的工作单元数量）都是属于“流动效率”，它们都是用来衡量研发管道的效率，同时精益思想也建议我们应该优先关注“流动效率”，确保价值可以最快速度的传递，其次才是“资源效率”。）
当然，这里隐含着一个难点就是“需求粒度”，不同的需求量，交付的周期肯定是有差别的，而在软件工程领域目前并没有一个精确的方式可以衡量一个需求的“粒度”，人天、点数、代码行无论是哪一种方法都有它的问题和局限性。
（2）资源效率：资源效率指的是各环节的资源利用率和产出情况，它影响了整个“管道”的流速。具体我们又拆分为了2个关键的要素：
团队能力：流动效率分解到资源效率，从人员的角度上的一个指标就是团队中参与开发的人员的“产能”（一个开发人员单位时间内交付的软件规模）。但是在软件工程领域，人的产能也同样没有通用、科学的度量衡，因此我们就再进一步拆解为人员投入、人员能力、以及工作效率，其中比较容易观察和衡量的就是工作效率，工作效率指研发人员使用每一个研发工具完成必要活动的效率。
工程能力：工程工具也是一个综合性、复杂性的系统工程，持续交付流水线以及测试能力决定了在代码在集成、验证、发布阶段的流动效率（全自动化的前提下），研发各类辅助工具会影响研发人员的产出，而基础设施则决定了整个工具链的底层效率和稳定性。但是好在，这些都是机器的事情，只要持续的拆解，每个过程都是客观的、可以度量的。
按照以上的理解，我们就获得了一个分层的评估方式：
（1）组织效能：即常说的业务结果或业务价值，通常约等于组织的KPI，包括生产力、盈利能力和市场份额，以及效率、客户满意度等非商业衡量指标。
（2）软件研发效能（SDO）：即通俗所讲的广义上的“研发效率”，它可用来评估软件研发团队是否能够支撑组织效能的达成。比如在一定的投入产出下是否做到了“有质量的快”、或者在一定交付质量&效率的情况下内是否有更多的产出、更小的投入。
（3）软件研发能力：决定了研发效率的关键因素。研发效能的提升必须要落在工程、技术和研发者上，这些因素共同决定了软件研发效能的结果。对于团队Leader来说，关注软件研发能力指标和改进，可有效提升整体团队的研发效能。
3、如何先找到问题并持续调优？
基于上述的评估方式，我们可以构建一套用来评估和诊断的模型体系，帮助研发效能持续的提升。此需要强调的是我们的一个基本观点：“模型的本质是对规律的洞察，而上帝不会告诉我们规律，只会展示给我们数据”，因此，我们虽然基于观察和经验构建了逻辑模型，但是会带入大量的团队数据并结合实际进行验证，最终把它转换成“基于数据构建的可验证模型”，只有这样才能确保它是贴近事实的。
三、研发效能体检模型-全景图
1、评估对象
按“团队维度”评估，因为团队综合了软件交付的载体“应用”以及关键要素“人”。团队的最高层级为“集团公司”，俗称“全站”，下一级是集团的九大BU，最小级别为一线TL团队，90%的评估指标都是可以按团队维度分解的，即在全站看到的一个问题指标，可以逐层分解到最小的TL团队。一线TL团队再向下分解则是团队负责的某一个“应用”或者某一个“人”，但是由于团队中“人”和“应用”很难有一一对应的关系，因此综合评估的模型会部分失效，比如，如果具体到某一个应用，那么“工程能力”的评估是有意义的，但是“团队能力”的评估则是无效的。
2、模型特点
（1）系统性：展示了影响效能的关键要素、关键指标以及它们之间的关联关系。
（2）抽象性：将业务特点、软件架构、软件研发团队、研发过程，进行抽象，投影到了一个二维的研发过程模型（类似一个管道，又称“研发管道模型”）中，确保模型既符合研发特点，又在软件工程上具有一定的通用性，一定程度上反映了软件研发的基本规律。这样一来，这套模型可以兼容团队间差异（团队各有特的特点，但是都在模型定义范围内）以及架构差异（ServiceFul、ServiceLess存在差异，但是都在模型定义范围内）。
（3）准确性：每一套指标均用集团全站数据以及通过采样选择的具体团队数据带入验证，既具有统计学意义，同时又确保贴近事实，反应团队实际情况。
（4）动态性：模型不是静态的，虽然总体分类不变，但是每一项中的评估指标都会随着集团业务变化、研发体系演进以及组织对研发团队要求演进。
3、模型中的因果性和相关性
（1）基本概念
因果关系：当一个作为原因的要素的数据变化时，另一个作为结果的要素在一定程度发生变化，两者存在着必然联系。
相关关系：当一个要素的指标变化时，有一定的概率会引起另一个要素的指标也可能随之变化，但是两者不存在必然性。
（2）效能模型中的因果性
每一个要素的指标可继续拆解，分解出具有因果关系的子指标。
比如，迭代平均周期，可以拆解为“开发阶段周期 + 集成阶段周期 + 灰度&发布阶段周期”，
当然，也可拆解为N个迭代周期平均值。拆解之后，任一子指标出现问题，必然会影响主指标。
因此，合理使用主子指标间的因果关系，可以起到问题定位的作用。
（3）效能模型中的相关性
效能模型中的要素与要素之间虽然相互影响，但是并非因果关系，而是存在相关性，比如研发能力中的某些指标变差，一定程度上会影响研发效率，例如“工作效率”中的很多指标显示效率低下，就有可能影响“交付周期”变长，但是这并不是必然的，有可能“人员能力”中相关指标更优，冲抵了“工作效率”的变化。但是即使如此，合理使用不同要素指标之间的相关性可以达到综合性提升的效果，理论上，如果“研发能力”体检之后所有的指标良好，那么“研发效率”的指标也不会差。
全景图中的“黑线”呈现的就是要素之间的相关性：
“研发能力”影响“研发效率”。对应精益理论，资源效率一定程度上影响流动效率。
团队能力中，“工作效率”影响“人员产出”，“人员能力”影响“人员产出”和“工作效率”。
工程能力中，“工具效率”直接既影响研发过程相关阶段（比如预发、灰度、发布）的流动效率，又影响人的“工作效率”（如编码、提交、验证等）。
而“质量保障”和“基础设施”会影响“工具效率”，并最终反映到研发过程效率和人员产出上。
转∶
原文链接
https://t.cn/A6Twm2WH
namo-amitabhaya！
零. 研发效能模型是什么？
研发效能模型定义了从研发过程→领域模型→指标体系→数据模型的标准设计体系，它的目的是可以用数据来的刻画真实研发过程，研发效能模型总体分为三部分：
研发过程：观察研发实际情况，定义我们要刻画的软件研发过程的核心概念，转化为研发活动和原子指标（也称为“度量”）。
领域模型&指标体系：基于我们的分析目的（比如评估研发效能评估、效能诊断等等）、结合软件工程领域知识，对研发过程抽象、建模，再依据模型，把一个或多个具体研发活动中需要关注的信息整合起来，提炼出关键的指标，输出指标体系。
数据模型：依照大数据设计体系，将上述交付件进行数据设计，转化物理表，输出数据模型。
一、研发效能模型基础概念理解
1、“效能”是什么？
“效能”这个词的原意是指事物所蕴藏的有利的效用能量，主要从能力、效率、质量、效益这四个方面体现出来。简单的说，是“做正确的事情，正确的做事”。首先确保做的事情有价值，其次再确保做的事情能够多、快、好、省，即最短的时间用更少的成本做更多的事情。
2、“度量”是什么？
度量是在一个特定组织上下文中形成的一系列共识。它的本质是组织内部对要实现的目标量化之后，形成的一种内部统一的术语。在语言一致的情况下，才可以用度量来量化设定的目标并观察目标的达成情况。
度量是什么：
在组织上下文中形成的一系列共识。
将经验性模型向量化模型进行的匹配。
包括人、流程、组织和工具的一个动态系统。
度量不是什么：
软件开发固有的活动。
跟绩效直接相关。
免费的。
3、软件领域“效能度量”如何做？
引用《精益软件度量》一书中对软件效能度量的解读：
我们假设业务策略能够准确、及时的传递到研发组织，那么业务对开发组织的期望可分为四类：
价值：交付产出物带来的业务价值。常用指标有价值命中率，用户满意度等。
质量（好）：过程表现以及线上表现。
效率：包括对市场的响应速度和单位规模开发组织的产能。
响应速度（快）：意味着先发优势，尽快响应客户，同时又能确保更早的收集反馈，验证判断、做出调整。常用指标有版本发布频率、平均交付周期、研发前置时间、客户前置时间等。
团队产能（多）：是指单位工作时间内的良品的产出数。在软件领域，把研发过程比作管道，产能就是管道的吞吐率，即单位时间内所能交付的软件规模（也成为单位时间内的产量）。常用指标如需求吞吐量。
能力：对上述因素的直接影响要素。比如个人开发能力（人均代码量、人均缺陷率等）、工程能力（流水线平均时长）、团队作战能力（团队负载度、团队并发度）、环境使用效率（环境使用率、机器配置使用水位）等等。
这几个维度具有一定的平衡性，但是也存在优先级，一般来说：
价值是最优先的，然后依次是质量、效率，最后评估能力。
原因很容易理解，如果价值低，说明没有做正确的事情，做的再快也没有好的结果。如果质量差，效率则没有意义，也就是说必须做到“有质量的快”。最后，如果价值、质量、效率都能达到一定的水平，再去评估能力，能力强，说明人或者团队或者工具具备每一次都能做好的基础。
二、研发效能评估思路
既然要提效，那么我们首先要回答三个问题：什么是研发效能、研发效能如何评估、如何先找到问题并持续调优。
1、什么是研发效能？
“效能”这个概念本身有很多解释，比如字面理解就是“效率*能力”或者“做正确的事+正确的做事”，比如《精益软件度量》中总结的“价值、质量、效率、能力”。但是映射到实际情况，从业务对软件研发团队的“效能”的感知的角度看，我们认为比较契合的还是Capital one的这句口号——“Deliver High Quality Working Software Faster”。试想一下，如果把研发团队整体看做是一个“生产工厂”，业务方最关心的就是你的这家工厂，能否持续的满足业务需求，能否持续的做到“有质量的快”，如果能做到，那么在此基础上，可以再看下你的投入，自然是越低越好。
2、研发效能如何评估？
（1）流动效率：结合业务架构、软件架构和研发组织架构，把研发过程抽象并“具象化”，我们会得到一个类似管道一样的模型，输入就是原始的“业务需求”，它经过设计&拆解变为“应用需求”（也可叫微服务需求），再经过开发人员编码实现、构建成可运行的软件包，最后发布到线上。按照精益的定义，我们首先要关心“流动效率”，围绕它定义关键指标。
（这里有一个点要澄清一下，在精益的理论中，流动时间（Flow time，一个工作单元从管道一端流动到另一端的时间）和吞吐率（Throughput，单位时间内通过管道的工作单元数量）都是属于“流动效率”，它们都是用来衡量研发管道的效率，同时精益思想也建议我们应该优先关注“流动效率”，确保价值可以最快速度的传递，其次才是“资源效率”。）
当然，这里隐含着一个难点就是“需求粒度”，不同的需求量，交付的周期肯定是有差别的，而在软件工程领域目前并没有一个精确的方式可以衡量一个需求的“粒度”，人天、点数、代码行无论是哪一种方法都有它的问题和局限性。
（2）资源效率：资源效率指的是各环节的资源利用率和产出情况，它影响了整个“管道”的流速。具体我们又拆分为了2个关键的要素：
团队能力：流动效率分解到资源效率，从人员的角度上的一个指标就是团队中参与开发的人员的“产能”（一个开发人员单位时间内交付的软件规模）。但是在软件工程领域，人的产能也同样没有通用、科学的度量衡，因此我们就再进一步拆解为人员投入、人员能力、以及工作效率，其中比较容易观察和衡量的就是工作效率，工作效率指研发人员使用每一个研发工具完成必要活动的效率。
工程能力：工程工具也是一个综合性、复杂性的系统工程，持续交付流水线以及测试能力决定了在代码在集成、验证、发布阶段的流动效率（全自动化的前提下），研发各类辅助工具会影响研发人员的产出，而基础设施则决定了整个工具链的底层效率和稳定性。但是好在，这些都是机器的事情，只要持续的拆解，每个过程都是客观的、可以度量的。
按照以上的理解，我们就获得了一个分层的评估方式：
（1）组织效能：即常说的业务结果或业务价值，通常约等于组织的KPI，包括生产力、盈利能力和市场份额，以及效率、客户满意度等非商业衡量指标。
（2）软件研发效能（SDO）：即通俗所讲的广义上的“研发效率”，它可用来评估软件研发团队是否能够支撑组织效能的达成。比如在一定的投入产出下是否做到了“有质量的快”、或者在一定交付质量&效率的情况下内是否有更多的产出、更小的投入。
（3）软件研发能力：决定了研发效率的关键因素。研发效能的提升必须要落在工程、技术和研发者上，这些因素共同决定了软件研发效能的结果。对于团队Leader来说，关注软件研发能力指标和改进，可有效提升整体团队的研发效能。
3、如何先找到问题并持续调优？
基于上述的评估方式，我们可以构建一套用来评估和诊断的模型体系，帮助研发效能持续的提升。此需要强调的是我们的一个基本观点：“模型的本质是对规律的洞察，而上帝不会告诉我们规律，只会展示给我们数据”，因此，我们虽然基于观察和经验构建了逻辑模型，但是会带入大量的团队数据并结合实际进行验证，最终把它转换成“基于数据构建的可验证模型”，只有这样才能确保它是贴近事实的。
三、研发效能体检模型-全景图
1、评估对象
按“团队维度”评估，因为团队综合了软件交付的载体“应用”以及关键要素“人”。团队的最高层级为“集团公司”，俗称“全站”，下一级是集团的九大BU，最小级别为一线TL团队，90%的评估指标都是可以按团队维度分解的，即在全站看到的一个问题指标，可以逐层分解到最小的TL团队。一线TL团队再向下分解则是团队负责的某一个“应用”或者某一个“人”，但是由于团队中“人”和“应用”很难有一一对应的关系，因此综合评估的模型会部分失效，比如，如果具体到某一个应用，那么“工程能力”的评估是有意义的，但是“团队能力”的评估则是无效的。
2、模型特点
（1）系统性：展示了影响效能的关键要素、关键指标以及它们之间的关联关系。
（2）抽象性：将业务特点、软件架构、软件研发团队、研发过程，进行抽象，投影到了一个二维的研发过程模型（类似一个管道，又称“研发管道模型”）中，确保模型既符合研发特点，又在软件工程上具有一定的通用性，一定程度上反映了软件研发的基本规律。这样一来，这套模型可以兼容团队间差异（团队各有特的特点，但是都在模型定义范围内）以及架构差异（ServiceFul、ServiceLess存在差异，但是都在模型定义范围内）。
（3）准确性：每一套指标均用集团全站数据以及通过采样选择的具体团队数据带入验证，既具有统计学意义，同时又确保贴近事实，反应团队实际情况。
（4）动态性：模型不是静态的，虽然总体分类不变，但是每一项中的评估指标都会随着集团业务变化、研发体系演进以及组织对研发团队要求演进。
3、模型中的因果性和相关性
（1）基本概念
因果关系：当一个作为原因的要素的数据变化时，另一个作为结果的要素在一定程度发生变化，两者存在着必然联系。
相关关系：当一个要素的指标变化时，有一定的概率会引起另一个要素的指标也可能随之变化，但是两者不存在必然性。
（2）效能模型中的因果性
每一个要素的指标可继续拆解，分解出具有因果关系的子指标。
比如，迭代平均周期，可以拆解为“开发阶段周期 + 集成阶段周期 + 灰度&发布阶段周期”，
当然，也可拆解为N个迭代周期平均值。拆解之后，任一子指标出现问题，必然会影响主指标。
因此，合理使用主子指标间的因果关系，可以起到问题定位的作用。
（3）效能模型中的相关性
效能模型中的要素与要素之间虽然相互影响，但是并非因果关系，而是存在相关性，比如研发能力中的某些指标变差，一定程度上会影响研发效率，例如“工作效率”中的很多指标显示效率低下，就有可能影响“交付周期”变长，但是这并不是必然的，有可能“人员能力”中相关指标更优，冲抵了“工作效率”的变化。但是即使如此，合理使用不同要素指标之间的相关性可以达到综合性提升的效果，理论上，如果“研发能力”体检之后所有的指标良好，那么“研发效率”的指标也不会差。
全景图中的“黑线”呈现的就是要素之间的相关性：
“研发能力”影响“研发效率”。对应精益理论，资源效率一定程度上影响流动效率。
团队能力中，“工作效率”影响“人员产出”，“人员能力”影响“人员产出”和“工作效率”。
工程能力中，“工具效率”直接既影响研发过程相关阶段（比如预发、灰度、发布）的流动效率，又影响人的“工作效率”（如编码、提交、验证等）。
而“质量保障”和“基础设施”会影响“工具效率”，并最终反映到研发过程效率和人员产出上。
转∶
原文链接
https://t.cn/A6Twm2WH
namo-amitabhaya！
YouTuber Brian Tong 近日受邀参加了一次特别的游览活动，由苹果全球营销高级副总裁 Greg Joswiak 等多位高管陪同，乘坐高尔夫球车畅游 Apple Park 总部。此次游园活动的核心内容是“iPhone 的现状”，涵盖了 iPhone 相机、人工智能等诸多话题。
参与此次活动的苹果高管包括：
Kainann Drance，iPhone 产品营销副总裁
Alok Desphande，相机软件工程部门负责人
Anand Shimpi，硬件技术部门负责人
Della Huff，照片和相机产品营销部门负责人
视频中透露了一些有趣的信息，其中之一是 Shimpi 谈到了苹果的人工智能计划：“我们一直将人工智能用于一些第一方功能，通过理解场景、配置相机参数以及最终改善成像质量等方面发挥作用。除此之外，开发者们也已经开始将诸如 Stable Diffusion 和大型语言模型等技术应用于设备之上。虽然我不能透露未来，但正如 Tim 所说，我们有一些令人兴奋的东西即将推出，从软硬件角度来看，我们的优势非常明显。”
当被问及 iPhone 是否已经“停滞不前”时，Joswiak 表示：“每当我认为 iPhone 已经完美无缺，无法再改进的时候，我们总会有一支才华横溢的团队想出办法，让它变得更好，甚至远远超出预期。新一代的 iPhone 15 就是绝佳例证，仅以相机为例，iPhone 15 Pro 的相机相比 iPhone 14 Pro 有着显著的飞跃，更是远超几年前的水平。想想 iPhone 11，那可是五年前的产品了，现在的 iPhone 已经远远超越了它。相机如此重要，因为人们用它捕捉日常生活中的点点滴滴。社交媒体固然重要，但相机的作用绝不仅仅于此。iPhone 15 Pro 拥有高达 4800 万像素的主摄，Pro 版提供 3 倍光学变焦，Pro Max 则拥有 5 倍光学变焦。计算摄影技术让照片品质更加出色，这些照片会成为我们生活中永恒的回忆，因此出色的画质至关重要。然而，最令我兴奋的是视频拍摄功能。iPhone 在视频拍摄方面取得的成就让我们感到无比自豪。坦白地说，我们并不将其他智能手机视为竞争对手，而是将专业的摄像机视为标杆。我们不断努力缩小差距，力求打造与专业摄像机比肩的卓越品质。而 iPhone 15 Pro 和 Pro Max 正是我们迈出的重要一步，其视频拍摄能力绝对称得上出类拔萃。”#apple爆料#
参与此次活动的苹果高管包括：
Kainann Drance，iPhone 产品营销副总裁
Alok Desphande，相机软件工程部门负责人
Anand Shimpi，硬件技术部门负责人
Della Huff，照片和相机产品营销部门负责人
视频中透露了一些有趣的信息，其中之一是 Shimpi 谈到了苹果的人工智能计划：“我们一直将人工智能用于一些第一方功能，通过理解场景、配置相机参数以及最终改善成像质量等方面发挥作用。除此之外，开发者们也已经开始将诸如 Stable Diffusion 和大型语言模型等技术应用于设备之上。虽然我不能透露未来，但正如 Tim 所说，我们有一些令人兴奋的东西即将推出，从软硬件角度来看，我们的优势非常明显。”
当被问及 iPhone 是否已经“停滞不前”时，Joswiak 表示：“每当我认为 iPhone 已经完美无缺，无法再改进的时候，我们总会有一支才华横溢的团队想出办法，让它变得更好，甚至远远超出预期。新一代的 iPhone 15 就是绝佳例证，仅以相机为例，iPhone 15 Pro 的相机相比 iPhone 14 Pro 有着显著的飞跃，更是远超几年前的水平。想想 iPhone 11，那可是五年前的产品了，现在的 iPhone 已经远远超越了它。相机如此重要，因为人们用它捕捉日常生活中的点点滴滴。社交媒体固然重要，但相机的作用绝不仅仅于此。iPhone 15 Pro 拥有高达 4800 万像素的主摄，Pro 版提供 3 倍光学变焦，Pro Max 则拥有 5 倍光学变焦。计算摄影技术让照片品质更加出色，这些照片会成为我们生活中永恒的回忆，因此出色的画质至关重要。然而，最令我兴奋的是视频拍摄功能。iPhone 在视频拍摄方面取得的成就让我们感到无比自豪。坦白地说，我们并不将其他智能手机视为竞争对手，而是将专业的摄像机视为标杆。我们不断努力缩小差距，力求打造与专业摄像机比肩的卓越品质。而 iPhone 15 Pro 和 Pro Max 正是我们迈出的重要一步，其视频拍摄能力绝对称得上出类拔萃。”#apple爆料#
【软件工程，GJB5000敏捷开发∶迭代和看板的不同之处】
迭代和看板是敏捷开发中管理工作流的两种方式，它们都适用于推动小批次工作快速流动，各自也都有其优势和弱点。下面的介绍，可以帮助你选择适合你的管理方式。
承诺
迭代是有明显的承诺和完成承诺的要求。每次迭代前制定的迭代计划都是开发人员对于本次迭代完成任务的承诺，每次迭代结束，开发人员都会被要求完成他事先的承诺。只有这些承诺都被完成，一次迭代才能完满结束。
而在看板系统中，没有明显的承诺意味。看板关注的是工作进展的流畅性，关注的是有没有浪费环节导致工作不够流畅。
团队协作
迭代中的承诺不仅仅是个人的，更是团队的。所以，在迭代系统中，要求团队成员协同工作，相互信任，互相帮助，从而确保实现团队的承诺。
而在看板系统中，每个人更多的时候是工作在自己的位置上，他首先要确保自己的工作按计划完成，然后才会考虑在下游出现瓶颈时再提供帮助。
批次规模
迭代是使用时间盒的，每次迭代就是完成一个时间盒，一个时间盒内需要完成软件的一个或几个功能。可是，每个功能的大小是不同的，这可能使得每个时间盒完成的功能的规模不可能一致，在固定的时间盒内会出现某次迭代完成的功能规模多，另一次迭代完成的功能规模少的情况。
而在看板系统中，工作流是按功能而不是迭代的时间盒来计算的，它不会出现基于时间盒的迭代中出现的因难以将功能整齐地放到时间盒中而导致的不必要的浪费。
节拍
迭代中采用的固定的时间盒的开发方式，可以被认为软件开发具有固定的节拍（每次迭代就是一个节拍），这种节拍相当于传统项目管理中的里程碑点，可以让团队成员不必一直保持紧张的状态，可以让他们长期保持斗志昂扬的士气。
而在看板系统中并没有天生的节拍，但如果软件系统会定期发布（例如每周一次），也可以将每次发布视作一个节拍。
以上从承诺、团队协作、批次规模和节拍等四个方面对迭代和看板进行了比较，它们各有千秋。项目组不要将自己限制在一种工具上，应当根据项目的实际情况作出最优选择。
这正是：
迭代看板不相同，四个方面说分明
根据实际做选择，只看效果中不中
参考书目：精益软件开发管理之道，作者：（美）帕彭迪克，译者：王海鹏，出版社：机械工业出版社
作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000培训、内外部评价以及软件过程改进、软件工程能力提升的研究工作。
转∶
原文链接
https://t.cn/A6TwMew4
namo-amitabhaya！
迭代和看板是敏捷开发中管理工作流的两种方式，它们都适用于推动小批次工作快速流动，各自也都有其优势和弱点。下面的介绍，可以帮助你选择适合你的管理方式。
承诺
迭代是有明显的承诺和完成承诺的要求。每次迭代前制定的迭代计划都是开发人员对于本次迭代完成任务的承诺，每次迭代结束，开发人员都会被要求完成他事先的承诺。只有这些承诺都被完成，一次迭代才能完满结束。
而在看板系统中，没有明显的承诺意味。看板关注的是工作进展的流畅性，关注的是有没有浪费环节导致工作不够流畅。
团队协作
迭代中的承诺不仅仅是个人的，更是团队的。所以，在迭代系统中，要求团队成员协同工作，相互信任，互相帮助，从而确保实现团队的承诺。
而在看板系统中，每个人更多的时候是工作在自己的位置上，他首先要确保自己的工作按计划完成，然后才会考虑在下游出现瓶颈时再提供帮助。
批次规模
迭代是使用时间盒的，每次迭代就是完成一个时间盒，一个时间盒内需要完成软件的一个或几个功能。可是，每个功能的大小是不同的，这可能使得每个时间盒完成的功能的规模不可能一致，在固定的时间盒内会出现某次迭代完成的功能规模多，另一次迭代完成的功能规模少的情况。
而在看板系统中，工作流是按功能而不是迭代的时间盒来计算的，它不会出现基于时间盒的迭代中出现的因难以将功能整齐地放到时间盒中而导致的不必要的浪费。
节拍
迭代中采用的固定的时间盒的开发方式，可以被认为软件开发具有固定的节拍（每次迭代就是一个节拍），这种节拍相当于传统项目管理中的里程碑点，可以让团队成员不必一直保持紧张的状态，可以让他们长期保持斗志昂扬的士气。
而在看板系统中并没有天生的节拍，但如果软件系统会定期发布（例如每周一次），也可以将每次发布视作一个节拍。
以上从承诺、团队协作、批次规模和节拍等四个方面对迭代和看板进行了比较，它们各有千秋。项目组不要将自己限制在一种工具上，应当根据项目的实际情况作出最优选择。
这正是：
迭代看板不相同，四个方面说分明
根据实际做选择，只看效果中不中
参考书目：精益软件开发管理之道，作者：（美）帕彭迪克，译者：王海鹏，出版社：机械工业出版社
作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000培训、内外部评价以及软件过程改进、软件工程能力提升的研究工作。
转∶
原文链接
https://t.cn/A6TwMew4
namo-amitabhaya！
✋热门推荐