据我观察,我遇到的所有命名方法都可以映射到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].
玩得开心!