刚读完下面的书，想复习一下。
标题：加速：精益软件和DevOps的科学：建立和扩展高性能技术组织
作者：Nicole Forsgren博士，Jez Humble和Gene Kim
在这篇评论中，我首先简要讨论本书的目标读者（以下称为Accelerate ）。 接下来，我讨论其中提出的主要思想。 最后，我对这些想法提供反馈和批评。
1-本书的受众和目的
从事软件团队工作的任何人都可以阅读本书并从中受益。 Accelerate旨在突出提供高质量软件的公司中员工和团队的行为。 员工调查是其基础，过去常常认为软件交付绩效可以带来更好的组织绩效（更大的盈利能力和市场份额）。
2-这本书详细说了什么？
作者和软件行业的资深人士Nicole Forsgren博士，Jez Humble和Gene Kim建议，软件交付绩效可以带来更好的组织绩效。
测量软件交付性能很困难。 错误的生产率度量标准很容易使工程团队感到恐慌。 作者确定了四个衡量软件交付性能的指标：
- 交货时间（满足客户要求的时间）
- 部署频率
- 平均恢复时间（MTTR）
- 变更失败率（变更失败导致生产中断的百分比）
因此，本质上，作者发现，绩效较高的人有更好的交付周期，更频繁地部署，更快地恢复服务以及更少地失败。
作者还发现，以下因素影响软件交付和组织绩效：
- 技术实践（连续交付）
- 精益管理实践：作者讨论：限制进行中的工作（WIP），显示关键质量和生产率指标的可视仪表板，生产反馈以及轻量级变更批准
- 精益产品开发因素：作者讨论：诸如小批量工作，所有团队成员都可见的工作流程，收集和实施客户反馈以及团队试验等因素
- 领导力特点：作者重点介绍：愿景，鼓舞性沟通，智力刺激，支持性领导和个人认知
- 员工满意度（以员工净晋升得分（eNPS）衡量）
几乎所有上述因素中，高绩效者都表现出色。 在本书的后半部分，作者解释了他们研究背后的方法。 最后，它们包括一个引人入胜的案例研究。
3 —批判
3.1-高性能定义者及其基础数据
首先，重要的是要了解这里的组织如何被归类为“高绩效”。 作者暗示，在四个指标（交货时间，部署频率，MTTR和变更失败率百分比）上表现出色的公司是高绩效的，并且随着市场份额的增长而获利。
为了了解Accelerate如何确定一名出色的员工，我想看看用于收集本书数据的调查问题，该书于今年3月出版。 但是，我找不到它们。 因此，我改为查看了2018年DevOps状态调查（更新：此调查不再有效）。 它是由Forsgren博士在她的Twitter feed上推广的，我在那里找到了它。 我认为以前的调查也有类似的问题。
在该调查中，要求参与者对以下各项进行评分，评分范围从“ 在目标以下完成”到“ 在目标以上完成” （“ 不适用 ”和“ 我不知道”也是一种选择）：
- 组织绩效
- 盈利能力
- 市场份额
重要的是要注意，获利能力和市场份额数据是从调查参与者那里收集的。 我对大多数工程师具有有关其组织绩效的准确信息的基本假设表示怀疑。
在技术公司任工程师的时候，我并不总是拥有盈利能力和市场份额数据。 另外，我与网络中的大约二十名工程师进行了交谈，令人惊讶的是，许多人也不知道有关他们组织的这些数字。
与我交谈的工程师可能不是代表性的样本。 但是，这些工程师中的大多数受雇于声称财务透明的（非公开）美国公司。 同样，当我与美国和欧洲以外的工程师交谈时，他们忽略了雇主的获利能力数量和市场份额。
此外，一些公司在市场份额数据不容易获得和/或不可靠的行业或地区中运营。 在形成新产业时，任何人都很难获得可靠的市场份额数据。
尽管参与者可以选择N / A之类的选项，但我不知道 ，但本书的结果并未详细介绍参与者选择这些选项的百分比，或者是否使用其他可信来源对这些数据进行了交叉检查。 提供更详细的调查数据将有助于读者执行自己的可靠分析。 定义一支高性能工程团队的更具体，更完整的基础数据将更加令人放心，因为这为本书的论文奠定了基础。
3.2-忽略公司的过去和未来表现
作者关于软件交付性能可能导致组织绩效的结论不一定是准确的。 他们从一个快照中查看公司的绩效，并得出结论，当前的组织行为是成功的原因。 从组织绩效的整体观点来看，这种论点会更有说服力。
这里有两件事在起作用。 为了增强我们对良好组织绩效的信心，我们必须在相当长的一段时间内进行研究。 此外，大多数情况下，稳定的组织绩效是由许多事物组成的复杂网络的结果。
这项研究衡量了当前的组织绩效，同时回避了在足够长的时间内考虑绩效的问题。 一些调查受访者有可能在组织获利时参与其中，但几个月后蒙受了损失。 或者，该组织在调查时并未盈利，但在数月后开始盈利。 研究经受时间考验的工程团队可能比审视那些导致短命的业绩的团队更为谨慎。 似乎该研究没有考虑这一点。
此外，获利能力和市场份额的提高可能归因于数月前做出的众多决策。 此外，除了软件交付之外，许多其他同样重要的因素也可能对组织绩效负责。 我觉得这些因素没有详细说明。
该书应该对组织绩效进行综合考虑，并考虑了以上两个问题。 这不仅会提出更充分的理由，而且会加强其结果。
3.3-测量时间精度
该调查还询问受访者他们在某些活动上花费的时间百分比。 例如，我在调查中看到以下问题：
- 您在新工作，返工或计划外工作上花费了多少时间？
- 您花在纠正安全问题上的时间百分比是多少？
- 您花费多少时间处理最终用户发现的缺陷？
- 您花在客户支持工作上的时间百分比是多少？
- 配置和管理CI / CD工具花费了团队时间的百分之多少？
毫无疑问，这些都是重要的问题，尤其对于确定高绩效人员如何管理他们的工作和时间。 但是，显然，调查并未询问参与者是否跟踪自己的时间，以及是否跟踪了时间。 如果调查参与者给出了未跟踪的时间估计，则这些时间估计的主张以及由此得出的结论将是不正确的。
即使回想起来，也很难猜测完成工程活动所需的实际时间。 我目睹了工程师抱怨某些活动花费太多时间。 当我要求这些工程师跟踪完成每个活动所需的时间时，数据几乎总是证明他们的时间估算不正确。
就我个人而言，我无法准确估算出我在缺陷上（由最终用户确定）与新工作所花费的时间比例是多少，而不跟踪我的时间。 我不确定在不了解调查参与者如何跟踪时间的情况下，基于围绕时间估计的调查问题进行的推论或推论是否有意义。
该研究应可靠地评估受访者如何估计他们的时间。 在缺乏可靠评估的情况下，从此类数据得出的结论令人怀疑。
3.4-忽略社会因素
传奇人物Gerald Weinberg在他的经典著作《计算机编程心理学》中指出，编程不仅仅是个人活动，更是一种社会活动。
Accelerate从各个响应中得出结果，但结果是由团队实现的。 解决团队中的问题需要社交互动。 尽管该研究考虑了文化方面的问题，但我仍然觉得某些社会方面没有涉及。
例如，社交互动和高绩效团队与低绩效团队的组成，工程师和领导者的经验和背景，反馈过程，完成工作所使用的非正式方法以及团队所使用的正式和非正式沟通渠道等方面的差异都是研究未包括的重要因素。 这些可以为读者提供有关高效团队的社会方面的宝贵见解。
3.5-团队如何实际衡量指标的详细信息不足
如上所述， Accelerate建议采用四种度量软件交付性能的方法，即交货时间，部署频率，MTTR和变更失败率。 对于新组建的团队来说，了解高绩效团队实际上是如何衡量这些因素的确很有帮助。
此外，作为读者，我将受益于高性能工具用来衡量此类指标的工具和过程的信息。 如果有这样的信息，读者也可以很容易地将这些想法应用到他们的团队中。
3.6-概括各个行业的绩效
我不确定Accelerate的软件交付性能衡量标准在不同行业是否适用。 首先，我认为在某些行业，例如制药等行业，交货时间并不短。制药产品先经过试验，然后进行法规测试，但甚至可能还没有推出。
虽然这些行业中的工程团队确实使用了本书提出的许多实践，但是我不确定这可以很容易地概括。
3.7-认知偏见
加速中的另一个问题是认知偏差的作用。 认知偏见是调查固有的； 这个事实应该向读者阐明。
员工可能会受到偏见的影响，例如锚定偏见（过于依赖一个特质或一条信息，而忽略了其他相关数据）或虚幻的相关性（在没有事件和行为之间建立关系） 。 能否大幅提高调查参与者的思想，认为他的组织一切都很好？ 如果是这样，调查（本研究基于该调查）是否适合这种情况？
被调查者有可能沦为这些偏见的猎物。 尽管在调查中处理认知偏见可能并不容易，但我希望作者正式提出是否/如何考虑这种偏见。
4-分开的想法
总体而言，《 加速》是一本有趣的书。 我边读边学。 我对时间的投入证明了我认为这本书很重要的事实。 此外，我这次审查的目标是就我认为可以改进的想法展开辩论，并让其他人以更好的方式获得它的概念。
