过于殷勤（敏捷）的侍者会让你美好的一餐糟糕无比。 然而，离开“敏捷”的“持续交付”餐馆，旁边还有“瀑布”餐吧。 嗷，这个快节奏的年代！ 注： “敏捷” （ agile ） 开发、 “持续交付” （ Continuous Delivery ） （CD）和 “瀑布” （ waterfall ） 式开发都是软件开发术语。瀑布式开发/瀑布模型是一种传统的、过时的开发模式，其得名于开发阶段按顺序衔接，如瀑布

在这个列表中，没有项目管理软件，这里不包含清单，也没有与 GitHub 整合，只是几种组织思维和提高团队交流的方法。 你也许经常听说下面这句话：工具太多，时间太少。为了节约您的时间，我列出了几款我最常用的提高敏捷团队工作效率的工具。如果你也是一名敏捷主义者，你可能听说过类似的工具，但我这里提到的仅限于开源工具。 请注意！ 这些工具和你想象的可能有点不同。它们并不是项目管理软件——这领域已经有一篇好

在这篇开源项目管理工具的综述中，让我们来了解一下支持 Scrum、 看板 Kanban 等敏捷开发模式的软件。 Opensource.com 以前对流行的开源项目管理工具做过相应的调研。但是今年我们增加了一个特点。本次，我们特别关注支持敏捷方法的工具，包括相关的实践，如 Scrum、Lean 和 看板 Kanban 。 对敏捷开发的兴趣和使用的增长是我们今年决定专注于这些工具的原因。大多数组织（7

专家回答了敏捷实践如何帮助团队更有效的 6 个常见问题。 “有问题么？” 你可能听过演讲者在演讲结束的时候提出这个问题。这是演讲中最重要的部分 —— 毕竟，你不仅仅是听讲座, 而是参加讨论和社群交流。 最近，我有机会听到我的同伴 Red Hatters 给当地一所大学的一群技术型学生做一个名为 “敏捷实践” 的讲座。讲座中有软件工程师 Tomas Tomecek 和敏捷开发的从业者 Fernand

当我们开始推行敏捷时，还没有容器和 Kubernetes。但是它们改变了过去最困难的部分：将敏捷性从小团队应用到整个组织。 越来越多的企业正因为一个非常明显的原因开始尝试敏捷和 DevOps: 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而 DevOps 将帮助我们得到所需的创新速度。但是，在小团队或初创企业中实践 DevOps 与进行大规模实践完全是两码事。我们都明白这样的一个事实

请阅读我们的热门文章，这些文章着重讨论了敏捷的过去、现在和未来。 对于 Opensource.com 上的敏捷主题来说，2019 年是非常棒的一年。随着 2020 年的到来，我们回顾了我们读者所读的与敏捷相关的热门文章。 小规模 Scrum 指南 Opensource.com 关于小规模 Scrum 的指南（我曾参与合著）由六部分组成，为小型团队提供了关于如何将敏捷引入到他们的工作中的建议。在官方

你更专注于安全性还是软件交付，还是可以两者兼得？ 技术社区中存在一种趋势，经常互换地使用 DevSecOps 和敏捷软件开发这两个术语。尽管它们有一些相似性，例如都旨在更早地检测风险，但在改变团队的工作方式层面有很大不同。 DevSecOps 建立在敏捷开发建立的一些原则上。但是，DevSecOps 特别专注于集成安全功能，而敏捷开发则专注于交付软件。 知道如何保护你们的网站或应用程序免受勒索程序

传统的项目管理理念中，瀑布和敏捷两种项目模式泾渭分明，市面上所有的研发管理软件，也是基于传统的理念，只能2选1，非常死板。      2选1的模式一点都不与时俱进，为什么这样说呢？受敏捷思想的影响，在实际项目实践中，不是完完全全按瀑布来，而是采用“小”瀑布模式，这里的“小”，就是在阶段内执行不同的计划（类似于一个阶段下有多次迭代），每个计划都有可验证的产出物，以防“大"瀑布那种，最后才发现问题，修