软件工程实践者的思想[2]

软件工程实践者的思想[2]

5.工程

最狭义的工程，是描述"做什么"和"做到什么".

也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是"过程"和"方法"的事；而有效、快速地实现"过程"和"方法"所需的，就是"工具".

这种软件工程体系层次（SoftwareEngineeringArchitecturalLayers）被描述成一张图。

过程伴随工程而出现，解决的是工程中"步调一致"的协作问题。那么工程是因为什么而出现的？

很显然，软件规模的不断增大是导致软件工程出现的根本原因。所以你会看到在几年前，开发一个小工具可以不讲工程；或者现在在你的Word中，为了将半角替换成全角字符而写的那个宏，也不需要工程。

接下来，即使软件规模增大，如果有一个牛人中的超牛人，愿意用20年来写一个任意庞大和复杂的操作系统，他也是能做到的。然而现实中不会有软件公司给他这样的机会。

项目的"复杂"可能要求不同知识领域的角色参与，而"庞大"则要求更多（人力、技术与管理）资源。"团队"作为开发行为的模式，是软件规模和复杂度渐次累积的.结果。

团队必将越来越庞大，因为（与工程对应的）软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论、拥有大量工具的集团军面前一触即溃。

6.组织

工程理论其实是包含组织学的。然而我在上面的那张图中，将组织与工程分离开来，并在二者之间画下了一道纵向的线。

如果说工程关心的是"需求"、"配置"和"文档"等等这些要素，那么这样的工程还是停留在技术层面：关注的仍是工程实现细节，而非目标。从角色角度来看，这是项目经理和技术经理共同关注的那一部分。

然而项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等问题。这些问题与工程本身并没有直接关系，而是"组织"方面的内容。

所以在工程环节里，"文档管理"和"配置管理"等词汇中的那个"管理",是管理的具体技术和方法；而在"组织"这个环节中的"管理",才是真正的管理学上的用词。

在这张图上，我试图从这个角度上来说明：作为项目经理，你必须有一部分的工作是非技术性的。甚至，你可能绝大部分的工作是非技术性的。因为与技术相关的管理技能（需求、配置、过程管理等）可以由开发经理来做，或者公司对于这一方面有较统一且成熟的规范，因而无需投入过多的精力。

你必须更关注于对这个（或这些）工程的组织与计划。站在"组织者"这个角色上，你现在要考虑的内容可能会是：

为项目的各个阶段建立计划，并逐渐地细化计划内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度；

确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其考核办法；

对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；

为每一个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512M内存变成2G,还包括准确地评估他的工作量，以及决定是否为他增加一个（能协同工作的）副手；