敏捷开发是否需要并如何建模

[LiHongxi]

参加姜志辉老师的ucd培训时，曾经聊到，Kent Beck等人在开发时是否也需建模，后来的共识是：应该直接在大脑中先建模了，实现模式似乎建立在了OO、UML建模等诸多知识的金子塔的顶部,

在阅读《Implementation Patterns》时 我读到：

the name express intentions but implementation..

Another principle behind the implementation patterns is to express as much of my intention as possible declaratively.

I mush build a model in my head of  the state of the program and the flow of control and data

希望能向大家就敏捷开发中的场景、目的等建模方式，做探讨，谢谢大家。

[Long Bai]

实现模式那本书描述的应该不是在顶部吧，接近底部还差不多。

不管怎样，总有一个层次需要建模的，除非涉及到的范围很小。是先在大脑中进行建模没错，所有行为都是思考后的结果，但大脑能记得多少，大脑中建模的流程又是什么样子的呢，接下来怎么把脑中的模型和其他人沟通呢？

--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina

[Xu Yi]

关键在于利用某个具体形式的模型进行沟通，不要认为此形式就等同于模型自身就行了

--
- - - - - - - - - -
Xu Yi, Kaverjody
Senior Agile Consultant @ HP Enterprise Services
Blog : http://blog.sina.com.cn/kaverjody
Sina Weibo : http://weibo.com/kaverjody
Skype : kaverjody
- - - - - - - - - -

[张克强]

除了在大脑里的模型，为了交流，用于交流模型是需要一定载体的。

一般而言，架构设计是值得文档化的。问题在于架构设计说些什么？

之前我写过个文章，贴在这里，供讨论拍砖。

架构设计的文档是架构设计的成果物。其中所要展现的元素就是架构设计的成果。从这个角度，也许可以简化下架构设计。
按照Just enough的原则，对于架构设计的元素，最有必要的给5颗星，其次4，3，2，没有必要的、可有可无的给1颗星。 

支持的操作系统，比如 win7, Redhat9   ☆☆☆☆☆ 
支持的数据库 比如Oracle, DB2, Mysql ☆☆☆☆☆ 
支持的浏览器（如果是有Brower访问的）☆☆☆☆☆ 
依赖的运行时环境 --比如Java, Silverlight ☆☆☆☆☆ 
依赖的中间件--- 比如Java容器，tomcat, websphere, Tuxedo ☆☆☆☆☆ 
依赖的核心构件或者Frame, 比如struts, hibernate, 自定义的构件 ☆☆☆☆☆ 
层次划分，比如 典型三层架构、多层架构  ☆☆☆☆
识别进程，画部署图 ☆☆☆☆☆ 
划分组件，画组件图 ☆☆☆☆☆ 
开发语言 比如c#, java, c++  ☆☆☆☆☆ 
开发所用的工具  比如IDE，报表设计器 ☆☆☆☆ 
重要组件间的接口 ☆☆☆☆ 
核心类的设计 ☆☆☆ 
数据库设计 ☆☆☆   存储数据和检索有其特点。在表达方面有其自身的特点。如数据集的提取，运算等, 要注意性能，完整性等。数据库设计也可做渐进设计
核心流程的说明 ☆☆ 
部分核心类的类图 ☆ 
特别的性能要求带来的考虑 ☆☆☆☆ 
特别的可恢复性要求带来的考虑 ☆☆☆ 
特别的信息安全要求带来的考虑 ☆☆☆

说明：
至于操作系统，数据库， 运行时环境等等可能不是由架构师决定，但如果没有其他人决定，或者领导要求一个初步方案时，架构师必须拿出意见。
就算别人已经决定了操作系统、数据库、 运行时环境等等，那么这些是下一步工作的前提和约束，也值得在架构设计文档中记述。

性能和安全的要求不是架构师定的，但如何保证实现性能和安全的要求，这是架构师必须考虑的问题。如果没有特别的要求，可以不考虑。
电信公司的应用和20人小公司的应用就算功能完全一样，初始设计就已经不一样了。
如果有特别的要求，比如交易所要每秒交易8万笔，对于干系人来说，这是最关心的，最核心的。

从数据库管理人员的角度来说， 数据库的设计说明是必不可少的，企业开发要特别关注于数据库  --- 对数据库管理人员来说，没错。但对于架构师在初期恐怕还不是一定必需的，可以给3颗星。

原文发在  http://hi.baidu.com/hespr/blog/item/f11cd9d9e63d9d3e33fa1c42.html 

张克强

blog: 从高效过程到卓越结果

weibo: http://weibo.com/zhangkeqiang 

[LiHongxi]

   

   1. 要站在用户的角度去思考，做什么，如何做，例如某一个变量在一个计算中担当何种角色

   2. 建立模型是为了当面对未知变化的时候，通过推理，能清晰知道这个问题（变化）的解。因为变化是相对的

       同样消除重复逻辑也是准确建立模型的需要 

   3. 命名也是为了表达逻辑的线索

   4. ucd中一个重要的概念是场景： 谁, 为什么？多少？时间,位置,怎么？

      这与《实现模式》中所讲的站在用户的角度去思考是相通的   

   5. 通过结对编程，代码共享，面对面沟通及tdd, 说明开发意义上的沟通的载体是什么呢？

[陈之过]

好像说的是模型啊,怎么整出操作系统,浏览器,数据库等等东西了呢?你是在做抽象思考吗?

[张克强]

模型这个词的范围可是很宽的。 

在软件建模时，明确下将来软件运行的操作系统、浏览器是有好处的。

对后续编程实现而言，这些信息是必须的。

建模时明确这些选择，会大大的方便建模，建模可以更有针对性的指导后续工作。

我不是在做抽象思考，我恰恰是在做具体实现的思考。

当然，大多数情况下， 操作系统、浏览器、数据库等等也许已经选定了，那就不必费脑筋了。

[陈之过]

难道你不懂接口分离吗?

[泥泥]

假设软件开发需要三种角色：产品经理、视觉设计、技术实现。（某些企业级系统或者底层系统是不需要视觉设计的，有些纯粹技术项目甚至连产品经理都没有的，只有一个需求管理角色。这些项目也从来不会被UCD培训引用，此处可以暂时忽略）

每种角色需要的、能做到的本来就不是同样的东西。

UML和UCD都不是一个时代的东东，串起来讲顿生穿越感。

在 2012年3月23日 下午10:06，LiHongxi <lihx...@gmail.com>写道：

--

[张克强]

这是个讨论区，这次的话题是“敏捷开发是否需要并如何建模”

综合下我的看法：

1， 敏捷开发需要建模

2，为交流，建模需要一定的载体，但不是所有的建模都要载体，不是所有有载体的建模需要长期保留。

3，敏捷建模中较好的、并值得形成文档的载体是架构设计
4，架构设计的范围和做法没有公论，上述推荐了常见的架构设计需要考虑的元素

5，推荐在架构里明确操作系统、数据库、浏览器等，这对后续开发有好处。接口分离是个选项，不分离也是个选项。在明确操作系统、数据库、浏览器等的情况下，做出选择会容易些，。在不明确操作系统等的情况下，只能选择接口分离，这需要更多的工作量，而最终与操作系统等打交道的模块或组件仍然是需要考虑具体操作系统等的。

至于我懂不懂接口分离，不是这个话题的内容。

如果你不赞成在架构时，来确定操作系统、数据库、浏览器，说说你的理由。

在实际中，有没有哪一次或几次，是在不知道软件所依赖的操作系统、数据库、浏览器等情况下，进行了建模或架构？

或者说说你所做的或者所认为的敏捷建模是什么样的

[陈之过]

> 在实际中，有没有哪一次或几次，是在不知道软件所依赖的操作系统、数据库、浏览器等情况下，进行了建模或架构？

每次都是,因为和这些东西没有关系

[Xiao Peng]

我现在正在带着一个团队尝试使用Specification by Example的方式进行建模。

SbE在需求分析和测试方面的意义已经没有太多争议，我现在在尝试通过"Find the missing concept"来指导对象建模。更新的信息请follow新浪：

@XiaoPeng-TW

=========================
肖鹏，ThoughtWorks资深咨询师
AD：TW招聘中。
Blog：http://xiaopeng.me

2012/3/28 陈之过 <chenzh...@gmail.com>

[漠河]

我们的架构人员对于架构设计停留在经验主义阶段，没有文档，不利于共享和过程跟踪。尤其是第三方组件、技术的选型比较随意。

[Long Bai]

个人观点，你们俩说的范围不一样:)

接口分离，是从某个模块从里往外看，是模块之间的操作，这个只是系统内部设计的一部分。从整个软件系统角度看，考虑的不仅仅是接口的部分。 操作系统，数据库等对成本和环境有很强的影响，在开始就要考虑清楚是对的。

在 2012年3月27日 下午8:37，张克强 <zhangk...@gmail.com>写道：

[LiHongxi]

Explaining the purpose of an object to another person leads me to look for rich and evocative images to describe it. these images can lead in  turn to new names   --Kent Beck

我现在认为 images 就是 ucd中“场景” 所描述的, 为什么是许多个images会产生一个新的名字呢

[LiHongxi]

Class names that are too short tax the reader's short-term memory. Clusters of classes whose names don't relate to each other will be difficult to comprehend and recall. Use class names to tell the story of your code.

短期记忆和长期记忆，在《番茄工作法图解》《暗时间》等书中，都提到了。看来命名也是有科学的依据的。

[Yong Huang]

隐喻足够。模型可大可小吧，言之无物。

[铁龙国]

这是必须的步骤。

在 2012年3月23日 下午10:06，LiHongxi <lihx...@gmail.com>写道：

--