标签：
过去几十年系统、程序开发中，很多东西不是很完善，一个又一个的淹没在焦油坑中，程序编程编程系统产品，成倍需要高达九倍，而只有它才是真正有用的产品，是多数系统的开发目标。编程的乐趣有一种创建事物的纯粹快乐；快乐来自于开发对其他人有用的东西；整体过程体现出魔术般的力量；学习的乐趣；来自于工作易于驾驭的介质上。同时我们也有着编程的苦恼，必须追求完美；是有他人来设定目标，供给资源，提供信息；概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。更新快，制作慢。
软件项目中存在着灾难：1、开发人员对项目的非科学估测，乐观的认同；2、人数和时间互换的混淆；3、开发人员的乐观导致忽略了很多错误，相对反而增大了系统测试的量；4、软件经理空泛的估算，容易让软件顾客放弃自己；5、向进度落后的项目中增加人手，只会使进度更加落后。
做任何事情不能太过盲目乐观，还得有科学性的依据，脚踏实地，切勿浮躁。
有人认为一个开发队伍就应该像一个外科手术队伍——对应各自的职位、工作分配。这样可以避免杂事干扰工作，提供他们的质量和开发效率。同时，还要学会如何分布运作，交流模式，达到良好的效果。
同时团队必须保证完整一致的概念，这样才能让开发人员统一完整的战线，也才能打赢这场项目开发站。概念的完整性要求一个人来完成，这就是所谓的贵族专制吧。开发人员整个队伍协同开展工作，根据技术说明。按照时间进度，然后以切合实际的行动去完成项目开发，这就是所谓的民主政治。
一个结构师在项目开发中主要实现设计，但是不能支配开发人员，因为真正的实现是由开发人员完成的。结构师只是提供建议。
我们需要一个非常必要的工具——手册，上面是产品的规格说明。这就是开发人员需要追求的精确程度，定义规定什么，未规定什么。形式化定义，要选择一个标准，其他作为辅助。
项目开发首要看先决条件，如果没有，那么这是一个废项目，开发就是浪费财力物力人力。失败的教训中有两个重要的原因：交流和组织。孤立的工作环境并不一定好，开发人员缺乏交流，就对整个项目的问题不能进行及时的交流和解决，这样各位开发人员对开发进度无法全面了解。所以必要的交流是必须的。一个项目缺乏组织也是不行的。管理者对项目有个全面的了解掌握，才能进行全面的分工布局，对开发者进行恰当的位置分布，从而提供项目的开发效率和质量。项目工作手册，类似工作安排计划，这样项目才能有条不紊的进行。
只有不断的实践，从实践中获得经验，才能在开发工作中做到胸有成竹。
最后需要不断的对项目进行优化，一达到目前做好的效果。
软件系统可能是人类创造中最错综复杂的事物，往往一个很小的功能，其实也需要开发人员进行完善的架构设计，考虑对其他模块的影响，以及代码编写工作的难易。用户在前台可能看到的只是几个文字，实际中却是开发人员日夜奋战的结果。客户的需求不会考虑实现的困难，有可能他们认为可以轻易实现的功能，却会让开发人员抓耳挠腮。不得不说，这是两个世界的对话。
无论怎样，沟通是不可避免的，只有相互交流，相互理解，才能做出精品来。
关于著名的Brooks法则——对于进度已经落后的软件开发计划而言，若是增加人力，只会让其更加落后。人们常拿人月来计算软件的工作量，但是Brooks发现软件的开发工作是需要人与人之间密切沟通的，使得设计工作不易分割。一般来说，一件复杂的工作大量投入人力，会使工作完成的更快，更加出色，但是在软件设计中，就不是。尤其是大型软件开发。往往增加人手反而会起到反作用。不得不重视。
标签：
原文地址：http://www.cnblogs.com/zrdm/p/4299474.html
