UML软件工程组织

敏捷建模是(不是)什么?
英文原文版权由Scott W. Ambler拥有
Original text is copyrighted by Scott W. Ambler
译者:林星 | 原文出处:www.AgileModeling.com

我坚信当在描述事物的范围时,你需要说明它是什么,它不是什么。不管你谈论的是系统还是案例中的AM都一样。以下就是我对AM的范围的观点:

  1. AM是一种态度,而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时,能够提高开发的质量和速度,同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”,如果你寻觅的是一些细节的指导,如建立UML顺序图或是画出用户界面流图,你可以看看在建模Artifacts中列出的许多建模书籍,我特别推荐我的书The Object Primer 2/e(尽管这有失公允)。

     

  2. AM是对已有方法的补充,而不是一个完整的方法论。 AM的主要焦点是在建模上,其次是文档。也就是说,AM技术在你的团队采用敏捷方法(例如eXtreme Programming,Dynamic Systems Development Method (DSDM),Crystal Clear)的基础上能够提高建模的效果 。AM同样也可以用于那些传统过程(例如Unified Process),尽管这种过程较低的敏捷性会使得AM不会那么成功。

     

  3. AM是一种有效的共同工作的方法,能够满足Project Stakeholder的需要。敏捷开发者们和Project Stakeholder进行团队协作,他们轮流在系统开发中扮演着直接、主动的角色。在“敏捷”的字典中没有“我”这个单词。

     

  4. AM是有效的,而且也已开始有效。当你学习到更多的AM知识时,有件事对你来说可能不好接受,AM近乎无情的注重有效性。AM告诉你:要使你的Project Stakeholder的投资最大化;当有清晰的目的以及需要解了受众的需要时要建立模型或文档;运用合适的工件来记录手头的情形;不论何时都尽可能创建简单的模型。

     

  5. AM是来自于实践中,而不是象牙塔般的理论。AM的目标就是以一种有效的态度描述系统建模的技术,它有效率,足够胜任你手头的工作。我和我在Ronin International (http://www.ronin-intl.com) 的同事将大量的AM技术应用于实践已经很多年了,我们琢磨的这些技术应用于非常广泛的客户,他们遍布各个不同的工业领域。而且,从2001年2月开始,就有数百位的建模专家通过“敏捷建模邮件列表”(http://www.agilemodeling.com/feedback.htm) 对这些技术进行过充分的检查和讨论。

     

  6. AM不是灵丹妙药。敏捷建模是改进众多专家软件开发成果的有效技术,充其量也就是这样了。它并不是什么了不得的灵丹妙药,能够解决你开发中的所有问题。如果你努力的工作;如果你专注其上;如果打心眼儿里接受它的价值观、它的原则、它的实践;你就可以改进你做为一个开发人员的效果。

     

  7. AM是面向一般的开发人员的,但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂,其中的很多内容,可能你都已经采用或期待多年了。应用AM技术并不是要你去练水上飘,但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术,这是个长期的、持续性的活动。学习建模在一开始可能很难,但你可以试着一次学习一样技术来完成你的学习。

     

  8. AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单,尽可能的小,目的只集中在和目前开发的系统有直接关系的事情上,充分了解受众的需要。

     

  9. AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果,提升价值的工具。而且,他们还尽力使用那些能够胜任工作的最简单的工具。

     

  10. AM并不适合每一个人。这一点在下面的列出的文章中会进一步讨论。

     

参阅模型何时是敏捷的?你是在敏捷建模吗? 以及敏捷建模何时是有(没有)意义的?

 

版权所有:UML软件工程组织