江苏龙网

  1. 首页 > 人文 > >

个Ruby On Rail 创始人讨论软件开发( 二 )


但是技术在宗教上几乎痴迷于速度 。如果您想专注于速度却又不相信估计 ， 那该如何工作？我们正在谈论进度和速度 。那实际上是两件事 。您可以尝试做得越来越快 ， 然后意识到自己实际上并没有前进 。我们对Shape Up的兴趣远不止于此 。最终将产生能够交付有意义的大量工作的项目 ， 客户和实施者对此感到自豪和满意 。试图将反馈回路缩小到不可能的很小 ， 这并没有改善 。这个想法是 ， 不断的反馈是一件好事 。是的 ， 出于某种原因！ 我不想不断评估自己的工作 。例如 ， 我们不进行冲刺 。按照Scrum和其他方法论的规定 ， 每两周重新调整工作是一种完全压抑和反复无常的工作方式 ， 只会使每个人精疲力尽 ， 实际上什么也没提供 。大多数人都无法在两周内交付真正的大型功能 。
真正的魔力在于将您的思维方式从预算转移到预算 。不要考虑花费多长时间 。考虑一下您愿意付出多长时间 。这颠倒了整个想法 。它使需求浮动 。模糊的项目定义实际上更现实 。高度具体的项目定义通常会很快误入歧途 。含糊不清的定义允许工作的人们发挥创造力和选择性 。而且 ， 当您考虑到这两件事时 ， 就可以授权代理商与这些人一起去做他们认为可以做的最好的工作 ， 而不仅仅是遵循规范 。
整个敏捷叛逆都是关于拒绝大型的前期设计 。但是我认为敏捷还没有得出足够的结论 。他认为：'我们不需要大型的前期设计 。我们只需要很少的前期设计' 。真的没有那么好 。许多软件方法学近距离地专注于实现的技术要求 。但是软件方面的艰苦工作正在弄清楚应该做什么 ， 而不是如何使它工作 。10x程序员有一个神话 。但这不是在解决问题方面英勇的程序员 。10x程序员是解决问题的程序员 。
重述问题确实应该在软件方法论的前列 。
当团队受困于两周的周期 ， 估算和制定规范时 ， 代码和决策的质量会受到影响吗？当然 。但不仅如此 。它导致了（我的意思是有点冒昧但不是那种冒犯）人类的痛苦 。在这种制度下工作的人只会被吃光和吐口水 。要每两周不断地重新评估您所做的所有事情 ， 因为那是新的Sprint周期开始的时刻–进度非常快 ， 无处可寻 。
这就是为什么我们不做每日站立 。这种持续不断的搅动 ， 在非常紧的皮带上绕圈旋转 。我认为这实际上是人性化 。敏捷再次说：'嘿 ， 你知道吗？ 您正在尝试进行为期两年的软件项目？ 这是一个完全的概念 。太遥远了 。是的 ， 绝对！ 但是后来 ， 敏捷方法学在最近被实践 ， 过度纠正并且太短了 。他说 ， 每天站立两个星期是这个神奇的周期 。不 ， 人们需要一些懈怠 。一些自主权 。一些空间 。
通过广泛的实验 ， 我们发现大约六个星期为我们提供了足够的呼吸和思考空间 。只要设定了界限 ， 即使每天看起来不一定像以前一样 ， 您也会取得进步 。您可能会发现在反馈循环方面 ， 团队的活动更加紧密 。他们疯狂地搅动 ， 但最终并没有取得更大的进步 。有时候 ， 跑得最快的团队是看上去很冷静的团队 。他们不是一直在某些方法论的跑步机上或在某个程序时钟上响！ 叮！ 叮！ 每五秒钟 。
个Ruby On Rail 创始人讨论软件开发文章插图
> 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个 。这就是您进行比较的方式 。
但这并不是说六个星期对每个人都有效 。我认为它实际上可以在数量惊人的情况下工作 ， 比两周的方法要频繁得多 。慷慨得多 。而且更现实的是 ， 您可以运送整个东西 。但是 ， 如果您不能在六周内交付完整的功能 ， 则您的反馈循环仍然太短 。如果我无法完成所有事情 ， 从创建 ， 实施到发货 ， 都在我的周期内完成 ， 那么周期太短了 。


推荐阅读


上一篇：iPhone 12选购前瞻！官方充电头可能还是必选项

下一篇：Win10 2004补丁更新 增强系统安全性