我观察到我已经遇到的所有命名方法可以映射到Babok概念上，Babok是它们的超集。   

这是上下文的宣言本身（派生来自敏捷组织自己的网站 www.agilemanifesto.org. ）：

宣言敏捷软件开发

我们正在揭示通过这样做和帮助他人开发软件的更好方式。通过这项工作，我们来到了价值：

1.个人和对流程和工具的互动
2.通过全面文件的工作软件。
3.客户合作合同谈判
4.响应遵循计划的变更

也就是说，虽然项目中有值
右侧，我们将左侧重视物品。

---------------------------------------------------------------- ---------------------------

在这里是一个分析，基于一般知识，个人经验和巴布奥布概念：

• BA基本面（并因此在工具内容之前必须出现所需的基本技能）。工具只能支持称职，有效的行为，而不是创建它。从某种意义上说，所有成功的项目都是“敏捷” - 我观察到所有成功的项目都充满了快速和自由互动的辉煌个人。这个单一因素似乎弥补了其他一切 - 欢迎各种各样的东西，我没有。
• 通过文档的软件已经是软件开发中最常见的方法，因此很难理解为什么这是“敏捷”。由于在软件开发中已经实现了65％的“失败”率，如果敏捷是有效的，它必须是1,3和4的物品。
• 替代“与利益攸关方的迭代”进行“客户合作”，并替代“合同”的“瀑布要求”。在他们最糟糕的情况下，合同是在理解之前“锁定要求”，导致承包商的过度变化秩序利润（允许更改）或失败的利益相关者接受（当他们不是）。瀑布要求最适合“一拍”像月球计划这样的努力。
• 在规划中，并不愿调整计划作为要求“学习”，显然是某些项目失败的原因 - 它主要是智力的失败（见第1项）。从这个概念中缺少的是企业分析的想法（特别是风险分析，利益相关者分析和成本效益分析）以及必须从这些中遵循的要求计划。另一个方法是 - 如果项目足够简单且低风险，敏捷可能是适合（请参阅企业分析部分中的Bok Tables 3.0和4.0，并查看您是否可以发现哪些项目可能使用敏捷。

因此，从分析到意见（如果您拥有自己的意见，请发送，我们将重新回复并报告同样）：

在我看来：敏捷过程适合某些类型的项目，但几乎不会。这是我的列表 - 你的是什么？

“小马铃薯” - 风险低，不必满足少数用户具有均匀兴趣的高回报系统，具有低的可见性，或者代表已验证，成功增量到已经成功的系统（是，维护和增强）。

 “可行性”或“概念证明”试验，可以清除更多投资在更大的项目中的方式？

 “研究”项目，几乎全部都是未知的，预算巨大，并且如果可以实现这一目标，则认为是不可或缺的。这些真的很少见;一个例子是“Skunkworks”团队，开发了独特（最终不可持续）的黑鸟间谍飞机。

“发明”项目的项目可以成功“公毒”和发展，这代表了完全新的行为，或者巨大的助推器，即人们渴望的行为，无论多么差价如何，（例如，手机服务，社交网络，45rpm记录）。

可能不会做的是企业级项目，必须组织许多人的努力的项目。我很遗憾地说，我尽管我帮助领导了这样的成功 - 调查管理系统超过1400多名政府用户。我们通过使用敏捷宣言中的所有四个原则成功，这仅奏效，因为我们是A-1，敏捷项目1团队。

我的建议 - 获得最聪明的团队，你可以真正关心他们的工作，并把它们放在巨大的压力下 - 它们会切割到骨头上，并不会跳过任何关键步骤，如果你愿意，你可以称之为敏捷，但是我称之为令人毛骨悚然！

更多应被揭示。保持反馈意见 [电子邮件 protected].

玩得开心！