理想团队的构建

有时，我在想最理想的团队莫过于一些创业团队了—— 分工明确。那些还存活着的公司在过去都有着那样理想的团队，然而随着公司业务与团队人数的增长，离这一些越来越远。

在我认识的那些创业公司的前端人员中，多数可能还充当着后台 API、App的开发，原因可归类为:

1. 招不到人

2. 没有钱

3. 不知道招什么人 (他们自己并没有意识到自己不知道)

如《REWORK》一书中所说的那样，只有在你真正受不了时才招人。如果同那些大公司一样，漫无目的地进行撒网，那么早晚会死在这条路上。通常在那些存活下来的团队(也包含没有存活下来的团队)里，一个人可能身兼多职，会有小部分的重叠，但是不会太多。

在这一个时期主导团队往往是Idea的所有者，Owner找来一个技术人员，这个技术人员再依照短处去寻找需要的人才。

 

随着公司业务的发展，出于个人、家庭、团队因素，总有些人会离职(人总是有需求的，WiFi应该是最底层的吧)，总需要迎进新人。

有序的团队

最初整个宇宙是混乱的、整个系统是混乱的、整个组织是混乱的。通过不断地分门别类，整个系统看上去似乎有序了。

 

在这样的团队里，A做着A应该去做的事，B做着B应该去做的事。

1. 如果A和B很熟悉，可能产生出ab —— 可能是一个新的系统，也可能是一个新的生物。

2. 如果A和B不熟悉，那么通过公司的各种各样活动会帮ta们产生ab。

3. 如果A和B不得已熟悉，那么我想这个ab可能是API。

在最初的团队里，A和B可能只隔着10cm，后来他们越来越远。

职能分明的团队是一个解耦后的系统，他们间的沟通需要比原来花费更大的开销。在传统IT公司及大部分的互联网公司都有这样的"最后一公里"问题。引自之前的文章《知识论(一): 知识传递》 :

传统软件开发流程中，知识传递的方式主要在于文档，而我相信在网上已经有足够的证据可以表明，程序员既讨厌看文档，又讨厌写文档。

无论是在系统集成环节，又或者是在交接环节，人们所做的一件事只是知识传递。因为职责让你不可能接触太多的东西，就好比原来你可以每天吃一点的药，突然要你在短期内吃完。

理想团队

团队类似于人物文明，更多地在于文化与知识的传承。人们想要一个理想的团队，但是他们往往并不知道他们真正的问题不在于团队本身——而在于团队是如何协作的。

理想型A

在多数的公司里，团队的组成方式类似于下图:

 

如果有一天大牛出车祸了，中牛roll off了，团队就剩下一堆绿帽子了...

在这样的团队里，我们可能会用下面的方式来教授团队的成员:

 

即类似于传统的授课制:

1. 你今天去把《Thinking Java》看一遍

2. 你今天去把《设计模式》看一下

3. ...

在这时候，那些领悟力比较好的就在NB的路上了，但是每次只会有那么一两个人。

理想型B

在另外一个理想型的团队里，人们想要的是这样的结构。

 

我想不到这样的团队还有怎样的知识可以传递。在这样的团队里，传递知识是相当于容易，因为大家很容易就懂得别人说的内容。

让团队中的每一个人都是全栈程序员的难度很大，然而这并不意味着这样的团队不可构建。

构建理想团队

在过去我们有师徒制，这样可以保证师徒间知识可以传递下来。而在多数的软件开发团队里，并不存在这样的制度，换句话说在这样的环境成长时，你只能依靠你自己。

 在一个团队里，当来了一个新人时你们会怎么做？

如果你是一个新人，你来到这样的一个团队:

1. A 教你如何使用各种快捷键。

2. B 教你使用一些特定语言的技巧。

3. C 教你一些基本的DevOps技能。

4. D 教你怎么追妹子。

5. ......

你会考虑加入这样的团队吗?

结对编程

或出于公司文化，或出于对自己的不明确认知，多数市场主导的公司并不会采用这样的方式来工作。这也导致了人们一直在追逐理想的开发团队时，一直找不到合适的时机。

 

这时，也许会有人提醒你，你多了个分号。我曾经在看别人的面试作业时因为多了分号，reject了一个人——因为语言是Python。

而这时候团队的组成，倾向于下图(图是盗的，上面的图也都是盗的 :) ):

 

在这样的团队里，并非每个人的技能都需要是一样的。会出现重叠，一个比一个强，可能有一个的技能点数是最强的。项目在不断开发地过程中，总会有人离职，有新人进来。

然而，在这个结对编程的过程中，知识都在不断地传递。

对软件流程的理解：

1.  

2. 首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计 进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、 运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

3. 详细设计 　　
   在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

4. 编码 　　
   在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。　

5. 测试 　　
   测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。

6. 软件交付准备 　　
   在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。 　　《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。 　　《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。

7. 7

   验收 　　用户验收。
   以上就是基本的软件开发流程。