人月神话笔记-贯彻执行

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zjiang1994/article/details/79142132

人月神话笔记-贯彻执行

他只是坐在那里,嘴里说:“做这个!做那个!”当然,什么都不会发生,光说不做是没有用的。

文档化的规格说明-手册

手册或书面规格说明,是一个非常必要的工具,仅有文档是不够的。

手册外部规格说明:
- 他描述和规定了用户所见的每一个细节
- 是结构师的主要工作产物

规格说明书在实现过程中会不断的修改,
但是修改的阶段化是很重要的,进度表上应该标注日期。

规格说明书应该避免描述用户看不见的事物,这些需要实现人员来定义。
体系设计人员要为自己描述的任何特性准备一种实现方法,但是不应该试图支配具体实现过程。

规格说明书必须清晰、完整、准确。
每条说明必须重复所有的基本要素。
准确比生动更重要。

结构师在清楚自己需要定义什么的同时也要明确自己不应该定义什么

形式化定义

优点:精确、倾向完整

缺点:不易理解

不要携带两个闹钟出海,带一个或三个。

会议和大会

周会:
- 由设计人员和实现人员的代表、市场代表进行
- 任何人都可以提出问题和意见
- 目的是发现解决问题的方法,而不是解决问题
- 方法会归纳成文档交给某个设计人员来进一步解决
- 会议会对上一期的详细的变更进行决策
- 对于无法决策的问题,由首席设计师来决定

周会的优点:
- 结构师、用户和实现人员定期交流,加深对项目的理解
- 与会人员对项目的理解更深刻
- 出现问题时内部和外部会同时寻求解决方法
- 有正式的书面文件
- 明确了首席设计师的权利,避免拖延和妥协

大会用来讨论解决周会积累下来的问题。

多重实现

在大多数项目中,机器和手册之间往往会在某一天出现不一致,人们通常会忽略手册。
因为与机器相比,手册更容易改动,并且成本更低。

电话日志

现在可以理解为询问日志

就是当实现人员对设计有不理解时,鼓励他们主动询问设计人员,而不是自己猜测。
设计人员应该记录每一次的询问个回答,合并整理,在开会中共有。

产品测试

产品测试小组:
- 麻烦的代言人
- 查明每一个可能有缺陷和相互矛盾的地方
- 顾客的代理人,专门寻找缺陷

猜你喜欢

转载自blog.csdn.net/zjiang1994/article/details/79142132