边界是一个很重要的问题。
-------------------------------------
国与国之间,有边界问题,会发生战争;
省与省之间,有边界问题,会出现三不管;
人与人之间,有边界问题,那是捞过界了,会出现诸如扯皮、小三、打架等等问题;
同理在IT公司内部管理是需要定边界的,职务、职责、部门、流程等等,项目管理也是要定边界的,需求也是要定边界的,设计也是要定边界的,我们看到的大部分东西都是要定边界的。
那设计是怎么定边界呢?
教科书给我们的设计砍了一刀,分为概要设计和详细设计。以前实在不知道该如何解释概要这个词,到现在还是不明白,从语义上难道概要是简单的写,详细是大写特写。这个边界尺度持续了很久都没有把握住。
直至在使用了在文章《混在IT-(6)八股文之需求分析》中的需求规格说明书三分定天下方法之后,对设计的边界有了理解。先举个生活的例子,让大家品味一番。
现在青菜很贵,大叔打算改行去要卖菜。
[u]需求[/u]:卖菜
[u]卖菜流程[/u]:
1、大叔推出特价菜,今天是花菜,只欢迎MM
2、MM选中花菜
3、MM说要多少斤
4、大叔把菜放到MM菜篮子里面
5、MM付钱
6、大叔笑脸
[u]解决方案[/u]:
有大傻很看好大叔卖菜钱途,愿提供环境给大叔,提供了以下解决方案
1、在街边占地盘卖,愿提供扁担一个,菜篮一对,不过有风险,城管太多
2、在菜市场租个摊位给大叔,但只能上午营业
3、建一个专卖店给大叔,可以24小时营业
[u]方案审批[/u]:
当然要专卖店,大叔喜欢阵地战,不喜欢游击战,不用到处躲猫猫
[u]概要设计[/u]:
讨论怎么建设一个专卖店,怎么装修,怎么布局,怎么更专业
[u]详细设计[/u]:
为了把买菜这个流程在这个专卖店做的更好,每个卖菜步骤必须要做包装,如大叔必须装西装、打蝴蝶结等等。但卖菜步骤的是不能变的,这个是原则,这是大叔花了很多心血想出来的。
[u]长远规划[/u]:
1、大叔也不排除会在专卖店条件允许下,在MM付钱的时候找个服务生拉拉小提琴,送送花的步骤。
2、在这个专卖店上,大叔还可以扩展业务,如卖苹果、卖手机……
不知道大家看明白了吗?
[u]总结一下边界[/u]:
概要设计是专卖店建设,详细设计是在这个专卖店上如何实现卖菜流程。
在实践中我们把设计报告也分成3块,其形式和边界如下:
1、详细设计报告,只涉及到需求规格说明书的分册内容,此部分的内容会随着分册的变动而发生变化。业务实现过程要符合概要设计中的约定。
2、数据库模型,分册中涉及到数据库部分在数据库建模工具中体现,需要的话可以导出成单独文档存在。
3、概要设计报告,系统如何建设,与具体的业务无关,是为分册所涉及的业务做支撑的,如网路架构图,部署架构图、数据库设计思路、采用的框架,框架使用的约定,非功能性要求实现等等,这份文档在项目版本迭代过程中可以说基本上是不会再改。做的好还可以在其他项目上使用。
Ps:下几章是找个例子分享概要、详细设计。概要设计大叔太久没做了,材料不好找。
-------------------------------------
国与国之间,有边界问题,会发生战争;
省与省之间,有边界问题,会出现三不管;
人与人之间,有边界问题,那是捞过界了,会出现诸如扯皮、小三、打架等等问题;
同理在IT公司内部管理是需要定边界的,职务、职责、部门、流程等等,项目管理也是要定边界的,需求也是要定边界的,设计也是要定边界的,我们看到的大部分东西都是要定边界的。
那设计是怎么定边界呢?
教科书给我们的设计砍了一刀,分为概要设计和详细设计。以前实在不知道该如何解释概要这个词,到现在还是不明白,从语义上难道概要是简单的写,详细是大写特写。这个边界尺度持续了很久都没有把握住。
直至在使用了在文章《混在IT-(6)八股文之需求分析》中的需求规格说明书三分定天下方法之后,对设计的边界有了理解。先举个生活的例子,让大家品味一番。
现在青菜很贵,大叔打算改行去要卖菜。
[u]需求[/u]:卖菜
[u]卖菜流程[/u]:
1、大叔推出特价菜,今天是花菜,只欢迎MM
2、MM选中花菜
3、MM说要多少斤
4、大叔把菜放到MM菜篮子里面
5、MM付钱
6、大叔笑脸
[u]解决方案[/u]:
有大傻很看好大叔卖菜钱途,愿提供环境给大叔,提供了以下解决方案
1、在街边占地盘卖,愿提供扁担一个,菜篮一对,不过有风险,城管太多
2、在菜市场租个摊位给大叔,但只能上午营业
3、建一个专卖店给大叔,可以24小时营业
[u]方案审批[/u]:
当然要专卖店,大叔喜欢阵地战,不喜欢游击战,不用到处躲猫猫
[u]概要设计[/u]:
讨论怎么建设一个专卖店,怎么装修,怎么布局,怎么更专业
[u]详细设计[/u]:
为了把买菜这个流程在这个专卖店做的更好,每个卖菜步骤必须要做包装,如大叔必须装西装、打蝴蝶结等等。但卖菜步骤的是不能变的,这个是原则,这是大叔花了很多心血想出来的。
[u]长远规划[/u]:
1、大叔也不排除会在专卖店条件允许下,在MM付钱的时候找个服务生拉拉小提琴,送送花的步骤。
2、在这个专卖店上,大叔还可以扩展业务,如卖苹果、卖手机……
不知道大家看明白了吗?
[u]总结一下边界[/u]:
概要设计是专卖店建设,详细设计是在这个专卖店上如何实现卖菜流程。
在实践中我们把设计报告也分成3块,其形式和边界如下:
1、详细设计报告,只涉及到需求规格说明书的分册内容,此部分的内容会随着分册的变动而发生变化。业务实现过程要符合概要设计中的约定。
2、数据库模型,分册中涉及到数据库部分在数据库建模工具中体现,需要的话可以导出成单独文档存在。
3、概要设计报告,系统如何建设,与具体的业务无关,是为分册所涉及的业务做支撑的,如网路架构图,部署架构图、数据库设计思路、采用的框架,框架使用的约定,非功能性要求实现等等,这份文档在项目版本迭代过程中可以说基本上是不会再改。做的好还可以在其他项目上使用。
Ps:下几章是找个例子分享概要、详细设计。概要设计大叔太久没做了,材料不好找。