- 用户操作
- [留言] [发消息] [加为好友]
- 订阅我的博客
-
-
-
-
- medie的公告
- 苦丁茶的Blog C++/VC问题请到 <a href="http://www.vckbase.com">VC知识库</a>询问 大侠多多 C++/VC源代码请到 <a href="http://www.codeproject.com">CodeProject</a>搜索 应有尽有 苏格拉底劝说一位失恋的年轻人，可怜的孩子，你怎么这么伤心？年轻人说，我女朋友不爱我了，她离开我了。苏格拉底说，孩子，该伤心的是她啊，她失去了一个爱她的人，而你失去的是一个不爱你的人。 <a href="http://blog.csdn.net/medie/archive/2005/01/01/236837.aspx">访客留言</a> Email:Medie@163.com [2005年1月1日创建]
- 文章分类
- C++/VC资源
- ChinaOak源码中心
- codeguru
- CodeProject
- sourcecode
- vccode
- VC知识库
- 中国网游研发中心
- 流行时代
- 程序太平洋
- 收藏
- Google在线翻译
- 汉字读音查询
- 网址之家-在线翻译
- 存档
画蛇添足与贯彻执行（转）
收藏
画蛇添足
开发人员在设计和开发第二个系统的时候是最容易造成过渡设计的。对于第一个系统他们更多是一种跟随，对系统和任务可能不是足够了解，他们会谨慎的工作，以完成师傅安排的任务为目标。对于第二个系统，他们有了第一个系统的经验，对系统开发充满信心，对于本来在第一个系统就已经有的增加修饰和润色的想法更加强烈。因此第二个系统最容易出现过度设计。
画蛇添足主要体现在以下方面，对于开发人员花太多的时间在界面美观性上面，但是更多还是从自我感觉出来，最终出来的是花哨而不简洁的用户界面，所以这里强调的还是对于界面规范性和交互设计还是要多征求美工和交互设计或用户的意见。另外就是过度设计，简单的问题采用复杂的思路或框架模式在求解，系统应该采用的架构的重量和框架模式应该是和具体的业务需求相关的，在能够满足扩展性和性能的基础上应该采用尽可能简单的方法来实现，对于越新出来的技术往往是越存在不稳定和不确定性。
需求的镀金是画蛇添足的另外一个重要方面，对于开发人员往往容易主观臆断客户需求某个功能，或者说是根据自己开发历史系统的经验猜测用户需求某些功能，这些都不是不可以，但是关键点是任何对需求功能点有增加和修改的想法最好都得到用户的确认。自己主观增加了某项功能就是一种需求镀金，这不仅仅是增加了软件开发成本，打乱原有的开发进度计划，而且往往降低用户的满意度。
为了避免画蛇添足，需要引入一些机制。比如软件开发规范的制定，其中又包括了界面设计规范，需求开发规范，数据库设计规范，代码规范等等，这些规范必须要得到严格的执行。另外就是评审机制的引入，在需求阶段引入了评审机制有利于减少需求镀金，在架构设计阶段引入的评审行为有利于保持概念的一致性和确定架构与业务目标的匹配度。
贯彻执行
我还是希望把贯彻执行理解为一种团队纪律，团队精神和团队建设很重要，但它的重点是积极团队凝聚力和工作积极性等问题。而一个在再积极主动也可能会犯错误，也可能有松懈和不能严格要求自己的时候，纪律的目的就是要避免这种情况。纪律不是僵硬的过程，纪律是一种团队规则，是经过团队共同讨论后确定的，因此项目经理应该首先带头执行团队纪律。
纪律必须文档化和有理有据，如果没有文档化下来。我们经常就是口头说下次应该怎样做，但是这是停留在口头上的东西具体的执行细节都无法查询到，团队成员在下次仍然是犯相同的错误。在多次没有按照纪律执行的团队成员，必须承担相应的责任。当制定的团队纪律没有得到严格执行的时候，就会有更多的人破坏纪律，最后团队规则就成为了一张白纸。
对于软件需求规格说明书，架构文档，用户手册和帮助，安装部署操作等等都是需要规范化和文档化的内容。一项工作内容如果贯彻了整个软件开发生命周期或者和用户交互，那工作内容就是文档化的重点考虑对象。工作内容不仅仅是文档化，而且是规范化。文档化后必须要体现其价值，而体现价值的重点就是关键和核心的内容都在文档中进行了描述。我们需要定义对于软件需求，架构设计等等工作各自的关键和核心内容都是什么。
会议在软件开发中是不可避免的，会议的关键点在于有效。对于周例会，有效的重点是统一目标，协商承诺，因此会设计到任务完成情况和任务安排，问题和风险等内容。对于评审会议有效体现在是否发现了关键性的问题，防止了重大缺陷的泄露，因此缺陷泄露情况是重要的衡量标准。代码走查的有效一方面体现在控制代码质量和白盒测试，一方面体现在团队共同学习和技能提高。
项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。测试小组应该独立于项目经理外，以保证三权分力，测试人员是用户的代言人，他们的作用既包括了验证也包括了确认。对于确认是检查最终的产品是否可以满足用户的需求，对于验证则是重点检查当初制定的需求，规则和设计决策是否都得到了严格的贯彻执行。
开发人员在设计和开发第二个系统的时候是最容易造成过渡设计的。对于第一个系统他们更多是一种跟随，对系统和任务可能不是足够了解，他们会谨慎的工作，以完成师傅安排的任务为目标。对于第二个系统，他们有了第一个系统的经验，对系统开发充满信心，对于本来在第一个系统就已经有的增加修饰和润色的想法更加强烈。因此第二个系统最容易出现过度设计。
画蛇添足主要体现在以下方面，对于开发人员花太多的时间在界面美观性上面，但是更多还是从自我感觉出来，最终出来的是花哨而不简洁的用户界面，所以这里强调的还是对于界面规范性和交互设计还是要多征求美工和交互设计或用户的意见。另外就是过度设计，简单的问题采用复杂的思路或框架模式在求解，系统应该采用的架构的重量和框架模式应该是和具体的业务需求相关的，在能够满足扩展性和性能的基础上应该采用尽可能简单的方法来实现，对于越新出来的技术往往是越存在不稳定和不确定性。
需求的镀金是画蛇添足的另外一个重要方面，对于开发人员往往容易主观臆断客户需求某个功能，或者说是根据自己开发历史系统的经验猜测用户需求某些功能，这些都不是不可以，但是关键点是任何对需求功能点有增加和修改的想法最好都得到用户的确认。自己主观增加了某项功能就是一种需求镀金，这不仅仅是增加了软件开发成本，打乱原有的开发进度计划，而且往往降低用户的满意度。
为了避免画蛇添足，需要引入一些机制。比如软件开发规范的制定，其中又包括了界面设计规范，需求开发规范，数据库设计规范，代码规范等等，这些规范必须要得到严格的执行。另外就是评审机制的引入，在需求阶段引入了评审机制有利于减少需求镀金，在架构设计阶段引入的评审行为有利于保持概念的一致性和确定架构与业务目标的匹配度。
贯彻执行
我还是希望把贯彻执行理解为一种团队纪律，团队精神和团队建设很重要，但它的重点是积极团队凝聚力和工作积极性等问题。而一个在再积极主动也可能会犯错误，也可能有松懈和不能严格要求自己的时候，纪律的目的就是要避免这种情况。纪律不是僵硬的过程，纪律是一种团队规则，是经过团队共同讨论后确定的，因此项目经理应该首先带头执行团队纪律。
纪律必须文档化和有理有据，如果没有文档化下来。我们经常就是口头说下次应该怎样做，但是这是停留在口头上的东西具体的执行细节都无法查询到，团队成员在下次仍然是犯相同的错误。在多次没有按照纪律执行的团队成员，必须承担相应的责任。当制定的团队纪律没有得到严格执行的时候，就会有更多的人破坏纪律，最后团队规则就成为了一张白纸。
对于软件需求规格说明书，架构文档，用户手册和帮助，安装部署操作等等都是需要规范化和文档化的内容。一项工作内容如果贯彻了整个软件开发生命周期或者和用户交互，那工作内容就是文档化的重点考虑对象。工作内容不仅仅是文档化，而且是规范化。文档化后必须要体现其价值，而体现价值的重点就是关键和核心的内容都在文档中进行了描述。我们需要定义对于软件需求，架构设计等等工作各自的关键和核心内容都是什么。
会议在软件开发中是不可避免的，会议的关键点在于有效。对于周例会，有效的重点是统一目标，协商承诺，因此会设计到任务完成情况和任务安排，问题和风险等内容。对于评审会议有效体现在是否发现了关键性的问题，防止了重大缺陷的泄露，因此缺陷泄露情况是重要的衡量标准。代码走查的有效一方面体现在控制代码质量和白盒测试，一方面体现在团队共同学习和技能提高。
项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。测试小组应该独立于项目经理外，以保证三权分力，测试人员是用户的代言人，他们的作用既包括了验证也包括了确认。对于确认是检查最终的产品是否可以满足用户的需求，对于验证则是重点检查当初制定的需求，规则和设计决策是否都得到了严格的贯彻执行。
发表于 @ 2008年03月03日 09:02:00 | 评论( loading... ) | 举报| 收藏
旧一篇:『转』十个笑话 换种心情领悟人生 | 新一篇:未来的it界需要概念研发（转）
- 查看最新精华文章 请访问博客首页相关文章
-
- 发表评论
-
- 表 情：
-
- 评论内容：
- 用 户 名：