敏捷开发最佳实践: Model Storming

导读：
　　新一篇: vb.net 与 C# 比较 | 旧一篇: MFC 超级链接的控件类
　　英文原文：http://www.agilemodeling.com/essays/modelStorming.htm
　　
　　Model Storming是一种实时的建模方式：你找到了一个需要解决的问题，你马上抓起一小撮团队里可以帮助你的同事，这个小组一起研讨解决这个问题，接下来每个人像刚才一样继续工作。这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand-up design session)或者客户的问答会议(customer Q&A session)，并且在传统的项目中也同样普遍。我们是时候开始探讨一下model storm,我们可以找到某种方式让这个过程变得更好。
　　我的经验是大多数的建模会议应该只有少量的人员参与，一般来说2到3位，这些人员讨论问题并且将草图画到纸或者白板上。这些model storming session基本上是一种即兴的事，一个项目团队成员让另一个人去和他一起建模，一般来说大概持续5到10分钟（model storm几乎很少超过30分钟）。人们在围着共享的建模工具（例如白板），一起去探索直到他们满意的理解这个问题，接下来他们继续工作（经常是coding）.
　　Analysis Model Storming
　　你将用model storm去分析需求。For example，一个项目相关人员可能告诉你你要构建的这个系统必须能够编辑学生的信息（译者：够俗的例子）。和组员们一起建立了草图，在屏幕上可以看到，see Figure 1。画了很多示例直到你们都理解了什么事你们需要构建的。这种草图是一种inclusive models 因为你们用了简单的工具和建模技术，这将允许项目相关人员的参与敏捷建模实践。
　　Figure 1. Screen sketches.
<IMG height=480 alt="" src="http://p.blog.csdn.net/images/p_blog_csdn_net/smalllixin/uiSketchStudentEdit.jpg" width=305>　　
　　
　　
　　Design Model Storming
　　敏捷开发者，包括XPer。当他们一旦选择了一个需求去完成，一般并不直接去编码（与敏捷开发的诋毁者告诉你的相反，译:外国人也勾心斗角）。这是因为model storming对于架构和设计也很常用。java程序员在编写复杂的代码之前经常草草绘制一张UML sequence图（见Figure 2），XPer将建立CRC cards（Class Responsibility Collaborator ）在索引卡片上（见Figure 3）用来揭示结构设计的一些细节问题，VB程序员可能选择画流程图(Flow charts)来为一个复杂的业务规则建模（见Figure 4）。无论你建立的是哪种模型，你一直在model storming。
　　Figure 2. Service-levelsequence diagram.
　　<IMG height=375 src="http://p.blog.csdn.net/images/p_blog_csdn_net/smalllixin/sequenceDiagramServiceLevel.jpg" width=676>
　　
　　
　　Figure 3. Hand-drawn CRC Cards.Figure 3. Hand-drawn CRC Cards.
　　
　　<IMG height=838 src="http://p.blog.csdn.net/images/p_blog_csdn_net/smalllixin/crcCardExample.jpg" width=600>
　　
　　
　　Figure 4. Flowchart for enrolling in the University.
　　<IMG height=499 src="http://p.blog.csdn.net/images/p_blog_csdn_net/smalllixin/flowChart.jpg" width=658>
　　
　　有一点很重要你必须理解，model storm并不一定必须是在白板上，你只需要一个共享的、包容性的工具(inclusive tool) 可以令人们在一起容易工作。举个例子，CRC卡片（Figure 3）被写到索引卡片上而不是白板上。
　　Why Dose This Work? （为什么这样做）
　　为什么model storming这种实时的工作比试图事前设计好所有的一切要好（model everything up front）?
　　有很多原因：
　　1. 无论我们喜不喜欢，在整个项目过程中需求总是变化的。
　　2. 等到需要时再随即分析细节，比在项目一开始就做这些你有了更多的领域知识。举个例子，如果一个需求要加入在项目中并在三个月内实现，对于研究一些需求的细节如果你有了三个月的领域知识会多于在项目开始，因此你能提出更多睿智的问题。
　　3. 如果你已经经常性的交付你的软件，那么项目相关者就会有三个月的对系统使用的经验。话句话说，他们可以给你更好的建议。
　　4. 事先设计细节常常会出现一个巨大浪费的结果。是的，尽管在敏捷开发中，在第0次迭代你想去做一些初始化需求的猜想和一些初始化架构的猜想，但是他们并不意味着你需要跳入细节的沼泽中。
　　话虽如此，当在为复杂的需求建模，或者为遗留下来的系统(legacy)建模的时候，有时你还是需要事先实现一些设计。这种情况实际上很少发生（不管传统的建模者可能对这种事情的期望），但是偶尔也会有。(This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.)
　　Adopting Model Storming
　　在你的工作环境中如何去推荐model storming呢？首先，越多的白板空间越好。一些公司不愿意去放置白板，很显然他们更关心内部的装饰,比如一个吸引人的打印出来的东西在墙上，这比起另软件开发团队更有效率的工作来讲对他们更重要。我的建议是不但要有很多的白板可供人使用，并且你还需要确定当他们背对着工作区的时候是否能看见，这可以令他们可以使用白板更easy的工作。
　　你可能需要为使用白板制定一种协议，特别当要擦掉一些东西的时候。你的团队文化同样对你的成功有着举足轻重的作用，团队必须可以接受其他人要求帮助，并且可以让其他人一起建模。你需要认识到这是正常的并且是有效的工作方式。我不能记得我们不用model storm时的项目，同样我也不能记起关于这个技术的很多细节的读书或者文章。如果it产业开始谈论我们在实践中实际做了什么而不是我们想我们应该做事情不会更精彩么？
　　
　　翻译的水平很有限，有不当的地方请指正，转载请注明译者：李鑫
　　

本文转自
 http://blog.csdn.net/smalllixin/archive/2007/11/16/1888049.aspx

欢迎注册黑客派社区，开启你的博客之旅。让学习和分享成为一种习惯！