十人应用软件开发团队分析

对于一个以开发一般的商业应用软件的开发团队，一些概念进一步进行分析。

1、效率问题：

一个有经验的编程高手对于应用软件来讲一天的代码编写量可以达到400-500行代码，而对于熟练人员一般在200左右，对于新手每天小于50-100行代码。所以如果完全用最好和最差来比较的话符合1/10的比例，但一个小型开发团队不可能全部是新手，其主体部分人员应该属于熟练人员。熟练人员和编程高手的两个重要观点：

（1）、架构设计对开发人员有更高的要求，不能要求每个开发人员都精通架构。但在一个成熟的架构下，在一个开发人员完全理解了的架构下，熟练人员可以真正熟练的开发。

（2）、不能要求每个开发人员都有复杂问题或疑难问题的解决问题，进度滞后一个重要原因往往是开发人员遇到了意想不到的疑难问题花费了他们太多时间去解决。

2、概念一致性：

在一个小型软件开发项目中有两个重要的概念一致性，一个是对需求的理解，需要完全符合SMART原则；另外一个就是我们的架构设计，总体或架构设计确定了整个系统的框架，是软件开发中的一个重要里程碑点和审查点。

 

基于以上两点后，再来分析一个10人团队的合理安排:

1、需求人员(2人)：

在这里将业务需求分析和软件需求分析，界面DEMO制作等几个角色全部合并。所以对需求人员提出了更高的要求，需求人员要熟悉业务，同时也要熟悉软件工程和软件需求的开发方法。因此需求人员首先是同用户一起分析实际的业务流程，收集和分析需求，挖掘需求，在业务需求得到用户认可后将其转化为用户需求和软件需求。用户需求将纳入范围说明书的一部分，是最好用户验收的标准和基准。软件需求用于指导团队的设计和开发，是设计开发依据的基础文件。

2、项目经理(1人)：

在这里的项目经理技术和业务都要熟悉，在此的项目经理重点在于和客户以及其它干系人打交道。因此干系人管理是项目经理的一个重点内容。任何产品只有赚钱才是硬道理，所以PMBOK里面强调的范围管理，成本管理，风险管理以及团队建设，沟通管理，采购管理都是项目经理需要关注的内容，具体详细开发进度和开发质量控制项目经理需关注，但具体的制订由开发经理负责。

3、开发经理(1人)：

开发经理即项目中的架构设计师，总体设计负责人。项目经理和开发经理是相互协作的关系：一个主外，一个主内。开发经理的重点除了架构设计外，就是要负责软件开发的进度和质量。架构设计的重点就是保持概念完整性，我们关注点是在架构设计确定了后开发人员可以完全按照架构的思路来实现这些业务功能或模块。因此我们讲数据库设计，顶层包和类的划分，模块和单元间的接口，集成的方法，系统的安全性能或健壮性等为架构需要重点考虑的内容。开发经理在整个项目中参与编码时间约10-20%左右，主要是负责完成一些复杂或核心的算法，协作开发人员解决些疑难问题。开发经理需要完成工作有：

a.详细开发进度计划的制订，包括后期的测试进度

b.架构设计(数据库,模块单元划分,接口,复用,性能)

c.复杂算法研究或编码，疑难问题的解决

d.功能模块的集成，开发人员代码的Review

在这种情况下，开发经理能够得到充分的利用，基本在每个阶段都承担重要的任务。

4、编码人员(4人)：

编码人员水平不可能完全都达到熟练的水平，因此4人最好采用结队的方式分为两组进行不同功能或模块的的开发。这里并不一定要采用XP完全结队的这种方式，但我们强调的是通过分组后尽量减少沟通的路径，提高沟通的有效性。在这里的编码人员并不是单纯的Coding人员，而是包含了详细设计的工作，在小型开发团队中我们关注重点是总体设计和架构设计，对于详细设计应该由熟练的编码人员自己来完成，但架构人员必须随时检查概念完整性得到了执行，编码人员完全遵循架构思路在进行开发。

5、美工人员(1人)：

专职一名美工主要处于是否要考虑软件的产品化问题，如果要考虑软件的产品化，界面的友好性，美观性和易用性是很重要的。美工的重要职责就是保证界面整体风格的一致性和美观性。对于有一定的编码经验的美工，如果项目能够实现分层开发，则该美工可以承担界面层的开发任务。

6、配置管理(1人)：

对于小型项目而言源代码管理系统和缺陷跟踪系统是不可以省略的系统，这两个系统的管理和维护，代码的管理，每日构建和打包需要由配置管理来完成。这样来看，配置管理工作不是很饱满的，因此配置管理还可以承担测试，文档编写和秘书的相关的职责。

7、测试人员(2人)：

这里安排两名测试人员，一名做白盒测试和集成测试，一名做系统测试。对于做白盒测试人员在这里更多要理解为开发经理的副手，应该是对系统架构和业务都比较了解的人员。白盒测试人员保证系统的主体功能文档和集成正确，是提交系统测试的前提。同时白盒测试人员需要介入到代码的Review上面，一定程度上保证代码的质量。系统测试人员安排一名就足够了，系统测试人员需要编写专门的测试用例，准备测试数据。

对于小型团队，不可能像大型团队一样项目周期长，人员可以分期投入。因此如果保证各个人员在项目的各个时间段都可以得到充分的应用是务必关注的一个问题。因此项目的生命周期模型一般采用增量迭代开发方式，另外一种是Feature Based的开发方式，这两种应该将是可以很好将功能迭代起来的方法。架构必须要保证概念完整性和统一性，因此是不推荐在总体设计没有完成前就开始迭代开发的方法。

以上人员分配是基于项目的以有实践得出的，一个关键点在项目经理和开发经理两个角色的定位上面。通过定义两个角色进行了明确的分工，使架构人员作用充分发挥，但是带来团队中出现两个Leader的问题，这一块可以借鉴微软的MSF团队模型。