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

为什么软件开发方法学很烂
围绕软件开发实践和方法的宗教战争中有很多教条。阶段门方法是否可以有效地管理软件开发风险，或者仅仅是风险管理歌舞uki？TDD是否真的可以提供更高质量的软件？结对编程是代码审查的绝佳替代品，还是提高咨询率的一种方法？我要争论的是，尽管缺乏科学的证据来决定这些主张，但有两个通用原则可以帮助我们选择好的做法，同时提高我们提供的软件的价值：减少周期时间并增加反馈。
Michael Feathers进行以下观察：
我认为，最后，我们只需要接受开发人员技能比语言选择或方法上的细微差别1更重要的变量。坦白地说，我认为我们都知道这一点，但是我们似乎遭受了这样的迷惑，即它们是进行调整的主要旋钮。也许这是从经济学角度出发的深信不疑的观点的延伸，如果人们可以互换，那将是理想的选择。
问题是，我们如何获得熟练的开发人员？由于从未令人满意地定义IT中个人生产力的概念，因此这是一个特别难以解决的问题。代码行（仍然是一种流行的措施）遭受毁灭性的缺陷，即代码行是一种责任，而不是人们通常认为的一种资产。测量工作时间会鼓励英雄行为-但经验表明，“英雄”通常是同一个人，他们通过尽早承担不可接受的风险而导致项目迟到，长时间工作会使人变得愚蠢，并导致软件质量下降。对于IT专业人员来说，仍然没有一套公认的专业标准或特许制度，招募优秀人才基本上是一门艺术，而不是一门科学。
心理学家至少已经解决了为什么很难获得和衡量IT技能的问题。正如丹尼尔·卡尼曼（Daniel Kahneman）在《快与慢的思考》中所说，“掌握技能有两个基本条件：足够规则的环境可以预测； [以及]通过长期练习学习这些规律的机会。”
但是传统的软件项目与常规的可预测环境相反。项目成功的唯一良好衡量标准-最终结果是否在其生命周期内创造了预期价值？-与导致成功或失败的关键决策相距甚远，以至于原始团队中的任何人都很少出现，甚至无法获得反馈。几乎不可能确定其中哪些决定导致成功或失败（在人工智能中，这称为信用分配问题）。
这些因素使IT专业人员很难掌握导致成功的产品和服务的技能。取而代之的是，开发人员获得了使他们能够最有效地实现其激励目标的技能，通常是宣布他们的工作“尽快完成”，而不考虑其功能是否已集成并且可以投入生产。功能领域也是如此。
软件项目是复杂的系统而不是常规环境的事实导致了另一个问题-收集实际上有效的技术，实践和方法的数据极其困难，并且几乎不可能在其所处的环境之外归纳此数据。聚集。
在他的著作《软件工程的妖精》中洛朗·博萨维特（Laurent Bossavit）对软件开发民俗进行了毁灭性攻击，例如“变更成本”（或“缺陷成本”）“曲线”，声称开发人员生产力的差异是一个数量级，即确定性，以及软件开发中方法学知识的许多其他基石。他表明，这些理论-以及其他许多理论-依赖于从计算机科学系学生进行的非正式实验或无法有效控制的项目中收集到的极少量数据。构成这些主张基础的研究的组织通常在方法论上不健全，数据分析不充分，而且最令人震惊的是，研究结果普遍超出了其适用范围2。
结果，就敏捷开发实践是否比瀑布式开发实践更好，反之亦然，就不可能认真对待任何一般性主张。“思想领袖”的直觉也是一个糟糕的指南。正如Kahneman所说：“人们对直觉的信心并不是对其有效性的可靠指导……在评估专家直觉时，即使在正常环境下，您也应始终考虑是否有足够的机会学习线索。” 正如Ben Butler-Cole在他的同伴文章“为什么软件开发方法论会摇摇欲坠”中指出的那样，引入一种新方法论的行为本身可以产生采用该方法论者打算带来的一些结果。
您可能会认为，这在决定如何运营团队方面使我们处于不可能的境地。但是，请考虑一下为什么软件开发不是一个常规的环境，以及为什么很难进行实验，获得技能以及衡量哪些实践和决策导致成功以及哪些导致失败。在所有这些情况下（根本原因是环境不规则）是在进行更改与了解更改结果之间的反馈循环太长。此处的“变更”一词应被广泛理解为意味着需求变更，方法变更，开发实践变更，业务计划变更或代码或配置变更。
减少周期时间有很多好处-这是将精益思维应用于软件开发时出现的最重要的原则之一。短周期无疑是创造出色产品必不可少的：正如布雷特·维克托（Bret Victor）在令人叹为观止的视频《原则上的发明》中所说：“创造的大部分是发现，如果看不到自己的东西，就什么也找不到在做。”
但是对我而言，这才是硬道理：除非我们专注于以下方面，否则我们几乎不可能练习持续改进，学习如何以团队或个人的身分变得更好，并学到能够成功创造出优质产品和服务的技能。尽可能缩短反馈循环，以便我们实际上可以检测到相关性，并识别因果关系。
实际上，从构思到反馈的周期短的好处是如此重要，以至于它们应成为您的业务模型最重要的标准之一。如果您必须在将产品创建为用户安装的软件包还是将软件作为服务进行选择之间做出选择，那么这种考虑应该会大力推动您朝着软件即服务的方向发展（我从这里的经验出发）。如果您要构建一个涉及硬件的系统，请设法尽快获取原型。，以及如何模块化硬件和软件，以便可以快速独立地对其进行更新。3D打印很可能会在此领域产生巨大影响，因为它允许将软件开发实践应用于硬件系统的发展。如果您希望缩短周期时间，则跨职能团队的工作或多或少是一项要求。
软件方法论-甚至是“雇用一堆很棒的人，让他们自我组织”的方法论-之所以糟透了，因为他们常常导致货真价实的行为：我们在做站立式，有优先待办事项，甚至出于善良而练习持续集成-为什么我们制作的东西仍然很烂并且太迟了？因为您忘记了最重要的事情：建立一个尽可能快地学习和适应的组织。

1尽管正如Laurent Bossavit指出的（私人交流），“开发人员的技能部分是他/她所知道的方法以及他/她偏爱一种语言而不是另一种语言的原因。”
2我并不是在建议我们放弃运行实验来更多地了解软件开发中哪些有效，哪些无效以及此类声明有效的上下文-相反，我是说我们不尝试几乎够辛苦了

为什么软件开发论让你觉得糟糕？相关推荐

每个程序员必看：如何在40岁后继续做软件开发？
导读: 这是一个 42 岁的开发者所写经验分享文章．并且列出一些他 18 年多身为软件开发者的经验谈．许多部分看完后都会希望自己当时就能够了解,所以很推荐不论是新手或是老手都要好好阅读这一篇文章. 故 ...
软件开发向大数据开发过渡_如果您是过渡到数据科学的开发人员，那么这里是您的最佳资源...
软件开发向大数据开发过渡 by Cecelia Shao 邵Ce It seems like everyone wants to be a data scientist these days - fr ...
银行软件开发实习生_如何找到学生的软件开发人员实习生
银行软件开发实习生 by Grazietta Hof 由Grazietta Hof 如何找到学生的软件开发人员实习生 (How to find a Software Developer Interns ...
30年间，软件开发行业为何Bug纷飞？
作者 | Chris Fox 译者 | 弯月,责编 | 屠敏出品 | CSDN(ID:CSDNnews) [导语]在时间的推移历程中,软件行业早已发生了天翻地覆的变化.和曾经大家习以为常的编码日常相 ...
亚马逊是如何进行软件开发的
亚马逊是如何进行软件开发的呢?如果你确实对这个话题感兴趣,不妨邀请三五好友,订上几个披萨,然后一起坐下来观看这个对Ken Exner的精彩访问,他是AWS开发者工具部的部门经理.这里着重强调Ken来自 ...
益老而弥坚：软件开发哲学反思录
来自赛迪网,原作者未知益老而弥坚:软件开发哲学反思录注:这篇文章虽然年代久远(1996年写的,对于IT行业来说用'久远'二字应该说还是十分合适的),但读过之后还是为作者的才华所倾倒,这是不可多见 ...
Vaughn Vernon谈当今软件开发所面临的挑战
Vaughn Vernon举办了一场演讲,阐述了他所遇到的各种软件开发方面的严重问题,但也为这些问题提出了应对的方案.在他看来,大量的项目与开发团队都深陷设计糟糕的系统中难以摆脱,无数开发者在不停地为 ...
软件开发本质论——自然之路
版权声明:本文为半吊子子全栈工匠(wireless_com,同公众号)原创文章,未经允许不得转载. https://blog.csdn.net/wireless_com/article/details ...
软件开发基本原则（一）—— 策略和因素（转）
前言前段时间一直在写技术方面的文章,现在想转转口味,从软件开发过程和项目管理的角度来谈论软件开发.本座也知道,从这两个角度来谈论软件开发对谈论者来说是非常冒险的一件事情,它不像技术,对就对错就错 ...

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

为什么软件开发论让你觉得糟糕？相关推荐

最新文章

热门文章