[分享]《软件开发项目管理》读书笔记（七）

第七章，软件项目设计规范管理的艺术

 

P217，功能规范书将软件的具体功能设计用专门的文件详细地归纳和总结在一起，是制造产品的蓝图，是开发计划的基石，是整个开发过程中绝大多数管理和计划决定的指南。

 

P216，微软的文化：没有设计规范书就不写一行程序编码。

 

P217-218，设计规范书的作用：

&_middot;为制定开发计划提供架构设计和实行具体开发的详细的指南；

&_middot;为制定测试计划提供功能和性能的测试依据；

&_middot;为客户教育和使用书的编写计划提供提纲；

&_middot;为客户售后服务支持提供产品的功能和性能总结及运行方案；

&_middot;为上级领导及客户提供产品开发的概述总结；

&_middot;为市场部门提供未来营销广告的指南和技术指标的细节；

&_middot;其他项目人员。

 

P220，产品使用方案指的是当这个产品杂客户或使用者的手里用来完成某一件任务时，使用者会怎样使用产品所设计的功能来具体地解决问题。包括对功能的描述和客户使用产品的具体步骤。

 

P220，每一个功能都是为了解决某一个具体的使用方案、解决某一个问题而设计的；那些没有具体使用方案的功能在开发时间受局限时往往首先被砍掉。

 

P221，在撰写设计规范之前先花一些时间验证某些功能设计的可行性和合理性，能帮助你尽量减少由于不合理的设计而造成的推翻重来的状况，和书写最后要被扔掉的东西所带来的时间上的浪费。

 

P223，在撰写设计规范书的整个设计过程中，要尽量征询其他同事的意见，让开发、测试、文档编辑等不同的开发专家一起参加你的设计工作。

 

P225，从理论上来讲，设计规范书正稿的通过意味着你正在开发的产品功能和特性在这一时刻就被冻结了，也叫功能设计的基准线（Base Line）被定下来。之后是编码工作的开始，功能就不能再随便改动了，因为每一功能设计的改动都讲影响到很多其他的工作。所有的改动要求都必须通过事先制定好的变更控制管理的规章制度来进行。

 

P225，功能设计基线是用来防止开发编程工作开始以后的无控制的功能扩张的要求——“功能蔓延”的现象，这种“功能蔓延”往往来自外部客户对项目要求的改变和内部市场人员等的不停地要求增加新功能的要求。

 

P226，每次设计规范书的修订和更新，都应该用专门的修订历史一节来对所有的改动中做详细的记录。

 

P228，微软有一个不成文的传统：所有的会议都不超过1个小时。原因是微软的文化认为做事要干脆，什么大事小事都应该在1小时之内解决，1小时解决不了，就会给人印象不是问题太难，而是说明你们这些开会的人优柔寡断、做事没效率、甚至是饭桶。

 

P229-233，设计规范书中应避免的差错和陷阱：

&_middot;设计规范书不够详细和完整

&_middot;设计规范书过分冗长

&_middot;撰写早期过分追求完美

&_middot;设计规范书更新太多或更新不够

&_middot;不向整个团队进行及时的通气

&_middot;不用正确的文档写作提纲和模板

&_middot;忽视对有待解决问题的处理

 

P230，设计规范书的详细角度是从开发可参照性的角度来考虑，也就是说，开发工程师们要能够参照设计规范书顺利地将产品的程序给编写出来，不需要再来问你很多细节就能够独立的将功能开发出来。

 

P230，设计规范书是否详细的自问：如果我不亲自回答开发工程师可能有的问题，他们能否从这份设计规范书了解我的所有设计思路而将产品开发出来？如果不能，就说明详细程度还不够。

 

P231-232， 整个产品的开发都要依照设计规范书来进行，要是设计有了改变，设计规范书有了更新，负责设计的项目经理必须及时向团队的全体成员通报最新的改动，使所有的 有关人员能做及时的调整。在规范书的前面采用一个更改修订历史的表格记录记录所有的改动，明确地标明到底什么改动或更新了。

 

P239，软件设计规范书需要进行审核，而且越是大型和复杂的开发设计，这样的审核就越需要重复多次；这个重复的、从审核到修改再到审核再修订的过程是需要时间的，制定项目的时间表要考虑到这个时间因素，以避免这些必需的时间花费而不至于被忽视而造成整个项目时间表的延迟。

 

（未完待续）
推荐到鲜果： 查阅更多相关主题的帖子: 范围管理