一种更加合理、高效、符合客观规律的软件开发团队组成模式和工作方式

本文探讨了一种更加合理、高效、符合客观规律的软件开发团队组成模式和工作方式。作者经历并带领过小作坊开发、小团队开发、五十人以上的团队开发，也尝试过瀑布、敏捷等开发形式，因此更多的着眼点是从实际经验、从现实条件、从人的本性出发思考问题。

问题分析

在软件开发领域中，资源的浪费是普遍的。

其中一条重要的原因在于没有尊重客观规律：要么教条主义的学了几本书、看了一些理论以后就妄图付诸实践；要么是被客观规律打败以后沉沦，连客观规律都不愿意尝试去理解。

也许下面作者的一家之言以后也被证明是痴人说梦，但是发现客观规律、理解客观规律、从客观规律出发解决问题的思路绝不会是痴人说梦。

客观规律是什么？客观规律就是：软件作为一个思维的产物，是很难用工程的方法进行衡量和计算的。许多浪费就是勉为其难套用了一些项目管理、工程实践的方法造成的。

所以，与其把软件开发看做是造楼房，不如把软件开发视为写小说。看做造楼房，就会有许多加工人、赶进度的想法；视为写小说，就不太会有：“多加几个作者每天多写几章出来”的奇葩要求。

因此，首先必须强调的是：软件是思维的结晶！

其次，国产程序员整体上来说的特点是，有较强的进取和自我学习精神，有一定团队协作意愿，但是普遍内向、沟通能力、交流技巧欠缺。

最后，作为一个开发团队，必然存在新人加入、旧人离去、代码移交、绩效考核等诸多现实问题。

一种可能手段

基于上述原因，理想状态下，针对1个软件项目的1个高效的软件开发团队的组成只应该有3-5人：

• 船长角色：核心程序员x1，制定时间节点，构架设计和编码，完成75%-65%的代码量。

• 大副角色：程序员x1，按照指示编码和对外沟通交流，完成20%代码量，并且作为船长的备份。

• 水手角色：程序员1-3人，按照需求测试，少量代码维护和修改，完成5%-15%代码量。

针对上述团队形式的说明：

1. 这里的1个软件项目并不一定是传统意义上的软件系统。例如一套软件系统是由iOS、Android和后台组成的系统，则其中可以算作包含了3个软件项目。反过来，如果软件功能不复杂，算成1个软件项目也未尝不可。事实上，合理准确地划分好1个又一个软件项目是非常关键的。

2. 关于计划时间的评估问题，由于软件开发的过程中需要相应的知识储备、需要解决未知的技术性问题、需要填平一些看不到的“坑”，因此很难有固定的模式去计算，更多的需要依赖船长的经验。

3. 如果船长表示无法完成任务，需要慎重考虑两种可能性：任务划分的确不合理，或者此人能力不够不适合当船长。如果船长表示可以完成，但是需要远超前述的水手角色，请参考前面两种可能性。

4. 付出和回报必须对应，特别是主心骨，完成整体结构设计和最多代码工作的人。

5. 由于只讨论软件开发，因此设计师、产品经理等角色没有提及，但是不代表这些角色不重要。

6. 人数能不能更多？可以，但是尽量避免。特别需要警惕其中是否存在资源浪费的可能。如果发现10个人都不够用的情况，就要认真考虑分为2个项目2个团队的可能性。

优势分析

1. 采用这种方式，最大的优势在于最大限度的减少了沟通的成本。

2. 使得将来的代码重构、甚至结构调整都处于比较受掌控的范围。减少冗余代码、重复代码的出现可能性。

3. 最大限度激发成员的主观能动性，调动开发人员积极性。流水线出来的只是能用的产品，而唯有激情创造的才有可能成为杰作。

难点分析

1. 成员能力不足以支撑这种结构，没有人愿意承担主心骨的责任。这点需要合理的激励机制来保证。

2. 系统庞杂以后，任务分割、团队界限不清晰。这点尽量依靠将含糊的逻辑部分放入唯一的软件内部实现，避免在接口层面含糊。

后续手段

举例说说一些手段来验证一个软件的开发是简洁、易懂的：

1. 软件能够所有功能，即：在软件交付以后，按照所有需求文档要求的功能都可以使用，包含性能要求

2. 每一行代码/资源都是有效的，即：删除任何一个源代码包中的文件或者任何一行代码，都会导致编译错误或者运行bug（此处和软件的扩展性是有冲突的，但是出于减少后续交接的复杂度的考量，可以考虑舍弃）

3. 软件的结构是容易理解的，即：整个软件的框架设计可以在15分钟内被讲解完毕，在此基础上，每一个具体的功能项可以在5分钟之内被讲解完毕。讲解完毕指面对有一定开发基础、但是对该项目并无了解的开发人员，使他们明白软件的基本结构。如果超过此程度，则软件需要被划分。

完。