《人月神话》读书摘要
买了好几月, 一直没翻, 不想在车上看了几十页, 很好读的一本书, 但我几个小时就读完了, 实在是对不住这本本厚厚的书, 呵呵. 以下是一些我认为的重要摘录和部分评论, 备注在行末的括号内, 已做浅色处理:
人月神话
- 当任务可分解或关系简单时, 人数越多, 效率越快, 否则反之. 所以说项目开发不是人员越多越好;
- 大团队不可能依靠面对面交流, 会议, 手册 (现在可以用BBS, WIKI一类的系统来实现这个);
- 更多的公司不是大型的专业开发团队, 除了开发新东西, 还要维护老东西, 老模块的维护该有专人负责, 他的综合素质应该很强;
变化是永恒的真理
- 变化(需求)是不可能杜绝的, 可行的解决办法是在约定时间内实现约定的需求 (不论是产品设计人员还是技术开发人员都害怕变化, 这表现为新手或缺乏项目实践的项目成员);
- 你至少需要一到两个高级开发人员, 他们在最忙碌的时候是最关键的解决问题能手;
- 不要在项目成员中设立职位级别, 比如 IBM 公司只有技术线和管理线两类职位, 不提"晋升"只说"调动";
- 系统越复杂越大, bug 越多, 任何系统都是亚稳定状态, 开发只是减少混乱的程度, 并且无法杜绝 Bug (过程管理的粗心和缺乏很要命, 就算再好的项目策划缺了过程管理质量会打折扣);
巧匠因为他的工具而闻名
- 使用好的工具: 更好的组件, 更好的技术, 更好的方法, 更高级的语言, 更好的测试方法... ;
整体与部分: 结构优于细节
- 精确定义产品: 功能定义, 规格说明, 描述规范化 (要做到这些很不容易. 而这才是开发的最大困难. 很多产品设计局限于界面和操作的设计, 内理上有很大缺限, 所以产品策划人员有开发背景再加产品特长则是上上人选);
- 定义整体结构, 自上而下, 避免初期在做架构时深入到细节, 这样有助于避免结构上的缺限 (单从产品设计的角度来说, 初期适合先做整体需求和功能规划, 比如先做一个网站地图(功能或页面提纲), 避免上手就做具体的网站页面设计图);
进度冲突与管理
- 进度表: 即阶段性目标, 有时间, 并且量化;
- 项目核心人员往往过高估计进度, 通常乐观化, 忽略了变化;
- 建议老板不要越俎代庖发号施令, 背后帮助项目经理来完成一些事情是为上佳选择, 非不得已, 老板都要维护项目经理的威信, 而不发生冲突;
- 仍然是过程管理, 简化之产品设计过程中的管理, 泛言为整个项目进展过程中的管理;
- "我们拥有一个富有热情, 老练的, 熟练的计划和控制小组." (Zomm.Quite 好像正在做类似的事情 "过程改进乃是催生可促生靠谱的人的组织!")
文档, 文档, 文档
- 文档: 产品层面需要简图和细致的需求说明, 同上;
- 流程图: 在产品层面表现为连续的简图模块;
- 自文档的程序 (PHP有一个可以自动生成文档的程序组件, 而 python 语言自身就带的自文档化也非常方便);
没有银弹
- 项目开发的创造性部分占据了大部分时间(比如产品策划, 技术架构), 其他的编码实施部分并不会很大程度地影响生产率, 如果会你可以请更熟练的技术人员;
- 基于以上原因, 开发效率不可能根本解决, 其他解决办法:
- 所以购买可用的组件是个好办法 (SOA看起来像个标准, 在其上构建可用的模块, 再比如 基于 Iphone 构建可用的模块, 是个不错商业之路);
- 精练需求: 开发人员最重要的工作不仅仅是编码, 而是帮助抽取和细化需求 (因为产品策划人员自身的局限或工作性质), 必要和充分的沟通十分是必须的);
- 快速原型: 演示需求脉络, 原型是最简化的系统实现, 但是这一个可扩展的架构, 日后的需求和扩展开发都基于此 (很遗憾的是我从未经历过想象中的原型开发... 囧);
- 需要更优秀的开发人员;
- 更需要优秀的设计(系统设计)人员, 而最好的设计人员通常不是最有经验的人员;
- 基于原型的增量式开发方法, 大受欢迎;
再论没有银弹
- "任何人若想看到一件完美无暇的作品, 他所想的那种作品过去不存在, 现在和将来也不会出现";
- 重用和交互构件只是解决了编码的效率;
- 用重用的大众软件代码完全个性化的需求, 易于定制的特性更受用户欢迎;
comments(5)