很早前读过的一本书《oo项目求生法则》,颇有感触,用几篇文章说说:
先说最有用的,书中说了十大问题的症状和解决方法,总结如下:
一、清除迷雾
概要:尽力交付一些东西,将告诉你真正的问题在哪里
症状:
必须拟定项目计划,但是缺少相关信息
需要平衡的力量:
你需要更多的知识执行计划
需要一步步推进项目进程
处方
在短期内,创造良好的开端,交付系统的某一部分
过量服用的结果
如果真正追求“清除迷雾”,将得不到真正的进展
相关策略
按周期尽早交付
原型法
微型法
二、按周期并尽早交付
概要:尽早交付,发现那些你不了解的,按周期交付,逐步完善
症状
对开发过程某些部分没有把握
需要平衡的力量
需要更多的知识计划和建立项目
一步步推进项目进程
处方
创建进度计划,确定每个发布版本都交付什么
过量服用的结果
如果增量期间太短,则会耗费大量的精力
相关策略
清除迷雾
原型法
三、原型法
概要:建立一个独立的方案,并发现它如何起作用
症状
要设计一个用户界面
试验新的技术
项目依赖一个关键算法
需要平衡的力量
需要更多的知识
要推进项目的进程
处方:隔离问题,制作一个一个小原型
相关策略
清除迷雾
按周期尽早交付
微型法
四、微型法
概要:运行一个微型的类似项目
症状
你正在考虑一项技术是否适合你
你不知道你的开发人员多久能学会这个技术
你不知道这个技术是否有效
需要平衡的力量:必须进行决策和制定计划
处方:运行一个微型项目,收集关于人员、技术等信息
过量服用的结果:试验项目大小要适中
相关策略
清除迷雾
尽早交付
原型法
五、整体多样性
概要:在一个开发小组中,需要各种专业技能的人员
症状
经常听到关于“官僚过程”的抱怨
你注意到开发小组内部存在沟通障碍
开发小组是按照产品或者阶段划分而建的
人们通过书面传递信息,而不是通过交流
开发小组人员之间不互相尊重
开发小组人员都被任命做所有的事情,并且抱怨时间都花在沟通上
需要平衡的力量
随着人员的增多,会出现交流缓慢现象
项目需要多面手,但是很难找到这方面的全才
开发人员不愿外漏自己的技能
不同小组之间互相责备
一个方面无法容纳整个小组
处方
对于每一项任务建立2-5人的小组:负责包括需求、设计、编码、测试等全部工作
整个小组对模块负责
合理安排小组的规模和办公地点
过量服用的结果
如果小组只有一个人,那么将没有好的效果
相关策略
所有权
六、淘金热
概要:没有时间等待需求,于是需求每周都有新的变化
症状
需要平衡的力量
希望开发人员忙碌起来
希望系统早日交付
希望避免重复工作
处方
让下游的开发人员现在就开始工作,他们会对项目有一些新的想法
过量服用的结果
有些工作会重做
相关策略
七、每一交付产品都有人负责
概要:有时许多人做同样的工作,有时一项工作没人做
症状
你的程序中存在“公共区域”和“孤立区域”
没有人更新设计和类图
需要平衡的力量
处方
为每一个模块确定负责人
问自己下述内容由谁负责:
系统整体架构
应用软件架构
用户界面
oo设计
代码质量
测试testcase
过量服用的结果
如果所有权分配不合理,则管理冲突会占用团队大量时间
相关策略
所有权
干扰
日托策略
八、所有权问题
概要:每一个发布都有其责任人
症状
你的小组是按照功能划分的,没有为组件分配所有权
你的小组是按照组件划分的,没有为功能分配所有权
需要平衡的力量
按照功能分配所有权,会导致某些组件成为公共区域
按照组件分配所有权,会导致某些功能成为孤立区域
处方
为组件和功能都分配所有者
过量服用的结果
相关策略
九、干扰问题
概要:无论如何,要保证项目在前进
症状
非主要任务占据项目小组很多时间
人们抱怨干扰太多
需要平衡的力量
处方
确保项目小组中有人能够为主要任务的前进工作
每一个任务由一个小组负责
牺牲个人
过量服用的结果
相关策略
十、日托策略
将开发小组分成两部分
由几个专家、高手组成进度组,专门负责编码,尽量不要让他们分心
一个高手、专家配合一至两个普通人员组成培训组,负责解答项目中出现的问题以及培训方面
感兴趣的话,讨论一把