“Prediction is difficult, especially when it’s about the future” Niels Bohr
“预测是困难的，尤其是在未来的时候” Niels Bohr
This article adds a couple of ideas (most notably the Law of Requisite Variety) to the concepts of mechanical authority, the theory of domains, and the cognitive layering theory that underlies the ladder of trust. We know that just because it works for them doesn’t mean it will work for us, but can we make useful predictions about that? I think we can.
本文在机械权限的概念，领域 理论 和信任阶梯基础上的 认知分层理论中添加了一些想法(最著名的是《必需品权定律》)。 我们知道， 仅仅因为它对他们有用并不意味着它对我们有用，但是我们可以对此做出有用的预测吗？ 我想我们可以。
(This article is a bit of a mess — I need to publish it so that I can find out how and why it confuses people. Making the theory accessible is hard work, and this is an effort to combine advanced theory with a case study. )
(本文有点混乱-我需要出版它，以便我可以找出它如何以及为什么使人们感到困惑。使该理论易于理解是一项艰苦的工作，并且这是将高级理论与案例研究相结合的努力。 )
理论的一些要点 (Some essentials of theory)
必要的变化规律 (The law of requisite variety)
The law of requisite variety states that if an organism is to survive, it must be able to respond to its environment in at least as many ways as the environment challenges it. So, if you live in an environment that can challenge you in 5 ways, and you have 5 behaviours in your repertoire, you might live. If you only have 4 behaviours in your repertoire, then sooner or later the environment will confront you with a challenge that you can’t meet.
必要的变种定律规定，如果一个生物要生存，它必须能够至少以与环境挑战生物一样多的方式对环境做出React。 因此，如果您生活在可以通过5种方式挑战您的环境中，并且您有5种行为举止，那么您可能会生活。 如果您的曲目中只有4种行为，那么环境迟早会面临您无法应对的挑战。
必要品种法+信托阶梯 (Law of requisite variety + Ladder of trust)
If you want to achieve a quality standard (layer 1), you have to be able to do things (layer 1).
如果要达到质量标准(第1层)，则必须能够执行操作(第1层)。
If you want to manage costs (layer 2), there is a qualitative increase in the complexity of your objective. Doing things (layer 1) cannot be enough: you need to be able to plan (layer 2) if you’re going to predict costs and therefore have a chance of managing them.
如果要管理成本(第2层)，则目标的复杂性将在质量上有所提高。 做事(第1层)是不够的：如果您要预测成本并因此有机会进行管理，则需要能够进行规划(第2层)。
Optimization (layer 3) requires a systems perspective (layer 3) for the same reasons. Integration (layer 4) requires the ability to identify priorities (layer 4), and you can’t responsibly exercise freedom (layer 5) if you can’t see what you’re doing (layer 5).
出于相同的原因，优化(第3层)需要系统角度(第3层)。 集成(第4层)需要具有识别优先级的能力(第4层)，如果看不到自己在做什么(第5层)，您就不能负责任地行使自由(第5层)。
+机械权威 (+ Mechanical authority)
A plan (layer 2) is a machine that can manage cost (layer 2). A specification (layer 3) can be used to optimize (layer 3). A language (layer 4) can be used to integrate (layer 4). Indicators and signals (layer 5) enable freedom (layer 5).
计划(第2层)是可以管理成本(第2层)的机器。 规范(第3层)可用于优化(第3层)。 一种语言(第4层)可用于集成(第4层)。 指示器和信号(第5层)实现自由(第5层)。
什么是软件？ (What is software?)
A piece of well-built software is a system (layer 3) that helps people achieve goals (layer 4). Ideally it is built by people who think well about systems (strong layer 3) and have some awareness of the goals (layer 4).
一个完善的软件是一个系统(第3层)，可以帮助人们实现目标(第4层)。 理想情况下，它是由对系统认真思考(第3层)并且对目标有一定了解(第4层)的人构建的。
敏捷的简短历史 (A short history of Agile)
敏捷前时代 (The pre-Agile eras)
During the cowboy era (until the rise of formal methods), the ability to create any software at all was something of a minor miracle. Software development tools were very difficult to use, their use was poorly understood, and the best available practice was to identify those superstars who were able to do the job at all, and support them as best as possible.
在牛仔时代 (直到形式方法的兴起)，完全可以创建任何软件的能力是一个小奇迹。 软件开发工具非常难以使用，对其使用知之甚少，并且最佳实践是确定那些完全能够胜任这些工作的超级巨星，并尽可能地为其提供支持。
Projects stood a high chance of not being delivered at all, and cost overruns were so routine that the idea of achieving work on time was regarded as ridiculous. This was not a sustainable state of affairs, and measures to ensure a minimum level of quality and some cost containment were introduced. These took the form of project plans (layer 2) and document standards (layer 3). Organizations that understood how to use them were able to get the unmitigated chaos of the time into some kind of order.
项目极有可能根本无法交付，而且成本超支是如此例行，以至于按时完成工作的想法被认为是荒谬的。 这不是一个可持续的状况，因此引入了确保最低质量水平和一定成本控制的措施。 这些采取项目计划(第2层)和文档标准(第3层)的形式。 理解如何使用它们的组织能够将当时毫无保留的混乱变成某种秩序。
The formal methods era stopped projects from getting completely out of control, and a wave of enthusiasm for plans and specifications took place. An answer to the most pressing problems in the industry had been found.
正式方法时代阻止了项目完全失控，对计划和规格的热情高涨。 找到了对行业中最紧迫问题的解答。
There were two problems:
有两个问题：
Due to a profound shortage of project managers with programming skills, project managers were enlisted to run IT projects despite having no understanding of the work. Where project plans had been used by layer 3 professionals to support their work, the layer 3 work was put under the supervision of layer 2 incompetents. Disasters ensued.
由于具有编程技能的项目经理的严重短缺，尽管他们不了解工作，但仍邀请项目经理来运行IT项目。 如果第3层专业人员使用了项目计划来支持他们的工作，则将第3层工作置于第2层不称职的监督之下。 灾难接。而至。
The programmers who knew what they were doing had a layer 4 problem: they knew that what they needed to do was to ensure that their work was relevant, and that the demands (from people who had no understanding of what they were talking about) for more control were doing more harm than good.
知道自己在做什么的程序员有一个第4层问题 ：他们知道他们需要做的是确保他们的工作是相关的，并且(对于那些不了解他们所谈论内容的人的)要求是什么。更多的控制弊大于利。
敏捷的诞生 (The birth of Agile)
The Agile Manifesto in 2001 laid out a set of priorities for software development. While recognizing that the layer 2 controls were useful, it asserted that the true priority was to actually deliver software. It was a badly-needed course correction.
《敏捷宣言》在2001年列出了软件开发的一系列优先事项。 在认识到第2层控件很有用的同时，它断言真正的优先权是实际交付软件。 这是急需的路线调整。
With a group of industry leaders backing them, senior programmers were able to get rid of the counter-productive project managers (#NotAllProjectManagers). A flourishing occurred, and programmers set about pursuing an important goal of the manifesto: to identify better ways of working.
在一群行业领导者的支持下，高级程序员得以摆脱了适得其反的项目经理(#NotAllProjectManagers)。 繁荣发展发生了，程序员开始追求宣言的一个重要目标：确定更好的工作方式。
Layer 3 concepts of how to organize work came into being, with eXtreme Programming and Scrum being the stand-out early systems. “Arrange your work according to this specification, and you’ll have more reliable and relevant software” was the promise, and for early adopters this was very much the case.
第3层有关如何组织工作的概念应运而生，其中eXtreme Programming和Scrum是杰出的早期系统。 诺言：“根据此规范安排工作，您将拥有更可靠和相关的软件”，对于早期采用者而言，情况确实如此。
敏捷崇拜的兴起 (The rise of the Cult of Agile)
Armed with specifications, and an easily-obtained Certified Scrum Master certificate, thousands of people went into organizations to spread the word about great software development.
有了规格和易于获得的Scrum Master认证证书，成千上万的人进入了组织，以传播有关出色软件开发的信息。
But the people who go on certification courses are the people who don’t already know how to do a good job without the certification. And a two-day course is no substitute for the years of experience it takes to be truly competent at layer 3. Instead of working with and fine-tuning the Scrum specification (which I single out due to its popularity and commercial success), these junior practitioners followed the Scrum specification. Debates about “the ideal number of minutes for a daily stand-up meeting” on LinkedIn arose, a clear indicator that ‘Scrum masters’ didn’t know how to run an efficient meeting, let alone optimize the performance of a software development team.
但是参加认证课程的人是那些不知道如何在没有认证的情况下做好工作的人。 而且，为期两天的课程不能替代真正具备胜任第3层所需的多年经验。这些课程不是使用和调整Scrum规范(由于其受欢迎程度和商业成功，我单挑它)。初级从业人员遵循Scrum规范。 出现了关于LinkedIn上“每日站立会议的理想分钟数”的争论，这清楚地表明“ Scrum masters”不知道如何召开有效的会议，更不用说优化软件开发团队的绩效了。
Underperforming and frightened, these practitioners defended their actions by pointing out that they were following specifications that had been developed by people far wiser than anyone in the room. In many places, pursuit of agility was replaced by adherence to Agile.
这些从业者表现不佳且受到惊吓，为自己的行为辩护，指出他们遵循的是人们比房间里任何人都聪明的人制定的规范。 在许多地方，对敏捷的追求被坚持敏捷所取代。
夹具到了 (The jig is up)
Software engineering has been successful enough that clients can typically expect something similar to what they asked for, delivered on a timeframe that resembles the original plan, at a cost that is not completely unknown. This is a massive step forward from where we were in 1980. And it’s typically achievable without investing in the cult of Agile. (There are degrees in computer science now, which do a pretty good job of preparing people to do the work: and the tools are so good that primary school students can develop systems that would have been a worthy undergraduate thesis in the 90s.)
软件工程已经足够成功，以至于客户通常可以在类似于原始计划的时间范围内交付与他们要求的东西类似的东西，而费用却并不完全未知。 这是自1980年以来的一大进步。通常无需投资敏捷组织就可以实现。 (现在有计算机科学的学位，这在使人们做好工作准备方面做得非常好：并且工具是如此之好，以至于小学生可以开发在90年代值得大学毕业论文的系统。)
Most software engineering work is not research and development; we’re not trying to work out how to get data displayed on the screen, we’re choosing between multiple prefabricated components and then gluing them together. The reasons which prevented us from being able to plan projects with confidence in the past are far less relevant today. Similarly, there’s no longer a desperate shortage of project managers who can tell the difference between cutting code and pouring concrete.
大多数软件工程工作不是研发。 我们没有尝试找出如何在屏幕上显示数据，而是在多个预制组件之间进行选择，然后将它们粘合在一起。 过去，使我们无法自信地计划项目的原因在今天已经不那么重要了。 同样，不再存在能够分辨代码和浇筑混凝土之间区别的项目经理。
The problem we have now is a lack of supervision and planning, because the course correction we needed 20 years ago has been locked in place. Today, we need more layer 2 support (especially competent supervision), not less.
我们现在面临的问题是缺乏监督和计划，因为20年前我们需要进行的路线调整已锁定在适当的位置。 今天，我们需要更多的第2层支持(尤其是主管监督)，而不是更少。
考虑的软件工程方法的要求 (Requirements for a considered approach to software engineering)
Before proceeding to select tools for the future concept of software engineering (more precisely, to provide a plan for selecting tools based on a specified categorization of tools), I’ll outline what I perceive to be the requirement for any fully-considered organization:
在继续为将来的软件工程概念选择工具(更确切地说，为根据指定的工具分类提供选择工具的计划)之前，我将概述我认为对任何经过充分考虑的组织都必须具备的条件：
您想覆盖所有图层 (You want to cover all the layers)
It’s simple once you’ve got the foundation: there are five cognitive layers in the model, and a cognitively complete organization covers all of them.
一旦有了基础，就很简单：模型中有五个认知层，一个完整的认知组织涵盖了所有这些层。
It does things, and it talks about what it’s doing.
它做事，并谈论它在做什么。
It manages cost, and it sets expectations so that variations can be detected and managed.
它管理成本 ，并设定期望值，以便可以检测和管理变化。
It assembles things into coherent systems, and reviews the system as a whole to make sure that it works as efficiently and effectively as it should
它将事物组装到一致的系统中 ，并对系统进行整体审查，以确保它能像应有的那样高效地工作。
It reconciles differing perspectives, enabling different systems to coexist in productive (or at least non-harmful) ways.
它调和了不同的观点 ，使不同的系统以生产性(或至少无害)方式共存。
It forms perceptions, and communicates about what it sees.
它形成感知 ，并交流所见。
If you’re doing all of those things, then you’re covering every aspect of considering things that I can imagine. Stafford Beer’s Viable System Model provides a more rigorous and sophisticated definition of equivalent layers that is especially relevant if you’re building your viable system out of mechanical parts. There’s also research that indicates that it really does predict viability (survival). (The VSM is a layer 5 model, whereas the cognitive layering model is a layer 4 model, and there are differences that can be important depending on the work you’re doing.)
如果您正在做所有这些事情，那么您将涵盖考虑我能想象的事情的各个方面。 斯塔福德·比尔(Stafford Beer)的“ 可行系统模型”提供了对等效层的更严格，更复杂的定义，如果您要用机械零件建造可行系统，则这一点尤其重要。 也有研究表明它确实可以预测生存力。 (VSM是第5层模型，而认知分层模型是第4层模型，根据您所从事的工作，有些差异可能很重要。)
设计工具选择计划 (Designing a tool selection plan)
Armed with one important design constraint (a requirement), we then have to consider the available materials. The theory of mechanical authority says that artefacts (machines) correspond to layers:
有了一个重要的设计约束(一项要求)，我们就必须考虑可用的材料。 机械权威理论说，人工制品(机器)对应于以下层：
- Instructions at the task/doing level 任务/执行级别的说明
- Plans at the supervisory/cost level 监督/成本级别的计划
- Specifications at the systems/optimization level 系统/优化级别的规格
- Languages at the integration/goal level 整合/目标级别的语言
- Indicators at the perception/vision level 感知/视觉层面的指标
If we arrange our communication/consideration needs vertically, and our artefact horizontally, then we get a grid that looks like this:
如果我们垂直排列我们的沟通/考虑需求，水平放置我们的人工制品，那么我们将得到一个看起来像这样的网格：
The green zone is where we have a tool that exists at the same layer as the need. These are the tools that are the most immediately relevant to the need.
绿色区域是我们拥有与需求位于同一层的工具的位置。 这些是与需求最直接相关的工具。
If the tool is one layer higher than the need, then we are in the blue zone. For example, when we are not sure what we should be doing, a plan can be a very useful constraint.
如果工具比需求高一层，那么我们处于蓝色区域。 例如，当我们不确定应该做什么时，计划可能是非常有用的约束。
If the tool is more than one layer higher than the need, then we are in the yellow zone. A corporate vision statement tends not to be very useful when attempting to formulate a specification; we typically need to translate the vision into a set of goals (into the blue zone) before it becomes useful for optimization.
如果该工具比需求高出一层以上，则我们处于黄色区域。 试图制定规范时，公司愿景声明往往不是很有用； 我们通常需要先将愿景转化为一组目标(进入蓝色区域)，然后才能用于优化。
If the tool is one layer lower than the need, we are in the brown zone. The tool has the potential to solve the problem, if it’s just the right tool for just the right problem. It’s likely that a tool in the brown zone will require more than just fine-tuning to work, and it may turn out to be simply inappropriate.
如果工具比需求低一层，则我们处于棕色区域。 如果它只是解决正确问题的正确工具，那么该工具就有可能解决问题。 棕色区域中的工具可能不仅需要微调才能工作，而且事实证明这是不合适的。
If the tool is more than one layer lower than the need, we are in the red zone. Tools in the red zone can’t fully resolve the need: they might be essential components of a full solution, but they cannot be applied in isolation.
如果该工具比需求低一层以上，则我们位于红色区域。 红色区域中的工具无法完全解决需求：它们可能是完整解决方案的重要组成部分，但不能孤立地使用它们。
来自该模型的预测 (Predictions flowing from this model)
A checklist is a collection of tasks. Apply it to the tasks which need to be done to conduct a takeoff or a surgical procedure (green zone) and there’s a good chance it will help. Apply it to the strategic goal of integrating a new practice into hospital culture (red zone) and the strongest advocates now acknowledge it isn’t enough.
清单是任务的集合。 将其应用于执行起飞或外科手术(绿色区域)所需的任务，很有可能会有所帮助。 将其应用于将新实践整合到医院文化(红色区域)中的战略目标，最有力的支持者现在承认这还不够。
Lean Six Sigma is a system for producing plans. Apply it to the tasks carried out on a factory floor (blue zone), and there’s a good chance of success. Apply it to the goal of ‘Higher quality for cheaper’ in a complex services organization (red zone), and you end up with Lean Sick Sigma.
精益六西格码是用于制定计划的系统。 将其应用于在工厂车间(蓝色区域)执行的任务，成功的机会就很大。 将其应用于复杂服务组织(红色区域)中的“更高质量，更便宜”的目标，您最终会得到Lean Sick Sigma。
Scrum is a specification for a software development team. Apply it to a software development team, and there’s a good chance of success. Apply it to integrating multiple teams (Scrum of Scrums, brown zone), and it might work, in the right situation.
Scrum是软件开发团队的规范。 将其应用于软件开发团队，成功的机会就很大。 将其应用于整合多个团队(Scrum of Scrums，棕色区域)，并且在正确的情况下可能会起作用。
ITIL is a specification for integrating IT services into an organization (brown zone). Apply it to an organization that will willing to accept those constraints, with an IT organization structured according to ITIL principles, with appropriate leadership, and it will work.
ITIL是用于将IT服务集成到组织(棕色区域)的规范。 将其应用于愿意接受这些限制的组织，并根据ITIL原则构造一个IT组织，并拥有适当的领导才能工作。
SAFE is a relatively prescriptive set of specifications and plans which attempts to combine the benefits of Scrum and ITIL. Combining multiple layers into one standardized solution amplifies the risk and the reward.
SAFE是一组相对说明性的规范和计划，试图结合Scrum和ITIL的优势。 将多层结合到一个标准化的解决方案中，可以放大风险和回报。
The Capability Maturity Model is a specification for optimizing the delivery capabilities of an IT organization. It’s in the green zone, and when applied skilfully, it’s very likely to optimize the delivery capabilities of an IT organization.
能力成熟度模型是用于优化IT组织交付能力的规范。 它位于绿色区域，如果巧妙地应用，很可能会优化IT组织的交付能力。
Disciplined Agile Development is a collection of specifications that provides a set of options for optimizing a software development team. Because it is a collection of candidate, incomplete specifications, it occupies the blue zone for optimizing a team: difficult to comprehend, but powerful in practice. (‘A collection of incomplete specifications that can be related to each other’ is a language.)
纪律敏捷开发是一组规范，为优化软件开发团队提供了一组选项。 因为它是候选的，不完整的规范的集合，所以它占据了优化团队的蓝色区域：难以理解，但在实践中功能强大。 (“可以相互关联的不完整规范的集合”是一种语言。)
XSCALE (I am an XSCALE Alliance member) contains a set of goals, specifications and plans that are not intended to be implemented as-is; they are intended to expand awareness of issues and possibilities. At its heart, it is a vision, occupying the yellow zone from an operational point of view. It comes into its own at the strategic level, when the task is to create new indicators and to reconcile perspectives.
XSCALE(我是XSCALE联盟的成员)包含一组目标，规格和计划，这些目标，规格和计划均不能按原样实施。 他们旨在扩大对问题和可能性的认识。 从本质上讲，它是一种愿景，从操作的角度来看，它占据了黄色区域。 当任务是创建新的指标并调和观点时，它在战略层面就应运而生。
Organization Engineering (my quixotic aspiration) is an effort to create a language for integrating and reconciling concerns. If it succeeds, it will be a tool that integrators can apply directly to their day to day work.
组织工程学(我的吉otic志向)是一种创建用于整合和协调关注点的语言的工作。 如果成功，它将是集成商可以直接应用于其日常工作的一种工具。
我希望您的帮助 (I’d love your help)
There are far too many communication failures in the world for one organization (let alone one person) to solve them all. I’m also constrained that I’m an engineer at heart, and I’m far too interested in building practical solutions to be able to stomach the work of testing these theories scientifically. I’ve built enough solutions to be confident that I can use this tool, but I’m all too familiar with the problems that occur when people fail to identify hidden prerequisites when deploying a new tool.
一个组织(更不用说一个人)要解决所有问题，世界上存在太多的通信故障。 我也被限制为我是一名内心的工程师，而且我对构建实用的解决方案太感兴趣了，以至于无法承担科学测试这些理论的工作。 我已经建立了足够的解决方案来确信可以使用此工具，但是我对人们在部署新工具时未能识别出隐藏的前提条件时所产生的问题非常熟悉。
If you decide to test these ideas in practice, please let me know how it goes. If it contradicts your experience, I’d like to understand why (this is the tenth iteration of the theory, but the first to be released to the public: I doubt the work of adjusting it is complete). And if you’d like my help applying it to a problem, then I’d love to hear from you.
如果您决定在实践中测试这些想法，请告诉我它的进展。 如果它与您的经验相矛盾，我想理解为什么(这是该理论的第十次迭代，但是第一次向公众发布：我怀疑调整它的工作是否完成)。 如果您希望我的帮助将其应用于问题，那么我很想听听您的意见。
1046
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
