关于软件开发项目任务的横向分解和纵向分解

转

    在一个软件研发项目的管理实践中，项目任务的分解一直是一个很重要的工作，但是不同的项目经理对这个问题的操作方式又常常会千差万别，其中一个很常见的分歧在于，是横向分解还是纵向分解？本文试图对此进行一个简单的探讨，希望能给处于项目任务分解困惑中的项目经理们一点借鉴。

     首先解释一下这两个概念： 横向分解是指基于技术架构层次进行的人员角色分工和任务分解。比较常见的一种情况是，项目的技术架构采用表示层、业务层和持久层三层架构，然后这三层分别采用struts、spring和hibernate框架，于是人员招聘时分别对相应的框架使用提出要求，具体任务分解时先由项目经理分解好模块任务计划，然后由设计师定义好各模块的层次间接口，再将具体编码任务分解给程序员。 纵向分解是指基于业务模块的任务分解。比较常见的一种情况是，项目经理首先拟定出整体项目进度计划，再按模块对项目任务进行分解，设计师关注模块间的接口和技术体系的一致性，具体模块内的设计和实现由各模块的责任人相对独立地完成。 横向分解是目前普遍采用的方法，优点就不多说了，网上应该有很多相关的介绍，缺点却是很明显的：首先，对于普通编程人员来说，配置文件编写起来相当烦琐，常常缺乏编译期检查，就算有工具支持往往也没有编写代码来得顺畅。其次，看懂一个简单模块的代码通常也要在代码和配置文件间转来转去，比较吃力，特别对于接手前人工作的程序员来说，简直是个灾难。再次，横向分解是建立在模块内层次间良好沟通的基础上的，对于层次间的沟通要求很高，如果这一项工作做不好会使整个项目陷入泥潭。 当然指出横向分解的缺点并不是要对此种方案进行全盘否定，而且方案的缺点有很多在项目中是可以规避的，只是这种方案的成功实施是建立在很多假设的基础上的，比如说项目具有一定的规模，相关人员具有从事相关岗位工作的技术能力，层次间接口能够良好定义，项目成员间能够进行良好沟通等等，如果这些假设很多都不具备，那实施这个方案就会带来灾难。

    笔者曾经碰到过一个案例，是个视频门户的运维系统项目，项目总共只有10人，项目经理却坚持要采用横向分解，说是大公司像微软、IBM都是采用的这种方案，我只问了他两句话：你从哪儿知道大公司都是采用这种方案？你是大公司吗？当然他并没有认真考虑我提的问题，依然大刀阔斧地实施起了他的项目管理策略：首先设置两名QA负责测试，一名美工负责做页面效果图，剩下的六人分为前台三人负责表示层和后台三人负责持久层，他自己只做项目进度计划。刚分完他就发现业务层没人做了，由于业务层跟表示层联系比较紧密，自然这个任务就落到了前台三个人的头上，但很快就出现了前后台进度落差巨大的问题，于是业务层任务又改为由后台来做了，但由于接口没有很好地讨论好，集成测试又出现了很多问题。 其实很多刚起步或规模相对较小的软件公司都采用的是纵向分解的方案，由于资源有限，项目较多，又缺乏高水平的系统分析和设计人员，有的项目甚至从需求分析到编码测试都由一人完成，机械地套用横向分解的方案是根本行不通的。当然纵向分解方案对人员素质提出了较高的要求，不但要熟悉表示层的相关技术，也要了解持久层的基础知识，还要熟悉业务流程，重要的是市面上缺乏面向应用的分层的整合型的框架，能够方便程序设计人员快速地开发出设计良好的企业应用。