《OO项目求生法则》之“策略”

很早前读过的一本书《oo项目求生法则》，颇有感触，用几篇文章说说：

先说最有用的，书中说了十大问题的症状和解决方法，总结如下：

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

 

感兴趣的话，讨论一把