软件理解与项目管理实战

很多开发人员聚集在一起, 怎么工作呢? 如果大伙做的是搬砖的体力劳动 (我很喜欢用搬砖的例子), 那么在一定限度内, 人员的增长和项目复杂度的增长是线性的关系;

程序开发就有些不同, 项目管理的复杂度似乎是和人员数量的平方成正比。 一个团队里有 4 个成员, 就有 6 种双向依赖和交流的途径, 然后增加一位新成员, 就要增加 4条新的双向依赖交流的途径。 对于 N 个成员的团队来说交流的途径总数是 n * (n-1) /2, 这种 N 平方的增长是不可持续的。

软件 = 程序 + 软件工程

程序，在这里指的是源程序，就是一行一行的代码。仔细看过去，它们的确是建立在数据结构上的一些算法。但是光有代码还是不行的，这些一行一行的代码不会自己运行，得有人编译成机器能懂的目标代码，而编译不仅仅是 cc 和 link 命令，对于一个复杂的软件，我们不但要有合理的软件架构（Software Architecture）, 软件设计和实现 (Software Design & Implementation),   我们还要用各种文件来描述各个程序文件之间的依赖关系，编译参数，链接参数，等等。这些都是软件的构建。

软件团队的各个人员每天都在不断地修改各种源代码，怎么保证软件在不断的修改中能保证质量，不至于崩溃? 有些时候，我们要为某个需求写一些特殊功能，然后不久要把这些功能再合并回主要版本。有些程序还有32 位版本, 64位版本, 等等。 这是源代码管理 (Source Code Control) 的问题 – 有时候也叫配置管理 (Software Configuration Management)。我们还有一系列的工具和程序来保证程序的正确性，这些工具和程序本身应该更正确，才能保证别的软件的质量，对么?    这质量保证的工作叫 Quality Assurance, 也叫软件测试 (Testing).

一个软件要有人买，就得先找到顾客，顾客有各种需求，有些靠谱，有些不靠谱，我们要把这些靠谱的需求都实现了，一群人要从需求分析 (Requirement Analysis) 开始，忙碌各种事情, 例如设计（软件架构），实现（写数据结构和算法），测试，到最后发布软件, 软件在运行过程中还会出这样那样的问题, 也许我们要时不时给软件打一个补丁, 这叫软件的维护（Software Maintenance）。这一系列过程就是软件的生命周期 (Software Life Cycle, SLC),  有人得负责软件项目的管理 (Software Project Management)。

上面的这些和软件开发活动（构建管理，源代码管理，软件设计, 软件测试，项目管理）是软件工程的核心部分。广泛意义上的软件工程也包用户体验 (User Experience), 用户界面设计 (User Interface Design) 等。所以，我觉得:

这个和程序，软件，软件工程有什么关系呢，我们可以做一个类比：

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删