据我观察，我遇到的所有命名方法都可以映射到BABOK概念上，而BABOK是它们的超集。   

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

敏捷软件开发宣言

我们正在探索通过开发和帮助他人来开发软件的更好方法。通过这项工作，我们开始重视：

1.个人和流程和工具之间的互动
2.工作软件胜过完整的文档。
3.客户通过合同谈判进行合作
4.响应计划变更

也就是说，尽管在
在右边，我们更看重左边的项目。

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

以下是根据常识，个人经验和BABOK概念进行的一种分析：

• 在工具变得重要之前，必须具备BA基础知识（以及执行需求沟通的基本技能）。工具只能支持有效的行为，而不能创建行为。从某种意义上说，所有成功的项目都是“敏捷的”-我观察到，所有成功的项目都充满了聪明才智的人，他们可以自由，快速地进行互动。这个单一因素似乎可以弥补其他所有问题-欢迎提供反例，我没有任何反例。
• 基于文档的软件已经是软件开发中最常见的方法，因此很难理解为什么它对“敏捷”至关重要。由于在软件开发中已经达到了65％的“失败”率，因此，如果敏捷才是有效的，那么第1、3和4项才是真正重要的。
• 将“与利益相关者的需求迭代”替换为“客户协作”，并将“瀑布需求”替换为“合同”。合同最糟糕的情况是试图在理解之前“锁定要求”，从而导致承包商的变更单利润过多（允许更改时），或者使利益相关者无法接受（如果不允许）。对于“月球计划”之类的“一键式”工作，最好保存瀑布条件。
• 过度计划和不愿根据“学习”需求来调整计划，显然是某些项目失败的原因-主要是智能的失败（请参阅第1项）。该概念所缺少的是企业分析（尤其是风险分析，利益相关者分析和成本收益分析）的思想以及必须遵循的思想。另一种表达方式是-如果项目简单且风险低，则Agile可能合适（请参阅“企业分析”部分中的BOK表3.0和4.0，并查看是否可以发现哪些项目可能使用Agile。

因此，从分析到意见（如果您有自己的意见，请将其发送给我们，我们将汇总答复并进行报告）：

我的看法是：敏捷过程适合某些类型的项目，但几乎不适合大多数项目。这是我的清单-您的清单是什么？

“小土豆”-低风险，像样的，高回报的系统，只需要满足少数具有相同兴趣的用户，可见性低或代表已成功使用的系统的成功，成功的增量（是，维护和增强）。

 “可行性”或“概念验证”试验可以为大型项目的更多投资扫清道路吗？

 “研究”项目几乎是未知的，预算是巨大的，并且如果可以实现这些投资，则其回报是必不可少的。这些真的很少见；一个例子就是“臭鼬工厂”团队，他们开发了独特的（最终是不可持续的）黑鸟间谍飞机。

“发明”项目是指那些能够“虚拟”成功并不断发展的系统，这些系统代表着人们渴望的全新行为，或者是人们渴望的行为的巨大推动力，而不论交付的质量如何（例如，手机服务，社交网络，45rpm记录）。

敏捷可能无法做的是企业级项目，这些项目必须组织许多人的努力。尽管我曾帮助领导了如此成功的事实，但我仍持有这种观点，尽管调查管理系统适用于1400多个政府用户。我们在敏捷宣言中使用了所有四个原则，并且成功了，这仅是因为我们是A-1敏捷项目1团队。

我的建议-尽可能聘请最聪明的团队来处理他们的工作，并给他们施加巨大的压力-他们会扎根，不会跳过任何关键步骤，并且可以根据需要将其称为敏捷，但是我叫它Bagile！

更多的将被揭示。保持反馈 [email protected].

玩得开心！