个Ruby On Rail 创始人讨论软件开发如果您要总结软件开发的整个过程

如果您要总结软件开发的整个过程，您会说："该项目迟到了，它被取消了" 。
文章插图
> Building software with David Heinemeier Hansson. Illustration by Gabi Krakowska.
我们已经到了《困难的计算机》的结尾。在讨论了各个软件组件的组成方式（从打印机驱动程序到密码哈希）后，我想总结一下构建软件产品的原理。
也许有些尴尬，但是即使经过了几年的行业发展，我仍然不明白为什么高科技公司如此着迷于速度。这种迷恋被融入软件的语言中，其中工作周期称为冲刺，进度的度量称为速度。但是，快速交付软件真的那么重要吗？我不知道。我不是自己开发软件，而是每天都对它进行故障排除，还是有时候，我希望工程师的工作速度稍慢一些。
我将有关构建软件方法论的问题带给了一个对该主题进行过激烈辩论的人。David Heinemeier Hansson创建了Ruby on Rails ，是Basecamp的联合创始人兼CTO ，并且是商业书籍（例如Rework）的作者。他还擅长与行业趋势抗衡，不管这些趋势是技术性的（例如微服务的日益普及）还是机构性的（例如风险资本成为发展高科技业务的默认方式）。我们讨论了当今的软件构建方式，对进行构建的人员意味着什么以及如何构建软件。
享受《困难的计算机》的最后一章。
Wojtek Borowicz：软件方法学是其自己的行业。有Scrum ， Agile ，教练，书籍以及所有这些。但是您和您的Basecamp团队不遵循这些做法。为什么？DHH：首先，我们的软件开发方法受到敏捷宣言和敏捷价值观的极大启发。它并没有像今天那样受到敏捷实践的启发。
许多敏捷软件方法论侧重于产品开发领域，而这些领域并不难。它们与程序结构息息相关。在大多数情况下，软件本质上是不可预测的，不可知的和不可变形的。几乎就像气体一样。它可以适应来自同一基本思想的各种不同的开口。尝试估计功能需要花费多长时间的想法不起作用，因为您不知道自己要构建的内容，而且人类很难估计任何东西。软件开发的历史是最近或被取消的项目之一。如果您要总结软件开发的整个过程，您会说："该项目迟到了，它被取消了" 。可以这么说，规划工作无效。
我们在Basecamp所做的选择是将Shape Up贴上标签，仅仅是因为那是我们发现需要努力的地方。我们正试图接受核心约束条件，即不可能准确地指定应该先执行哪些软件。您只能发现在限制条件下应该做什么。但是，这也不像我们遵循完成后完成的想法。那是产品管理思想的绝对放弃。相反，我们所说的是：不要做估算，不要做预算。Shape Up的核心是预算。不是要花多长时间，而是值得。因为某些事情可能需要一周或四个月的时间。值多少钱？
在整个工作周期中，有些事情值得（通常是极限），对我们来说这是六个星期。这就是我们所谓的大批量生产。否则它的价值可能会比这少。也许只有一个星期，也许是两个星期。那是一小批。这需要模糊的项目陈述"让我们添加特征A" ，将其置于约束之下，然后由代表来确定实施工作的对象。这就是这里的关键见解。如果您有一个大的问题定义和一个固定的边界，并且给有创造力的聪明人自由选择这些条件内的解决方案的能力，他们将做出色的工作，他们为此感到自豪。
敏捷清单
在2001年，由17名男性（当然是零女性）组成的小组发布了一份文件，为未来20年的软件开发设定了方向。他们的《敏捷宣言》将敏捷软件开发的原则进行了整理。这些想法是基本的（例如："工作软件是进度的主要衡量标准"和"简单性至关重要"），但它们催生了敏捷教练，顾问和作家的整个领域。
因此，这些方法的问题在于它们过分注重估算，而软件本身是不可能做到的？我走得更远，说估计是胡说八道。它太不精确了，甚至在处理固定输入时也没有用。而你不是。在看到软件之前，没有人能够准确地描述该软件应该做什么。我们可以抢先描述开始做某事之前应该做些什么的想法简直是铺天盖地。敏捷的想法是，您需要运行软件来获取反馈，但是敏捷的现代实现并没有接受他们自己所教的课程。