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

真正的魔力在于将您的思维方式从预算转移到预算。不要考虑花费多长时间。考虑一下您愿意付出多长时间。这颠倒了整个想法。它使需求浮动。模糊的项目定义实际上更现实。高度具体的项目定义通常会很快误入歧途。含糊不清的定义允许工作的人们发挥创造力和选择性。而且，当您考虑到这两件事时，就可以授权代理商与这些人一起去做他们认为可以做的最好的工作，而不仅仅是遵循规范。
整个敏捷叛逆都是关于拒绝大型的前期设计。但是我认为敏捷还没有得出足够的结论。他认为：'我们不需要大型的前期设计。我们只需要很少的前期设计' 。真的没有那么好。许多软件方法学近距离地专注于实现的技术要求。但是软件方面的艰苦工作正在弄清楚应该做什么，而不是如何使它工作。10x程序员有一个神话。但这不是在解决问题方面英勇的程序员。10x程序员是解决问题的程序员。
重述问题确实应该在软件方法论的前列。
当团队受困于两周的周期，估算和制定规范时，代码和决策的质量会受到影响吗？当然。但不仅如此。它导致了（我的意思是有点冒昧但不是那种冒犯）人类的痛苦。在这种制度下工作的人只会被吃光和吐口水。要每两周不断地重新评估您所做的所有事情，因为那是新的Sprint周期开始的时刻–进度非常快，无处可寻。
这就是为什么我们不做每日站立。这种持续不断的搅动，在非常紧的皮带上绕圈旋转。我认为这实际上是人性化。敏捷再次说：'嘿，你知道吗？您正在尝试进行为期两年的软件项目？这是一个完全的概念。太遥远了。是的，绝对！但是后来，敏捷方法学在最近被实践，过度纠正并且太短了。他说，每天站立两个星期是这个神奇的周期。不，人们需要一些懈怠。一些自主权。一些空间。
通过广泛的实验，我们发现大约六个星期为我们提供了足够的呼吸和思考空间。只要设定了界限，即使每天看起来不一定像以前一样，您也会取得进步。您可能会发现在反馈循环方面，团队的活动更加紧密。他们疯狂地搅动，但最终并没有取得更大的进步。有时候，跑得最快的团队是看上去很冷静的团队。他们不是一直在某些方法论的跑步机上或在某个程序时钟上响！叮！叮！每五秒钟。
文章插图
> You can tell this is a stock photo because no one is that enthusiastic during a standup meeting. P
您相信您的Shape Up方法可以在更大的组织中工作吗？一个拥有500或5,000个而不是50个工程师的工程师？首先，您不应该考虑能够从五个人扩展到五千人的软件方法论。试图为一个单位计划5,000人的工作是一个愚蠢的事情，但实际上没有人这样做。更为有趣的方法是：对于任何公司，适当的团队限制一般是多少？假设有500个大型公司，则是100个团队，每组5个。这就是您进行比较的方式。
但这并不是说六个星期对每个人都有效。我认为它实际上可以在数量惊人的情况下工作，比两周的方法要频繁得多。慷慨得多。而且更现实的是，您可以运送整个东西。但是，如果您不能在六周内交付完整的功能，则您的反馈循环仍然太短。如果我无法完成所有事情，从创建，实施到发货，都在我的周期内完成，那么周期太短了。
如果您从事本机应用程序开发，并且声誉很高，那么也许六个星期的时间还不够。也许您还需要更多。或者可能不是。这取决于您是否可以运输要运输的物品。但是整个行业已经开始思考"哦，两周是一个很好的时间表" 。什么？我们如何变得如此确定？即使对于一家拥有5,000名员工的公司来说，六个星期也是一个比较现实的起点。
您还不太满意地谈到了软件开发中出现的其他趋势，例如微服务和无服务器或测试驱动开发。您实际上是否对软件工程学中的任何趋势感兴趣？这是一个棘手的问题。找出我不喜欢的所有东西要容易得多。
显然，我有些偏见，因为我在推动这些事情。我正在实施Ruby on Rails和Shape Up ，并分享了一些我认为应该如何进行软件开发的知识。这并不意味着没有其他方法可以做到。Web开发有各种各样的技术堆栈和方法，这些使我微笑。我很高兴看到我们在JavaScript开发方面取得的进步。前端发生的升级在原子级别上非常出色。我认为我们误入歧途的是分子水平。人们采用的框架和方法都不是很好，但是我认为基础的技术改进是通过编译器， polyfilling和JavaScript在这些版本上的核心进展。