帮您全面认识敏捷建模思想(6)

作者: Scott W. Ambler/林星 高继荣 编译 出处:计算机世界报　2008-03-21 14:56　   砖    好    评论  条 　进入论坛

阅读提示：本文系统地讲述了敏捷建模思想的精髓，希望大家仔细研读！

6、你是在敏捷建模吗?

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

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

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

你的客户/用户都能够积极的参与需求建模，分析建模工作。
接受需求的变化，并遵照变化了的需求行事——不存在“需求冻结”。
根据Project Stakeholder定下的优先级顺序，首先解决优先级最高的需求；在随后的工作进展中，集中解决风险最大的问题。
你采用迭代、递增的方法建模。
你的精力主要集中于软件的开发，而不是文档或模型本身。
注重团队协作精神，欢迎任何人提出意见或建议。
尽可能地做到简单——使用你可以获得的最简单的工具；使用能够胜任的最简单的模型。
随着开发的进展，你的大部分（不是所有的）模型都会被丢弃（而不作为正式的文档保存下来）。
客户/业务组织拥有业务决定权，开发人员拥有技术决定权。
大家都一致认为模型的内容比内容的格式/表现手法要重要的多。
在你建模的时候，需要不断考虑的一个关键问题是你该如何测试该模型所描述的内容。

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

你的目的是产生文档，例如需求文档，并且，这些文档需要一个或几个Project Stakeholder签字认可。
你使用CASE工具进行软件的架构搭建和设计，但却没有进一步在此基础上自动地产生部分或全部的代码。
你的客户/用户和你一起工作的时间很有限。比如，他们加入项目需求的初始开发阶段，但时间非常有限，只是回答一些问题；然后就会撤出；然后在迟些时候再参加一个或几个对你工作的接受审查。
你一次只专注于一种模型。最常见的例子就是“用例建模会议”，“类建模会议”或是“数据建模会议”。这种问题产生的最根本的原因就是“单一的artifact开发者”。例如专门进行数据建模的人，专门进行用户界面建模的人。而在AM中，每个人都是多面手，都能够胜任这项工作。
你工作的方式是做好一个模型以后再做下一个模型－也就是说，你是采取一种“serial”的方法工作。
你所在小组仅负责模型的设计或文档的编写，当完成这些模型或文档后再将其交付给另外的小组进行下一步的开发工作。也就是说，你是以一种“serial”的方式来“传出（handing off）”你的工作。

7、敏捷建模何时是有（没有）意义的?

何时合适AM运作?

但这不是我的情形...

何时不合适AM运作?

何时敏捷建模是适合你的?

敏捷建模不是万能的，它并不适合于每一个人、每一种情况。即使是你的条件非常适合于AM，也不能保证它就能良好的运行——你在组织内实施AM时还是有可能犯下错误。我的经验是，在以下条件满足时，AM极有可能发挥其效力：

软件开发采用了敏捷方法。AM不是一门完整的方法学，它只是某个软件开发流程中的一部分应用。要成功应用AM，你所采用的开发流程的观念必须要与AM的观念相匹配（译注：XP与AM匹配，而CMM与AM就不匹配）。否则，你只是在片面的运用AM中的几项技术，而不是真正的配置了AM。

采用迭代式、递增式的开发方式。做为AM的两项实践，有效的沟通（communication）和反馈（feedback）要求软件开发采用迭代和渐增的方法。

需求不确定或不稳定。Martin Fowler在他的新方法学中指出，如果你的项目就像是自然探险（大多数项目都如此），那最佳的选择就是采用敏捷方法来开发软件。当需求不明或易变时，你就应该采用一种能够适应这种情况的开发方式。AM拥抱变化，它采用递增的开发方式，寻求快速的反馈，并且一贯坚持Project Stakeholder的积极参与，这就是AM对付需求变化的法子。使用AM，你就能够迅速而有效地发觉客户的需求。

开发软件是你的主要目标。这是AM的核心原则之一，但对很多项目来说，这并不是他们的目标。例如，有时候一个项目团队的主要目标是从客户那里圈钱（在外部采购中时有发生），或是简单的制定系统规范，因为系统要交付给另一个团队去实现。更糟的是，一些项目仅仅是出于政治上的考虑，它的目的就是让别人感到他们正在做这件事，至于要做出来什么东西却根本没有考虑。软件开发的目标应该是生产出满足客户需求的有效的软件系统－如果你的目标不是这样，AM就不适合你。

你需要有stakeholder的积极支持和参与。Fowler同样认为，敏捷软件开发工作要想成功，需要有project stakeholder的积极支持和参与。Project Stakeholder是那些受软件项目的开发和/或部署潜在的影响的人。包括直接用户，非直接用户，经理，高级经理，操作人员，支持人员，测试者，和这个系统有关（整合或交互）的其它系统的开发人员，以及维护人员。AM要想成功，你需要了解你的Project Stakeholder是谁，你还要能够和Stakeholder保持日常的接触，Stakeholder能够及时的为你提供信息、做出决策。此外，还应该要有管理层的大力支持。

开发团队能够自我决策。敏捷软件开发，特别是敏捷建模，对大多数的组织来讲都是新生事物。接受敏捷方法对大多数的组织来讲都是一件很难的事，因为它对大多数人来说都是一种新的工作方式。想要成功，我的经验是，不管成功还是失败，要根据项目团队的优点，给他们机会。鼓励他们尝试新技术，给他们资源（包括时间），让他们开始学习。应该尽量杜绝玩弄权术的现象，这就意味着组织中的管理层和一些部门要改掉原来的做法。

要有真正的AM斗士。不论何时，接受新的事物总会面临着挑战。人们不愿意改变，他们喜欢、他们也习惯了以前那种繁琐的慢节奏的工作方式。他们和你看事情的角度不同，你希望引入敏捷方法来解决问题，而他们不认为那是问题。也许他们会改进自己喜爱的开发方法，但这些方法和AM格格不入。也许，AM威胁到他们在组织内的权力分配。即使不考虑这些情况，也还是会有人抗拒变化。要想成功的改变，必须要有真正的AM斗士。他们支持AM，为AM奋斗，他们愿意去收集Project Stakeholder的支持，他们愿意进行AM思想的宣传和培育，让AM能够在组织内生根发芽。改变需要时间，这些斗士就是在争取时间。

你需要负责、主动的开发人员。Fowler指出敏捷软件开发强调开发人员的纪律性，要求开发人员能够协同工作，开发高质量的软件。这意味着你需要一个健康的团队环境，人们能够相互信任，相互帮助，共同迈向成功。和那些敏捷开发方法的诋毁者告诉你的完全相反，你需要的人并不是一个个都要求能上天入地。根据我的经验，你的要求很简单：愿意完成工作，有合作精神，能够有效工作。

你需要有足够的资源。你现在知道了敏捷建模需要人们的紧密合作。就是说你需要“协同开发的空间”，例如能够使人专注于工作的建模室，一堵能够演示模型的公用墙，最好还能给每对开发人员配置一台共享工作站。除此之外，你还需要有足够的建模工具，例如白板、索引卡片、标记、和其它必须的CASE工具。我就曾经看过由于基本资源（像样的椅子，桌子，食物，饮料，和高端工作站）的缺乏，使软件开发工作的进展受到阻碍。如果你的项目团队因为这些锱铢之事导致失败，那我倒是想问问你这项目对你的组织是不是真的那么重要。如果不是，那就cancel它，把你的精力投入到其它更有价值的项目中去吧！

但这不是我的情况....

共10页: 上一页 [1] [2] [3] [4] [5] 6 [7] [8] [9] [10] 下一页

【内容导航】