Dark Scrum

“我最初的‘敏捷’导师Kent Beck曾经提到，他发明极限编程（Extreme Programming）的主要目的之一，是让程序员的生存环境变得更安全一些。然而事实证明，对程序员而言，这个世界尚不安全，尤其是乱用Scrum可能会给程序员带来更多的不安全问题，Scrum发明人之一Ken Schwaber曾说这种情况让他很难过。”在一次访谈中，Ron这样说道。

他在博客上分享了一篇帖子，主张开发人员应该放弃“敏捷”。该帖子进一步阐述了开发人员应远离“人造敏捷”的形式，而应更接近宣言的价值和原则。

据他称，“人造敏捷”和“黑暗敏捷”经常被用来形容各种所谓的“敏捷”方法，这些方法并不能改善开发人员的生活，而是《敏捷宣言》最初思想的对立面。Jeffries指出，发生这种情况的主要原因是：这种“敏捷”对企业有利，对开发人员则不利；开发人员依然不具有自主性，而是被强制性工作。因为借助各种不同的教练和培训，能够提高问题的可见性，通常可以使高层管理人员和公司做出更明智的决策。

自上而下地推行敏捷通常意味着某些事情是由高层决定，接着在整个组织中实施或推广。然而大多数人在没有经过适当的培训或指导、不理解其背后真实理念的情况下就被要求采用敏捷，这就会给开发人员带来的更多干扰，更短的工作时间，更大的压力以及要求“更快”的需求。在使用SAFe、LeSS和其他功能的大型Scrum实践中，会经常出现这种情况。

回到《敏捷宣言》的根源，Ron强化了这样一种观念，即敏捷背后的最重要的事情是思维方式、价值观和原则，因为它们能够提供构建软件的最佳方法。

因此，无论组织采用何种正式的框架或方法，每个敏捷开发人员都应以以下方式工作：每周产出可运行的集成软件；不断提升自身技能；保持软件设计干净；在软件价值的基础上进行沟通对话。