敏捷开发 瀑布式开始_新敏捷–开始

敏捷开发 瀑布式开始

该博客的常识读者知道我是敏捷的大提倡者，带有一个小“ a”。 我倾向于嘲笑似乎从营销委员会中跳出来的新的大创意。

事实是，有时候这些都是好主意。 有时它们是反复试验的第一个版本。 当我们在当前阶段查看它们时，它们看起来似乎很荒谬，但是如果有人接触到它们并继续推动，我们可能会得到一些奇妙的东西。 就像质量一样，我们在事后有时甚至数年后才能得到真正的判断。

因此，我决定抛弃一些玩世不恭的态度，并尝试着眼于敏捷宣言以来发生的事情。 名为“新敏捷”的帖子集是我进行“新敏捷”演示文稿的背后。 我提出了敏捷世界中的不同主题。 一些信息将伴随我的观察，而一些信息只是鼓励您学习，如果他们感兴趣的话。 会有建议，但特别是我感兴趣的地方。 可能对每个人来说都不一样。

在开始之前，我们需要回顾一下如何到达这里。 像许多示例一样，我首先回到敏捷宣言。

“我们正在探索通过开发软件并帮助他人开发软件的更好方法。”

2001年在犹他州雪鸟市滑雪的17位聪明人在一句话中将科学应用于软件开发。 我们的想法是，我们并不了解所有内容，但我们会继续尝试，学习，失败并重试。 我们的想法是，如果有更多的人这样做，我们将增加学习。 软件开发不是一个单一的过程，而是不同的路径，这种想法我们甚至还没有发现。

好主意。

今天，这些仍然是正确的，因此我们已经学到的东西可能不是开发软件的最佳方法。 例如，似乎在TDD进行了将近20年之后，我们找不到更好的东西，因此这是最佳实践。 但是明天我们可能会发现更好的东西。

这些事情不是从2001年开始的。那是他们刚起名的时候。

如果我们回顾历史，我们可以看到不同的人在获得他们的名字之前就学习并应用精益原则。 以W. Edwards Deming为例。 第二次世界大战后，他去了日本，并确立了敏捷的基础：PDCA周期：计划，执行，检查和调整。 这是不断学习和改进的基础。 戴明为丰田制造流程奠定了精益基础。 如果您正确地构建了桥梁，那么多年后，“开发软件并不像在构建桥梁”，这可能会让您感到震惊。

像是可以停止生产线的生产线工人的想法是持续集成的源头。 不相信我吗 在有效的CI中，当构建中断时会发生什么？ 修复它是最大的优先事项。 这不是一项管理令。 在这种文化中，开发人员停止了他们正在做的事情，并使构建重新步入正轨，并且他们的决策得到了管理层的支持。 就像生产线工人停止生产线一样。 质量是第一，文化支持它。

所以我们有了这些想法，但是因为直到90年代我们还没有真正的互联网，想法才以今天的速度进行交换。 沟通仍然有限。 因此，当肯·施瓦伯 （ Ken Schwaber）和杰夫·萨瑟兰 （ Jeff Sutherland）等人开始从事Scrum工作， 肯特·贝克 （ Kent Beck）和罗恩·杰弗里斯 （ Ron Jeffries）从事eXtreme编程工作， 阿利斯泰尔·考克博恩 （ Alistair Cockborn）从事水晶工作时，他们就是在与团队合作。 为了支持顾问的营销工作而使用了不同的名称，但是从根本上来说，它只是“与团队合作”。

他们交流思想的方式是古老的方式：论文，书籍和会议。 您应该记住，那时关于这些事情的会议并不多。 大多数情况下是程序员会议（那时没人敢考虑为测试人员举行会议）。 有业务管理会议，但是他们对开发人员的玩法并不真正感兴趣。

然后互联网发生了。 就像识字，然后印刷一样，互联网为爆炸式的知识提供了途径，并以更大的比例覆盖了更多的受众。 最后，想法“按比例缩放”。 他们相互比较，讨论，面对和运用。 有些成功，有些不好，有些则狡猾。

敏捷宣言发布后的几年，商业世界已经准备好停下来，并听到一些来自橄榄球的名称的开发方法。

在大多数情况下，我们会说剩下的就是历史了。 但这仅仅是开始。

翻译自: https://www.javacodegeeks.com/2014/12/the-new-agile-the-beginning.html

敏捷开发 瀑布式开始