https://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/阅读心得：软件工程方法论令租着觉得很糟糕，因为我们在真正的进行软件开发之前，并没有办法预测我该项目适用于哪种开发方法，如果一味的只知道死套前人的方法，束缚了思想，那肯定得不到预期想要的结果。用代码的行数取衡量一个开发人员的优劣，同样是不正确的。项目成功的唯一正确度量是最终的结果在生命周期里是否达到了预期目标。对项目获得的反馈少等因素IT专业人士很难获得成功产品和服务所需的技能。
软件开发是一个漫长的艺术过程，我们需要好好学习，认证总结，提高能力，才能在软件开发的路上，走得更好。任重而道远。。。
译文：
围绕软件开发实践和方法论的宗教战争中有很多教条。阶段门方法在管理软件开发风险方面有效吗，还是仅仅是风险管理歌舞伎？TDD真的能带来更高质量的软件吗？结对编程是代码审查的高级替代品，还是只是提高咨询率的一种方式？我要说的是，虽然缺乏科学证据来确定这些说法，但有两个一般原则可以帮助我们选择好的实践，同时提高我们交付的软件的价值：减少周期时间和增加反馈。
Michael Feathers发表了以下评论：
我认为，归根结底，我们必须承认，开发人员技能是一个比语言选择或方法上的细微差别重要得多的变量1。坦率地说，我认为我们都知道这一点，但我们似乎有一种错觉，认为它们是需要调整的主要旋钮。也许这是一种根深蒂固的观点的延伸，即从经济角度来看，如果人们可以互换，那将是理想的。
问题是，我们如何获得熟练的开发人员？由于IT中个人生产力的概念从未得到令人满意的定义，这是一个特别难以解决的问题。代码行（仍然是一种流行的度量标准）存在一个毁灭性的缺陷，即代码行是一种负债，而不是人们通常认为的资产。测量工作小时数会鼓励英雄行为——但经验表明，“英雄”通常是那些通过在早期承担不可接受的风险而导致项目延迟的人，长时间工作会让人变得愚蠢，并导致软件质量低下。目前还没有一套公认的IT专业人士职业标准或特许制度，招聘优秀人才在很大程度上是一门艺术，而不是一门科学。
心理学家至少已经解决了一个问题，即为什么学习和衡量it技能如此困难。正如丹尼尔·卡尼曼（Daniel Kahneman）在《快速思维和慢速思维》（Thinking Fast and Slow）一书中所说，“获得一项技能有两个基本条件：一个足够有规律、可以预测的环境；（以及）一个通过长期练习学习这些规律的机会。”
但传统的软件项目与常规的、可预测的环境相反。衡量一个项目成功的唯一好方法——最终结果是否在其生命周期内创造了预期价值？-与导致成功或失败的关键决策相去甚远，以至于原始团队中的任何人都很少在场获得反馈。几乎不可能确定这些决定中的哪一个导致了成功或失败（在人工智能中，这被称为信用分配问题）。
这些因素使得it专业人士很难获得成功产品和服务所需的技能。相反，开发人员获得的技能使他们能够最有效地实现激励他们的目标——通常会尽可能快地宣布他们的工作“开发完成”，而不管功能是否已集成并已准备好生产——其他功能领域也会出现类似的问题。
软件项目是复杂的系统，而不是常规环境，这一事实导致了另一个问题——收集技术、实践和方法论实际有效的数据的极端困难，以及几乎不可能在收集数据的环境之外推广这些数据。
洛朗·博萨维特（Laurent Bossavit）在他的优秀著作《软件工程的小妖精》（The Leprechauns of Software Engineering）中对软件开发的民间传说进行了毁灭性的攻击，例如“变更成本”（或“缺陷成本”）、“曲线”、开发人员生产率的变化是一个数量级的说法、确定性圆锥体的概念，以及软件开发方法论知识的许多其他基石。他指出，这些理论——以及其他许多理论——依赖于非常小的数据集，这些数据集要么来自计算机科学专业学生的非正式实验，要么来自不可能得到有效控制的项目。构成这些主张基础的研究组织在方法上往往不健全，数据分析不当，而且——最令人震惊的是——研究结果的普遍性远远超出了其适用范围。
因此，对于敏捷开发实践是否比瀑布式开发实践更好，或者说敏捷开发实践比瀑布式开发实践更好，我们不可能认真对待任何一般性的说法。“思想领袖”的直觉也是一个糟糕的向导。正如Kahneman所说，“人们对直觉的信心并不是对其有效性的可靠指导……当评估专家直觉时，你应该总是考虑是否有足够的机会去学习这些线索，即使在正常的环境中也是如此。”正如本·巴特勒·科尔在他的演讲中指出的那样
162
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
