【IT168 技术文章】

    敏捷开发方法所面临的最大的挑战就是开发人员声称自己遵循了这种方法，而实际上他们并没有这么做。当他们运作出了问题的时候，他们就会去责备方法不好，但其实他们根本就没有真正遵循过这些方法。在极限编程(eXtreme Programming XP)就有这样的例子，一些编程狂宣称他们完全遵循XP所有的原则，但实际上仅仅是他们听到的关于XP的一小部分内容，如你不需要这么多文档。他们的产品要么质量低劣，要么根本就不能满足实际用户需求，但他们将这一切的失败都归罪于XP，真是不公平！

    我很想避免此类问题在AM上出现，但这只是一个理想。现实中，我力所能及的只是能指出你在什么情况下是在以敏捷的方式建模，什么情况下不是。

    什么情况下，你是在敏捷建模?

    你的客户/用户都能够积极的参与需求建模，分析建模工作。

    接受需求的变化，并遵照变化了的需求行事——不存在“需求冻结”。

    根据Project Stakeholder定下的优先级顺序，首先解决优先级最高的需求；在随后的工作进展中，集中解决风险最大的问题。

    你采用迭代、递增的方法建模。

    你的精力主要集中于软件的开发，而不是文档或模型本身。

    注重团队协作精神，欢迎任何人提出意见或建议。

    尽可能地做到简单——使用你可以获得的最简单的工具；使用能够胜任的最简单的模型。

    随着开发的进展，你的大部分（不是所有的）模型都会被丢弃（而不作为正式的文档保存下来）。

    客户/业务组织拥有业务决定权，开发人员拥有技术决定权。

    大家都一致认为模型的内容比内容的格式/表现手法要重要的多。

    在你建模的时候，需要不断考虑的一个关键问题是你该如何测试该模型所描述的内容。

    什么情况下，你不是在敏捷建模?

    你的目的是产生文档，例如需求文档，并且，这些文档需要一个或几个Project Stakeholder签字认可。

    你使用CASE工具进行软件的架构搭建和设计，但却没有进一步在此基础上自动地产生部分或全部的代码。

    你的客户/用户和你一起工作的时间很有限。比如，他们加入项目需求的初始开发阶段，但时间非常有限，只是回答一些问题；然后就会撤出；然后在迟些时候再参加一个或几个对你工作的接受审查。

    你一次只专注于一种模型。最常见的例子就是“用例建模会议”，“类建模会议”或是“数据建模会议”。这种问题产生的最根本的原因就是“单一的artifact开发者”。例如专门进行数据建模的人，专门进行用户界面建模的人。而在AM中，每个人都是多面手，都能够胜任这项工作。

    你工作的方式是做好一个模型以后再做下一个模型－也就是说，你是采取一种“serial”的方法工作。

    你所在小组仅负责模型的设计或文档的编写，当完成这些模型或文档后再将其交付给另外的小组进行下一步的开发工作。也就是说，你是以一种“serial”的方式来“传出（handing off）”你的工作。