软件开发：个人与团队是永远的核心

Brooks在他的《人月神话》中指出软件行业没有“银弹”，如果将平台与框架开发当作是软件行业的“银弹”可就大错特错了，充其量它只是“龙骑士 ”。软件行业没有“银弹”的原因是，软件开发工作与人——个体和由个体组成的团队，息息相关。

再好的方法论都需要由个体去实施，而个体不可能是全能，因此我们需要团队。实施平台与框架开发的根本目的是为了实现高质高效软件开发，那高质高效软件开发又需要我们具备哪些技能呢？让我们从团队和个体层面去了解。

图 1是作者给出的高质高效软件开发的抽象团队效能模型。从这个模型可以看出，支撑高质高效软件开发的三大支柱是行为、能力和方法。行为支柱的内容包含个体行为和群体行为；能力支柱涵盖思维能力、业务能力和沟通能力；方法支柱则存在流程、工具和复用。

图1

能力是指为了完成某一任务所需具备的主观条件，而方法是达到某一目标的（客观）途径。因此，不要将“具备使用某某方法的能力”理解为“某某方法是一种能力”，犯这一错误的读者很容易认为模型中的“能力”与“方法”存在重叠。

由于抽象效能模型并不具体到某一团队，所以其中的内容并不具备很强的指导意义，但它为各具体效能模型提供了框架性的指导。我们可以根据需要将抽象效能模型运用到不同的团队上，从而形成各团队的具体效能模型。

图 2是软件开发团队的（具体）效能模型。其中的SCRUM可以根据具体的团队变为CMMI、乃至传统的开发方法；其中象Gcov等具体工具也可被功能相近的其他工具所替代。比如，用RTRT代替Gcov、用Klocwork代替Lint、用Purify代替Valgrind、用Subversion代替Git、用ClearQuest代替Bugzilla。

图2

开发团队效能模型有什么意义呢？首先，该模型告诉我们，如果真的要在软件行业找“银弹”，所找到的“银弹”应是“什么模样”的。其次，从模型中可以看出，时下流行的SCRUM敏捷软件开发方法论只是流程的一部分，而不是高质高效软件开发的全部内容。也就是说，团队即使对SCRUM这一方法论驾轻就熟，离高质高效软件开发这一目标仍相差很远。同样地，本书的主题——平台与框架开发，在这个模型中也只是一种复用方法，不是全部。最后，该模型可以当作是开发团队到达高质高效软件开发目的地的地图，让我们在开发活动中时刻关注我们需要什么，而不致于在前进的道路上因为片面关注某些内容而迷失。

读者或许会问：“为什么在这一模型中没有强调设计能力的重要性？”这是因为设计需要的是抽象能力（已涵盖于其中）。“那管理呢？”作者认为管理也可以象技术那样分解到效能模型已涵盖的子内容中。

除了从团队的角度了解高质高效软件开发需要关注哪些内容外，我们还得从开发工程师个体的技术能力角度加以审视。由于技术能力的范围很广，我们很难具体地说明开发工程师应掌握的技术细节，还得以抽象的方式加以表述。作者通过图3所示的技术能力分层模型将开发工程师的水平分为三层，它们形成一个“能力金字塔”。

图3

大约80%的开发工程师处于“金字塔”的底部，处于这一层次开发工程师关注的焦点是个体自身技能的发展。这些开发工程师的特点是：对（零散的）具体技术知识感兴趣；在工作中虽然遵守流程和服从管理，但对流程和管理的内涵并不关心，甚至认为它们是属于“浪费时间的事”；对于平台与框架他们更多关注的是如何使用；对于什么是软件设计并没有清晰的认识，更谈不上追求设计之美。这一层次的工程师在工作中或多或少地需要更高层次工程师的指导。

大约18%的开发工程师位于“金字塔”的中部，这一层次开发工程师的关注焦点除了个体技能提高外，还包含团队。这些开发工程师的特点是：他们对软件设计感兴趣，明白设计（而不是测试）是软件质量之本，并逐渐形成自己的设计思想，以及在工作中追求设计之美；在流程和管理方面，他们会积极思考“为什么要那样”、“有没有更好的方法”；对于软件平台与框架，他们不只满足于使用，而是积极探究其实现原理和细节。这一层次的工程师在团队中起着中流砥柱的作用，在工作中能独挡一面。

位于“金字塔”顶端的那2%开发工程师所关注的焦点就更广了，他们除了关注个体技能的发展和团队效能外，更关注软件行业。这一层次开发工程师的特点是：他们明白软件开发工作不只是技术和项目管理，而与人的因素息息相关；他们会思考如何通过流程去提高团队的开发效率和组织效能；他们理解质量保证是一个系统工程，需要“流程 + 工具”这样的方法论；他们更加理解软件平台与框架对于企业的意义，并会通过打造自有软件平台与框架来提升团队的开发效率和质量。这一层次的工程师在团队乃至公司中起着“领头羊”的作用。

或许有读者认为流程这样的内容不应是开发工程师所需关注的，而应由公司的质量管理部门或流程部门去操心。实则不然！开发工程师对于项目的真实状况是最了解的人，他们也最清楚怎样的流程有效、怎样的流程又只是形式，更了解开发质效上不去的根源是什么，因此他们更适合为团队制定（或修订）流程。

软件行业存在很大的一个误区：由开发工程师之外的人决定流程的内容。虽然很多制定流程的人出身于软件开发工程师，但只要他不是工作于具体的项目，他就很难帮助该项目团队制定适用的流程。流程的框架思想是相同的，但由于团队存在很大的差异，这就使得我们必须重视“量体裁衣”。作者并不反对最开始的流程框架源于质量或流程管理部门，但倡导最终的流程一定出自开发工程师之手、是开发工程师认同的。

当然，现实中又存在另一困境——开发工程师中真正关心流程的人很少，不可避免地我们会潜移默化地认为流程不是开发工程师应关心的内容。走出这一困境的方法不是将流程的决定权从开发工程师手中交出去，而是培养开发工程师的流程意识。

读者或许对分层模型中各层次人数的比例存在疑问，这些数字具有科学性吗？没有！它只是作者基于工作经历的个人主张。考证这些数据是否靠谱的另一种方法是将之与公司的绩效管理系统进行比较。但凡大一点的公司，其绩效管理系统一定会制定年终绩效考核时“杰出”、“优秀”、“称职”和“待提高”四类人的占比。“杰出”的比例会在5%左右、“优秀”的比例会在15%左右，而“称职”和“待提高”加起来会在80%左右。

开发工程师技术能力分层模型的意义何在？其一，指导开发工程师的职业发展。让开发工程师明白自己要努力的大方向是什么。其二，让团队在追求高质高效软件开发的道路上，关注团队是否拥有上面二层次的人，为团队组建和人才培养作指引。很显然，如果上面两层次的人员不具备，那要真正做到高质高效软件开发就根本不可能。

最后还得强调，效能模型和分层模型的目的在于强调人与团队是所有软件开发项目的关键。任何忽视这两大因素的方法和做法一定走不长、更走不远，也一定会让我们步入无法摆脱的困境。