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

---

前言

Michael Feathers发表了这样的观点:
I think that, in the end, we just have to accept that developer skill is a far more significant variable than language choice or methodological nuances1. Frankly, I think we all know that, but we seem to suffer from the delusion that they are the primary knobs to tweak. Maybe it’s an extension of the deeply held view that from an economic viewpoint, it would be ideal if people were interchangeable.
他认为开发人员技能是一个比语言选择或方法论细微差别更重要的变量。

Why Software Development Methodologies Suck?

要搞清楚这个问题，你首先就要清楚什么是软件开发方法论，它与软件开发模型,软件过程有什么联系?为什么它会让我们感觉很糟糕呢?下文做出了本编个人的见解。

---

一、软件开发方法论

软件开发方法论就是根据待开发的软件特点设计相应的开发流程，就是把一个大事情，拆分成一个一个的小事情，再把这些小事情串起来组成一个大事情。经过不断的实践，效果非常明显的开发流程就固定了下来，形成了“开发模型”。
如果你还不是很清楚它的定义，建议查看小编之前写的一篇文章 ：
软件工程方法论对我们经软件开发有多大用处？

---

二、我们感觉糟糕的原因

一、问题是我们如何找到有技能的开发人员？由于信息技术中个人生产力的概念从未得到令人满意的定义，这是一个特别难以解决的问题。代码行仍然是一个流行的衡量标准，遭受了一个毁灭性的缺陷，即一行代码是一种负债，而不是人们通常认为的资产。衡量工作时间会鼓励英雄行为，但经验表明“英雄”通常是那些在早期就承担不可接受的风险而导致项目延期的人长时间工作会使人变得愚蠢，并导致软件质量低下。对于IT专业人士，目前还没有一套公认的专业标准或特许制度，招聘优秀人才在很大程度上是一门艺术，而不是一门科学。

二、传统的软件项目与常规的、可预测的环境是相反的。衡量项目成功与否的唯一标准——最终结果是否在其生命周期内创造了预期价值与导致成功或失败的关键决策相距甚远，以致于原始团队中的任何人都很少能在场获得反馈。几乎不可能确定哪一个这些决定中的任何一个都会导致成功或失败。

在人工智能中，这被称为信用分配问题。

三、开发人员获得的技能使他们能够最有效地实现激励他们的目标——通常尽可能快地宣布他们的工作“开发完成”，而不管功能是否已集成和生产就绪，在其他功能领域也会出现类似的问题。软件项目是一个复杂的系统而不是常规的环境，这一事实导致了另一个问题：收集技术、实践和方法实际有效的数据非常困难，并且几乎不可能在收集数据的上下文之外概括这些数据。

四、软件方法学:是“雇佣一群优秀的人，让他们自我组织”的方法都很糟糕，因为它们常常会导致货物崇拜行为：我们做的是站起来，我们有一个优先的积压工作，我们甚至为了上帝的缘故在实践持续的集成——为什么我们制作的东西仍然是肮脏和迟来的？因为你忘了最重要的事情：建立一个组织它能尽快学习和适应。

---

总结

当然，我并不是建议我们放弃运行实验来了解在软件开发中什么是有效的，什么是无效的，以及这些声明在什么环境下是有效的。恰恰相反，我是说我们还不够努力。事实上，从想法到反馈的短周期时间的好处非常重要，因此它们应该成为商业模式最重要的标准之一。不可能的对于我们来说，要练习持续改进，学习如何作为团队或个人变得更好，并获得能够成功地创建伟大产品和服务的技能，除非我们专注于让反馈循环尽可能短，这样我们才能真正地发现相关性，并辨别因果关系。
推荐阅读:https://continuousdelivery.com/2012/08why-software-development-methodologies-suck/