为什么软件开发方法论让你觉得糟糕？

为什么软件开发方法论让你觉得糟糕

围绕软件开发实践和方法的宗教战争中有很多教条。阶段门方法是否可以有效地管理软件开发风险，或者仅仅是风险管理歌舞uki？TDD是否真的可以使软件质量更高？结对编程是代码检查的上乘替代品，还是提高咨询率的一种方法？我将争辩说，虽然缺乏科学的证据来决定这些主张，但有两个通用原则可以帮助我们选择良好的做法，同时提高我们提供的软件的价值：减少周期时间并增加反馈。

Michael Feathers进行以下观察：

我认为，最后，我们只需要接受开发人员技能比语言选择或方法上的细微差别1更重要的变量。坦白地说，我认为我们都知道这一点，但是我们似乎遭受了这样的迷惑，即它们是进行调整的主要旋钮。从经济学的角度来看，这也许是人们深信不疑的观点的延伸，如果人们可以互换，那将是理想的选择。

问题是，我们如何获得熟练的开发人员？由于从未令人满意地定义IT中个人生产力的概念，因此这是一个特别难以解决的问题。代码行-仍然是一种流行的措施-遭受毁灭性的​​缺陷，即代码行是一种责任，而不是人们通常认为的资产。测量工作时间会鼓励英雄行为-但经验表明，“英雄”通常是同一个人，他们通过尽早承担不可接受的风险而导致项目迟到，长时间工作会使人变得愚蠢，并导致软件质量下降。对于IT专业人员来说，仍然没有一套公认的专业标准或特许制度，招募优秀人才基本上是一门艺术，而不是一门科学。

心理学家至少已经解决了为什么很难获得和衡量IT技能的问题。正如丹尼尔·卡尼曼（Daniel Kahneman）在《快与慢的思考》中所说，“有两个获得技能的基本条件：一个足够规则的环境，可以预测；并且有机会通过长期练习来学习这些规则。”

但是传统的软件项目与常规的可预测环境相反。项目成功的唯一良好衡量标准-最终结果是否在其生命周期内创造了预期价值？-与导致成功或失败的关键决策相距甚远，以至于原始团队中的任何人都很少出现，甚至无法获得反馈。几乎不可能确定其中哪些决定导致成功或失败（在人工智能中，这称为信用分配问题）。

这些因素使IT专业人员很难掌握成功生产产品和服务的技能。取而代之的是，开发人员获得了使他们能够最有效地实现其激励目标的技能，即通常宣布他们的工作“尽快完成”，而不考虑功能是否已集成且可投入生产，而其他方面也会出现类似的问题。功能领域也是如此。

软件项目是复杂的系统而不是常规环境的事实导致了另一个问题-收集实际上有效的技术，实践和方法的数据极其困难，并且几乎不可能在其所处的环境之外归纳此数据。聚集。

在他的著作《软件工程的妖精》中洛朗·博萨维特（Laurent Bossavit）对软件开发民俗进行了毁灭性攻击，例如“变更成本”（或“缺陷成本”）“曲线”，声称开发人员生产力的差异是一个数量级，即确定性，以及软件开发中方法学知识的许多其他基石。他表明，这些理论-以及其他许多理论-依赖于从计算机科学系学生进行的非正式实验或无法有效控制的项目中收集到的极少量数据。构成这些主张基础的研究的组织通常在方法论上不健全，数据分析不充分，而且最令人震惊的是，研究结果普遍超出了其适用范围2。

结果，就敏捷开发实践是否比瀑布式开发实践更好，反之亦然，就不可能认真对待任何一般性主张。“思想领袖”的直觉也是一个糟糕的指南。正如Kahneman所说：“人们对直觉的信心并不是对其有效性的可靠指导……在评估专家直觉时，即使在正常环境下，您也应始终考虑是否有足够的机会学习线索。” 正如Ben Butler-Cole在他的同伴文章“为什么软件开发方法论会摇摇欲坠”中指出的那样，引入一种新方法论的行为本身可以产生采用该方法论者打算带来的一些结果。

您可能会认为，这在决定如何运营团队方面使我们处于不可能的境地。但是，请考虑一下为什么软件开发不是一个常规的环境，以及为什么很难进行实验，获得技能以及衡量哪些实践和决策导致成功以及哪些导致失败。在所有这些情况下（根本原因是环境不规则）是在进行更改与了解更改结果之间的反馈循环太长。此处的“更改”一词应非常普遍地理解为意味着需求变更，方法变更，开发实践变更，业务计划变更或代码或配置变更。

减少周期时间有很多好处-这是将精益思维应用于软件开发时出现的最重要的原则之一。短周期无疑是创造出色产品所必不可少的：正如布雷特·维克托（Bret Victor）在令人叹为观止的视频《原则上的发明》中所说，“创造的大部分是发现，如果看不到自己的东西，就什么也找不到在做。”

但是对我而言，这才是硬道理：除非我们专注于以下方面，否则我们几乎不可能练习持续改进，学习如何以团队或个人的身分变得更好，并学到能够成功创造出优质产品和服务的技能。尽可能缩短反馈循环，以便我们实际上可以检测到相关性，并识别因果关系。

实际上，从构思到反馈的周期短的好处是如此重要，以至于它们应成为您的业务模型最重要的标准之一。如果您必须在将产品创建为用户安装的软件包还是将软件作为服务进行选择之间做出选择，那么这种考虑应该会大力推动您朝着软件即服务的方向发展（我从这里的经验出发）。如果您要构建一个涉及硬件的系统，请设法尽快获取原型。，以及如何模块化硬件和软件，以便可以快速独立地对其进行更新。3D打印可能会在该领域产生巨大影响，因为它允许将软件开发实践应用于硬件系统的发展。如果您希望缩短周期时间，则跨职能团队的工作或多或少是一项要求。

软件方法论-甚至是“雇用一堆很棒的人，让他们自我组织”的方法论-之所以糟透了，因为他们常常导致货真价实的行为：我们在做站立式，有优先待办事项，甚至出于善良而练习持续集成-为什么我们制作的东西仍然很烂并且太迟了？

因为你忘记了最重要的事情：建立一个尽可能快地学习和适应的组织。

原文链接：https://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/