“交通拥堵会对都会区的生活质量和经济生产率产生不利影响。 它会增加油耗，旅客和货运的成本，坠机次数以及对人体健康有害的尾气污染物。” —约翰·C·法尔科基奥（John C. Falcocchio）
用肉眼看，交通拥堵和交通拥堵往往是无法预测的，并且看起来很混乱。 的确如此，但是如果我们花一点时间再考虑一下，地下交通拥堵甚至更加复杂。 例如，一场车祸给人们上下班上下班带来了意想不到的延误，以及影响整个社会的其他指数流。 《交通拥堵的成本和其他后果》一书的作者约翰·C·法尔科基奥（John C. Falcocchio）写道，“交通拥堵如何对都会区的生活质量和经济生产率产生不利影响”。 软件开发还会遇到交通拥堵，这会带来相关的成本和后果。
在这里我将做简短的介绍，因为我想很多人已经意识到软件开发中的“交通拥堵”正在使我们付出金钱。 由于这不是“交通拥堵”的完整列表，因此我鼓励您在下面的评论中分享开发软件时遇到的“交通拥堵”示例。
因此，以下是我在软件世界中经常观察到和遇到的一些流量拥堵情况：
- 将时间花在错误的优先级上 （虽然这似乎很明显，但通常很难发现。）
- 不必要的复杂性 （例如，在一次性原型中进行构建测试）
- 学习曲线陡峭的代码 （例如，架构上的过度优化）
- “ 责任的扩散 ” -当我们假设其他人将要采取行动时，我们什么也不做，但实际上我们的假设通常是错误的。
- 工作协调性差 （例如，在同一应用程序的同一区域并行工作的开发人员过多，会导致合并冲突等问题）
- 增加更多人以加快项目 进度 （请参阅“ 布鲁克定律 ”）
- 沟通中断会增加误解和错误
- 跨时区的团队没有有效的沟通方法/渠道 （研究表明，沟通成本可能会随着组织距离的增加而增加。）
- 工作负担过重 （例如，人们开始专注于“做事”，以赶上他们错过 批判性思维 的截止日期 ）
- 知识的损失和差距 （虽然这看起来很明显，但通常很难发现。）
在您问“那又是什么？”之前，请裸着我。 我认识到您可能已经意识到上面列出的交通拥堵，但是目的是要考虑这 会给 您的业务造成多大的损失，以及在开发软件时可能会比预期的贵得多 。 我相信这是一个真正的悬而未决的问题，我相信在软件领域已经有10多年的历史了，在有效解决当今软件界的交通拥堵方面，这仍然是一个巨大的挑战。
您如何改善使用{technique / method name}的方式 ？
接下来，我将分享一些技巧来帮助您入门。 有些您可能已经很熟悉，但是我建议您借此机会问“ 如何改善{technique / method name}的使用方式 ？”。 我还将介绍一些更复杂但可靠的技术，这些技术将填补现有软件实践中的空白。
这是要做好并不断改进。
可以轻松减少软件世界中的交通阻塞和拥塞。 我们已经知道这一点，因为过去（近）八十年来我们一直在尝试改善软件开发实践。 但是，重要的是要认识到，这不仅与“做到”有关，而且与“做好并持续改进”有关。 还值得注意的是，由于软件开发的纯粹本质，我们将永远无法消除拥塞-这是持续不断的“学习活动”，并且是由具有自然社会偏见的人们推动的活动。
让我们看一下4种基本技术，我们应该不断改进这些技术以使其性能良好。
1.不要假设，问“正确的”问题
很明显，我知道。 但是，混乱，快节奏和动态的软件开发环境的本质使我们无法提问。 因此，我们做出的假设要比我们愿意接受的更多，因为我们允许直觉来控制。 作为人类，我们喜欢采取捷径（也称为认知偏见）。 这意味着我们会反复错过进行批判性思考的机会。 因此，提出一个或多个问题可以防止您走上一条漫长而压力大的旅程，而不必走过去。 更重要的是，提出“正确”的问题有助于最大程度地减少软件开发中的“交通拥堵”。 但是知道要问哪些问题需要训练和练习，因为提出“正确”的问题并不容易。 世界50强企业创始人瑞克·史密斯（Rick Smith）写道：
“今天的领导人沉迷于答案。 …提出正确问题的能力将具有更大的价值。 在混乱的情况下，获胜需要集中精力，而知道要集中精力的地方将取决于您提出的问题。 将来，您作为领导者的效率将取决于您提出正确问题的能力。”
《您的犯罪现场代码》的作者亚当·托恩希尔（Adam Tornhill）以一个问题的形式描述了对康威定律的有用解释：“考虑到建议的软件体系结构，最佳组织应该如何实现它？”。 这个问题是有用的组织工具，使我们能够设计软件产品的共享部分，使其与组织结构更加一致。 话虽如此，这里还有一些其他示例问题可以帮助您入门：
- 我/我们有合适的团队吗？
- 如果团队成员离开，我们如何预测知识损失？
- 我们是否在衡量正确的绩效指标（针对团队，产品等）？
2.预测瓶颈和未来结果
我们可能已经知道，开发软件时出错或迟到是一项昂贵的活动。 这是由于昂贵的活动是“看不见的”。 但是，如果我们可以预测瓶颈和未来的结果，则可以为企业节省大量资金。
相隔十年，梅尔文·康威（Melvin Conway）和弗雷德·布鲁克斯（Fred Brooks）各自发表的研究表明，我们的组织与我们设计软件的方式之间存在联系。 这被分别称为康威定律和布鲁克定律。 这里的意思是，广泛的研究表明，从我们编写的代码中可以发现和学习很多东西。 因此，我们可以使用代码来预测瓶颈。 以下是我们可以预测的“什么”瓶颈的一些示例：
- 瑕疵
- 沟通中断（例如合并问题）
- 协调不力（例如，许多开发人员只在一个代码库中工作）
- 需要在哪些地方改进哪些开发实践
- 时间耦合
- 技术债务
另一方面，可以采用科学的建模方法来预测未来的结果，这与统计学家和精算师所使用的方法相同。 尽管更为复杂，但它提供了一种可靠的方法，可以在给定不同场景的情况下实现每种结果的机会。 由于这涉及到相当复杂的技术，因此在这里我将不做详细介绍，而是分享一些我们可以预测的示例。 这是我们可以从建模中学到的知识，因此可以预测未来的结果：
- 给定预期/期望的投资回报率，我们应该在一个项目上投资什么？
- 一个项目的可行投资是多少？
- 什么时候我们会失去“ 机会之窗 ”？
- 我们何时才能基于支出，软件开发和软件交付来耗尽投资？
- 如果我们想“走得更快”（又可以提高软件交付速度），要花多少钱？
预测瓶颈和未来结果的能力可以大大降低成本并提高软件开发效率。 有兴趣学习如何为您的企业做到这一点？ 发信息至hello@criticide.com
3.发现昂贵的做法
我们经常误解为解决问题而尝试适当执行的感觉。 因此，要确定最昂贵的软件开发实践并不容易。 例如，为什么我们不比较构建一套功能的成本与另一套功能的成本？ 还是为什么不将某个结果发生的可能性与另外两个替代方案的可能性进行比较？ 简短的答案是，我们认为它太难了，自然地，我们是无知的。
发现昂贵的实践需要相对更复杂的测量和分析技术，这些技术不能简单地在列表步骤或文章中进行解释，因为它涉及广泛的数学，自定义和批判性思维。 相反，我将分享一些可以发现的机会（但不仅限于此）：
- 我们的团队在开发软件过程中和内部的 知识损失 风险
- 由于个人创建的心理图（也称为“主观观点”），开发团队之间的知识障碍
- 通过“代码搅动” （代码更改的速率）来识别花在复杂合并上的时间-这是可以避免的吗？
- 瓶颈 ，例如。 协调不力导致并行工作
- 需要改进发展实践的地方
- 潜在的工艺损失
最终，发现产品开发过程和业务中昂贵的实践需要对问题（而不是症状）进行透彻的了解，并以可靠的证据，技能和经验进行评估。 如果我可以提出建议，那么与曾经做过这项工作的人取得联系总是一个很好的起点（请参阅杀灭杀虫剂）。
4.不要为了简单而牺牲精度
“我们为简化而交易精度…但是……总会有可能得出错误结论的风险。” — Adam Tornhill
当我们依靠直觉和思维捷径（系统1的思维）时，“我们以精确为代价，以求简单”。 但是这样做，“总是存在我们可能得出错误结论的风险”。 因此，尽管简单性对某些事物有好处，但对所有事物却不利。 精度也是如此。 在不确定性至上的软件世界中，至关重要的是要知道我们需要精度而不是简单性。 以下是我们在精度至关重要的情况下每天面对的一些不确定性：
- 我的团队可以交付多少容量？
- 我们会限期吗？
- 期望我们能够以100万美元的投资交付产品X是否合理？
- 我们是否可以通过追加投资25万美元和/或增加X个团队成员来更快地交付产品X？ （请注意，除非您有可靠的证据，否则通常都做一个坏主意。）
- 与采取行动A的风险相关的美元价值是多少？
最后，取决于我们选择如何开发软件。 构建成功的软件产品与我们如何管理不确定性高度相关。 这包括限制我们的批判性思维上限，以便我们知道何时需要精度而非简单性。
如果我们想到开发软件来进行旅行，那么我们很想到达目的地。 因此，与未知/不确定路线相比，首选已知路线。 但是，在软件开发中，没有所谓的已知途径。 因此，我们需要对如何应对不确定性具有战略性。 一厢情愿的想法不会使您走得太远，但是通过消除干扰（例如缺乏沟通，协调，目标不明确等）并进行批判性思考，我们便踏上了实现更可持续软件开发的道路。
编程是一种学习活动。 具有讽刺意味的是，我们必须尽早做出如此多的基本设计选择，直到我们对系统了解最少的时候。” — Adam Tornhill
与使用Google Maps从A点开车到B点的确定性不同，“编程是一种学习活动。 具有讽刺意味的是，在我们对系统了解最少的时候，我们必须尽早做出许多基本的设计选择。”
感觉自己可能想摆脱一个或多个交通拥堵？ 给我们发邮件hello@criticide.com，以探索我们如何提供帮助。
学到了什么？ 单击👏说“谢谢！”，并帮助其他人找到本文。
如果您喜欢内容，请按住拍手按钮！
拍50次！
