为什么敏捷框架的所有定义都是手动的？

Question

以维基百科的定义为例：

敏捷软件开发是一种软件开发的方法，在这种方法下，需求和解决方案是通过自组织和跨功能团队及其客户(S)、/end用户(S)的协作努力而进化的。

这句话是怎么说的？这是说

开发人员组致力于改变问题并相互交流。

这并没有描述如何解决问题，团队的结构(除了团队的存在)，管理，敏捷的目标受众，甚至它是如何实现的。维基百科的整篇文章都是这样的。就像广告一样。

现在我不是软件工程的新手了，我可以清楚地看到，这个定义是为了尽可能多地激起流行词，这意味着它的意思是吸引高层管理人员。

这就引出了我的问题，为什么敏捷开发的所有定义都是手动的，我在哪里可以找到敏捷的简单但技术性的描述呢？

Answer 1

因为敏捷不是一个框架。这是一种心态。

流程和工具上的个人和交互--不要告诉您的开发人员遵循某些脚本。人们应该互相交谈，而不是机器上的齿轮。

工作软件超过全面的文档-软件的重要性，而不是软件的承诺。演示和示例比没有人阅读的用户指南更有效。

客户合作而不是合同谈判--当你和客户一起工作时，事情会更好，而不是为了几个月前你同意做的事情而争吵。

按照计划来应对改变--这才是关键所在。敏捷承认人类无法预测未来。一切都变了。需求变化。技术的变化。人们会生病的。人们都会离开。因此，敏捷心态是指你不再试图为每一种可能发生的事情做计划；不要为人们事先制定一个严格的计划，让人们去遵循。

心态是重要的，而不是你采取的步骤。

Answer 2

敏捷是一个一组值，而不是一个过程框架。事实上，其中一个主要的价值观是个人而不是过程--而不是坚持一个僵化的框架，而是找到一种适合相关人员的工作方式。

敏捷版空间中有各种各样的框架可用于启动，最显著的是面向产品开发和咨询项目的Scrum。但是这些框架没有什么共同之处，除了“定期审查您的流程并根据需要对其进行调整”。

将敏捷描述为过于模糊而没有帮助是公平的。对围绕这些价值观形成的充满流行语的“敏捷-工业情结”(同样，最引人注目的是Scrum)的嘲讽也是公平的。因此，我建议问：

1. 这个软件项目应该与敏捷价值观保持一致吗？答案可以是合理的“不”。
2. 这个软件项目如何更好地表达这些价值？例如，我们如何才能更容易地响应不断变化的需求？
3. 我们不是第一个尝试这样做的人。我们怎样才能向其他人学习这些价值观呢？这可能意味着完全采用现有的过程，或者试验敏捷的技术。

Answer 3

敏捷软件开发宣言是关于一种心态的转变和一种文化的改变。在这个领域中，每个定义中没有简单的敏捷技术定义。

敏捷是所有个人和组织的文化转变之旅，其目标是变得敏捷，即改变组织的文化和个人的心态。如果你不这样做，你只是在做敏捷的戏剧。

因此，为了成为规定性和技术性的，你需要接受这些价值观和原则，并为自己描述--为了使用这些准则--我们需要改变什么？

然后开始你的改变之旅，使用一些提到的框架(最好的适合使用组合-- XP、Scrum/Kanban、精益软件开发)作为起点和组织变革方法，例如(按字母顺序排列--市场上可以找到许多其他的)，你需要确保公司帮助你适应你的组织、目标和合适的人选：

Kotters 8步进程加速变革

Prosci ADKAR

使用Sociocracy 3.0开发敏捷和弹性组织的实用指南