最小软件开发团队探索随笔2014

引论

通过最近几年的实践，对于软件开发的最小团队模式，有一些新的理解，和大家共享：

• 很多团队，公司在成本压力下，总是希望寻求一个最经济有效的团队组合，这个是可以理解的，也是该随笔的初衷。
• 最小团队不是指单纯的减少人员，不是把一个需要5个人做的工作压缩为1个人做。
• 软件开发本身存在一个众所周知的弊病，就是只要存在一个能够编码的技术人员，那么软件就总是能够“做”的出来，这也给人一个假象，软件开发的最小团队就是一定数量的“码农”；这个在其他领域比如建筑和制造几乎是不可想象的，究其根源，是因为软件的质量标准过于的飘渺： 我的意思是，最小团队绝不是几个“码农”。
• 人员可以合并，但角色不能合并；职能可以合并，但能力不能合并: 换言之,担什么角色就必须能做什么事情,就必须具备相应的能力.

总之,我对最小团队的看法,最小团队就是最少的角色,而这些角色不能再削减,但人员还是可以以兼任的方式来合并角色,不过在兼任过程中要注意不能有名无实,同时需要具备胜任该角色的能力.

三要素

软件时开发的三个基本要素是：管理，业务和技术。

管理： 除完全以单人方式进行的开发不在本文讨论的范围，2人以上就存在一定的团队管理，人员的协调，工作的安排，流程的部署，进度的监督等等，加上必然存在的客户管理，“鸟无头不飞”，说的就是管理者的必要性。

业务： 很简单，软件做了半天是为什么而做，产生什么效益和结果，这个都需要业务来完成，业务来自于需求，深化为设计，由测试加以验证, 最后接受者是客户。

技术： 更容易理解，没技术能叫软件开发？软件开发首先是技术活，但广义上来说，需求分析，系统设计和开发管理这些也都属于技术的范畴，只要需要方法论的地方就需要技术。

所以做软件先考虑其三大要素，是管理是否成熟，业务是否明确，技术是否过硬，就能知道软件是否能够顺利完成。

角色

下面我们从3个基本要素的基础上讨论下，探讨下我心目中的最少角色。

• 管理体系

n  项目经理： 兼顾客户管理和团队管理2大职责，在小团队中，这两种管理几乎不可能再拆分。

• 业务体系

n  需求分析：从客户获取需求并加以分析，重在和客户的交流。

n  系统设计：通过软件的设计方法，把需求升华为软件系统。由于系统设计是一种非常抽象的升华过程，这里我认为还是和需求分析分开。

n  测试：对软件实现业务的确认和评估者。

n  培训：业务的实施者，撰写系统相关文档（功能性文档），另外也需要负责客户的培训，由于该人员和测试人员有对内和对外之分，目前在角色上还是加以区分。

• 技术体系

n  主程：整个开发技术体系的支持者，就是我们一般理解的“技术高手”，在小团队中虽然还谈不上“构架师”的名头，但主程除了需要较高的研发能力以外，还必须能培训带动其他人员进入自己的技术体系。

n  业务开发：一般有被称为后端开发人员，由于目前的系统都需要大量的数据支持，这样的人员必然具有极高的数据处理功底。

n  前端开发：由于客户对界面的要求日益提升，前端人员目前的地位已经大幅提高，不但要熟悉界面构架，界面技术，相当程度也必须熟悉数据查询和后台技术。

n  界面设计：当前端开发不能达到美观要求，界面设计人员必须以自己的美术能力加以辅助设计。

目前来看以上9大角色几乎我认为的最少角色配备（非人员配备），当然其中，培训（如果软件简单到不需要培训），主程（技术简单到不需要高手研发），界面设计（界面简单到不需要设计），者3个角色为辅助角色，在特定的情况下可以考虑省略，尽管我认为这样的情况其实并不常见。

人员

有人会说,不是9个角色吗,我1个人或者2个全包了,这就是最小团队; 但如果每个角色的工作都要做好,显然不太现实. 又有人说了,那么有个角色就马虎点呗,反正软件给你做出来就行了: 好,这里就涉及本文的一个核心问题,我认为这9个角色如果被随意省略,或者根本不做,那么软件的质量将会受到极大的影响.

不过9个角色也不是一定需要9个人,那么最小的人员配备是什么的, 我谈下我的看法:

1. 项目经理可以和需求分析: 这个在很多团队几乎是一个标配,由于项目管理和需求分析合并同样是一种交流为主的工作,这样的合并并不违和.
2. 系统设计和业务开发: 刚刚说了,需求分析是更偏向于客户交流的工作,而系统设计则是更多依赖逻辑思维和技术理解的工作,这两者最好是分开. 而作为系统设计者,对技术构架的理解加上对业务本身的理解,做后台业务开发几乎是顺理成章.
3. 前端开发和界面设计: 在目前日益增长的软件界面要求下,前端开发的要求越来越高,其工作量和技术要求完全不在业务开发之下. 前后端人员分离是目前比较常见的选择, 另外, 前端人员业务也需要完成界面布局和一些美观方面的设计. 当然如果对界面美术要求非常的高, 还是可能需要其他美工的协助.
4. 测试和培训: 测试人员是业务的确认者,那么就不能由业务的开发者来兼任,系统设计看似是另外一个不错的选择,但一方面成本较高,另外一方面兼顾业务开发的系统设计人员可能无暇分身,加上后期培训需要的考虑,加入一个测试人员无疑还是比较划算的.
5. 主程: 这个人员是可选的, 如果团队技术框架稳定明确,这个角色可以不加,业务和前端开发人员一样能够完成系统的技术实现. 风险也较小, 但如果团队的技术框架是不成熟的,项目的技术风险特别大的,我强烈建议加入一个独立的主程人员,为项目的技术实现保驾护航.

 所以我心中的最小团队这样的:

• 一个具备管理能力和需求分析能力的项目经理.
• 一个能够进行系统设计和后台业务开发的业务开发人员.
• 一个具有一定界面设计和较强前端开发能力的前端开发人员.
• 具有测试能力和一定培训和文档能力的测试人员.

共4人团队.

如果团队技术体系不成熟,项目技术风险特别大的时候,请加入

• 一个具有很强研发能力,技术能力过硬,对软件构架有相当理解的主程人员.

共5人团队

当然根据项目的规模再适当增加更多的业务开发,前端开发或者测试人员,这里就不加累述了,而一般项目经理和主程不需要太多人参与.

 

总结

l  最小团队指用最少的角色组建团队,角色可以合并,但工作和能力不能省略.

l  软件时开发的三个基本要素是：管理，业务和技术

l  软件团队最少需要的9个角色是:项目经理,需求分析,系统设计,业务开发,前端开发,测试,培训,界面设计,主程.

l  最小团队至少包括4-5人: 项目经理,业务开发人员,前端开发人员,测试人员,必要时加入一个主程人员. 

 

最后，根据我目前的经验，最小团队的最大问题不是这个团队能不能完成任务，而是能不能找到5个合适的人员，最小团队的确大大削减了人员的数量，但其实是大幅提高了对人员素质的要求，少而精是它的本质，而在实际情况中，既不愿意化代价请高手，又不愿意化时间培训新人，却偏偏希望团队“少而精”，才是这种模式最大的尴尬。