准确性显然是一个迫切希望的程序员技能。准确性是质量的关键因素，直接反映在完成的设计、编码和测试中。准确性的度量是一个重要的质量指标，即便它不是唯一的指标。因为没有bug、满足所有需求但是没有人喜欢的软件的准确性也不错。为了对质量有更全面的了解，还需要看用户的响应。关于这个主题，我们将在后面讨论。为了测量准确性，我倾向于关注发行后的产品问题和bug。正如前面章节所讨论过的，我不认为开发阶段的bug是一个有用的度量。开发阶段的bug存在太多的不可控因素，包括测试的时机以及测试的深入程度。从度量的角度看，我认为对开发阶段的bug的正确态度是，如果开发阶段的bug没有修复，则认为任务本身没有完成。产品问题既有严重的（例如主机系统的崩溃或者停机），也包括轻微的，如出错消息的拼写错误。应该跟踪每个问题，并且相应的产品领域以及每个领域的相关的程序员也应该尽量识别问题。每个问题应基于对客户以及用户的影响，使用一致的方法给予严重性评分。很多软件团队已经有了这样的评分系统。如果你的团队还没有的话，我建议使用简单的分级，例如从1到5，1代表“非常低”而5代表“致命错误”。对于“回归”bug需要做一些特殊的说明。“回归”bug指的是曾经正确的功能出现部分、全部故障的产品问题。回归bug对现有用户的感受和信心的伤害尤其严重，因此即使是一个可能微不足道的实际问题，其整体影响也可能相当严重。一般情况下，程序员要特别注意避免引入回归bug。一个建议是，将回归bug的严重程度给予比实际情况更高的评分。例如，对一个通常会评为“中等”严重程度的产品问题，如果是回归bug，则给予“高”严重程度的评分。对于某一特定的问题影响到多少客户进行追踪也有价值。一个导致崩溃的bug是一个严重的问题，但是如果所有的客户都会受到影响，则这个问题就会比只影响单一客户的情况严重得多。我建议按照对报告该问题的客户的影响来为严重度评分，但是也要单独跟踪每个问题影响到的（或者根据推测影响到的）用户的比例。我们可以根据所了解的信息对这个比例进行调整。确定一个问题所涉及的确切产品领域或者应该由哪个程序员负责解决这一问题也许并不现实，尤其是在刚刚发现或报告问题的时候。这可以理解，但根据我的经验，这并不是主要的问题。仅仅一个所占比例相对小的问题不清楚或者没有分配，这并不会带来显著的数据误差。随着时间的推移，将会调查和分配较重要的问题，此时就可以进行调整，确保度量已经反映了真实情况。因此，最终至少对于较高的优先级和较严重的产品问题，收集到高质量的数据是可能的。在某些情况下可能由多个程序员负责解决一个产品问题，而且负责修复问题的程序员未必是最早负责该问题的程序员（或唯一程序员）。如果多个程序员负责存在问题的产品领域，无论谁负责修复错误（这方面使用效率指标单独跟踪），该领域的bug应该均分到负责该领域所有的程序员。当程序员共同从事一个产品领域，将程序员的责任确切地按比例对应到每个人可能是很困难的。所以，除非可以清楚地确信某个程序员对问题相关的代码负有全部责任，我建议简单地将该问题对等地分配到负责该领域的每个程序员身上。例如，如果在后端发现了一个结构性问题，是由于对象－关系映射引起的，而该领域由三个程序员维护，我的建议是，在追踪方面，让每个程序员都负责该问题的三分之一。理想的情形是定义一个非常精细的产品领域清单，定义出对每个产品领域负责的程序员。这样保证当问题分配到特定的产品领域时，可以将问题关联到程序员。如果三个程序员分配到对象－关系映射系统，该系统有9个平均严重性为3的bug，那么可以认为每个程序员有3个bug（该领域共有9个bug，由3个程序员均分）和总计为9的严重度（总计27的严重度，由3个程序员均分）。产品问题包括配置问题、可扩展性问题或者性能问题，同时也包括编码错误。如果系统运行太慢或在高负载下崩溃，这些产品问题也应该跟踪。同样，你需要定义所涉及的产品领域和负责的程序员。此处也存在一个灰色地带，因为在某些情况下，客户或用户可能会要求增强或修改特性，这可能会解释为产品问题，或者在它导致更大的问题之前，你发现了系统中一个需要更正的限制或设计缺陷。对跟踪准确性而言，我建议关注那些清楚的案例，也就是应该可行而实际上行不通的情形。这意味着包括那些原始的任务需求，或者应该忽略的隐式的需求（可能是一个设计或者计划错误）。凡是不在范围中的，不是明确的或者隐式的需求的部分，不应作为一个产品的准确性问题。例如，如果客户发现一个页面缺少帮助链接，如果其他页面都包括一个帮助链接页面并且该页面也应该有一个，则这是一种准确性问题。如果所有产品中的页面都没有帮助链接，而非仅此一个，并且不希望有一个，这就不是一个准确性错误。再举一个例子，如果产品在一个期望的负载之下性能缓慢，这就显然是一个程序员的准确性问题。但如果该产品只是在远高于预期的负载下出现性能问题，那么这就可能不是应该跟踪的程序员准确性问题。如这些例子所说明的，这个灰色地带存在主观因素。但根据我的经验，我发现仅仅存在少量难以归类的问题。公平的评估也应该允许团队进行反馈，这有助于在程序员准确性数据中仅产生极少的、可忽略的失误。一旦你决定修复产品问题，会把该问题指定为一个工作任务，并有一个复杂度评分。我不认为有必要在问题修复之前进行复杂度评分。一个原因是，在有人调查或实际修复之前，复杂性往往难以确定。虽然你可能反驳说一个严重性很高、修复复杂性也很高的问题会比一个严重性很高但解决复杂度较低的问题更为糟糕。但从程序员准确性的角度来看，我认为两者是一样的。根据解决复杂度来对问题进行评分可能会产生误导。例如，如果程序员A工作的领域有3个关键严重性但都是低复杂度的产品问题，而程序员B的领域有2个中等和1个低严重性的产品问题，但都具有高的复杂度，你认为哪个程序员的工作准确性更好？我个人认为程序员B有更高的准确性，因为此时“错误”对用户的影响较小——尽管程序员B要做较多的工作来解决这些问题。很多时候，一个修复的复杂度和程序员从事的领域的复杂度相关。这也更使得我相信，通过复杂度对产品问题进行评分是一个潜在的误导的加权方式，从而使得准确性难以在不同的产品领域和程序员之间进行比较。所以，在此处我建议按照如下的步骤来跟踪程序员准确性：
对发布后的所有产品问题进行跟踪。所谓产品问题是功能失常，或者是系统没有按预期执行。按照对用户影响的严重程度对每个产品问题进行评分，保持度量的一致性和简单性，并考虑调高回归bug严重性。对每个问题影响到的客户的百分比进行估计和跟踪。定义细分的产品领域，把每个产品问题分配给相应的产品领域，识别出从事每个区域的程序员。如果把一个产品的问题分配到由多个程序员负责的领域，则出于跟踪目的，在程序员之间等分该问题。不要根据修复这些问题所涉及的工作的复杂度来进行评分。为了帮助了解每个程序员从事的工作以及团队的运作方式，我发现保持对每个程序员负责的内容的广度进行跟踪很有价值。对特定的团队所负责的软件，以及每个程序员发挥的作用，广度是关于其整体复杂性的关键指标。使程序员涵盖所有必要的领域，对任何软件开发团队的成功极为重要。一些程序员在一个领域优于其他领域，而另一些程序员更愿意处理多个领域，我认为这是另一种程序员技能。我发现跟踪广度最简单的方法是，使用和跟踪bug的产品领域相同的粒度定义，并确保所有任务都根据产品领域进行了跟踪。这适用于所有类型的任务，包括设计、编码、测试或bug修复。从而工作的范围与对任务本身的跟踪获得了一致。一个程序员的广度也就是他们完成的任务所涉及的产品领域的计数。另一个追踪广度的不同方式是，持续地跟踪程序员在发布版控制系统中的检入，对涉及的源文件的数量进行计数，或者用一个（自动或手动）的系统将源文件和特定的产品领域等同起来。然而，我担心只是跟踪源文件自身可能不是真正的广度指标。例如，一个产品领域可能有许多小而相似的文件，从而更新这些文件的一个程序员可能比另一真正工作在两个不同领域的另一个程序员涉及更多的文件。如果源文件能够等同于产品领域，则这提供了如上面所建议的相同的结果。如果能够完全自动化，这可能更为可靠。然而，根据我的经验，手动跟踪任务的产品领域已经证明是相对简单的方法。为了测量程序员的广度，我建议：
定义精细的产品领域，最好是保持和问题跟踪的定义相同。保证每个程序员任务都分配到一个或多个产品领域。用此数据跟踪每个程序员从事的产品领域。如前所述，程序员有多种途径来帮助他人，不管是在软件开发团队内部还是外部。人们要求或需要帮助的数量可提供很多关于软件产品和软件开发团队的当前状况的信息。乐于助人在很大程度上是一种程序员技能，有些程序员可能拥有或者比别人需要这种技能。程序员帮助他人的情况可提供很多关于个体的信息，否则他们的工作并不容易被注意，以及他们如何为团队的整体成功而努力。帮助他人可以包括，但不仅限于：协助他人发现如何解决问题、如何处理一个特定的任务；指导团队成员；协助客户；协助支持、销售或市场人员；协调小组的郊游或活动；帮助团队成员处理可能会干扰工作的个人问题；激励他人；提高士气。帮助他人可以定义为程序员在分配或计划任务之外，为了帮助团队实现其目标所做的任何事情。我认为对两块数据进行跟踪是有意义的。首先，我愿意跟踪一个程序员接收到请求后帮助别人的次数。这些事实上是对于程序员已计划、分配的任务的工作流的中断。请求可能会通过电子邮件、短信、电话或者亲自访问的形式。所有的请求都应该计算在内，无论这个请求有多小。只要与当前分配的任务无关，对程序员工作的任何帮助请求都是合乎条件的。我所找到的跟踪这一数据的最好方式也是最简单的，即要求程序员在特定的时间间隔（例如每周）内汇报他们所收到和响应的请求数量。通过这种方法得到的数字不会完全准确，程序员无法跟踪请求的确切数字，因此他们会向上或向下舍入进行估计。然而，对于个人和团队整体收到的请求，这些自报的数字仍然提供了一个在数量级上有序的测度。和整个团队公开分享这些数字能够使得大家尽量准确，以及与同事一起自我规范报告的数字。我希望跟踪的第二个数据是程序员在没有收到任何请求的情况下主动帮助他人的次数。同前一个数据一样，程序员在任何分配的工作之外提供的帮助都算数，无论这个帮助多么微不足道。为了跟踪这个数据，我发现可以要求团队成员承担观察员的角色，如果他们发现某程序员为他人提供了帮助，就通知数据记录者（我或者收集度量数据的其他人）。事实上，在许多情况下，报告的最佳人选是接受帮助的人。如上所述，帮助可以有许多形式，包括解决问题、做出贡献、指导、激励、团队建设以及个人支持。或许这种主动积极的行为正是你想鼓励的，因为跟踪这些行为能够辅助你达成这种目标。你有多种更可见、更有趣的方法可以实现对这些行为的报告。例如，你可以创建一个像team-assists@myorg.com这样的邮件列表，或者博客、wiki，从而团队成员可以在程序员帮助他人时引用他们。公开也激励了帮助行为以及报告行为。同时这也使得跟踪更为简单，因为可以简单地统计消息或者邮件主题的数量。或许你会思考是否应该为了这些互动行为获取更多的数据。我个人的经验是，令人惊奇的，尝试找出程序员在和谁互动（团队内或者团队外），或者试图找出原因，或者试图跟踪准确的花费的时间，几乎不会带来什么好处。首先，我发现收集更详细的数据可能很难。当数据是自我报告的，或者是由观察员（团队成员）报告的时候，要求更精细的数据可能会适得其反，从而导致较少的数据。仅仅当比较容易而且了解其潜在用途的时候，人们才愿意收集和报告数据。如果你要求程序员每周报告寻求帮助的次数和观察到他人主动帮助的次数，这是很容易的。但是，一旦你开始要求他们跟踪请求从哪里来、对象是谁、花费了多长时间，收集数据的难度就高得多。对于许多人来说，如果不能恰当地做到，或者花费了太多时间，那么他们宁愿干脆什么都不做。即使收集更详细的信息是可能的，我也不认为能够了解更多无法从其他途径看到的信息。例如，你可能认为更多关于程序员的“乐于助人”的交互能够告诉你更多有关特定质量或者团队的问题。但任何真正的产品质量问题应该迅速转换成bug或任务。同样，团队的问题（如程序员在学习一门新技术时遇到麻烦），也将呈现为任务不能完成或者延迟。最后，我的理论是，你从更详细的信息中了解到的，将会在其他方面的数据指标中获得。然而，乐于助人这一数据指标是唯一的，因为其指示了另外一种和成功高度相关的程序员能力与团队动态的元素。因此，对于度量程序员的乐于助人，我有如下建议：
程序员每周报告他们收到的与工作有关的请求以及他们的响应（超出分配给他们的任务）的频繁程度。如果软件开发团队的其他成员得到了主动的帮助，或者他们观察到一个程序员主动帮助了别人，也进行报告。和帮助他人一样，程序员的创新或主动解决问题可极大地帮助团队。我能想到很多从事过的项目，其中一两个创新，或者程序员主动承担了额外领域中一两个实例，成为成功的关键。由于程序员展现了这些能力从而使得团队更易于成功，在程序员度量中涵盖这些方面的贡献的分析，我相信这是非常重要的。但是，正如乐于助人一样，创新性和主动性难以用一致的方式进行识别和跟踪。所以，需要创造性地思考如何测量它们。我相信，在这种情况下，在评估程序员行动的突出创新，或者程序员在未解决的问题或机会面前展示了突出的主动性的时候，团队的领导者和管理者处于最佳位置。要求你的团队领导担任观察员，每当程序员展示了值得注意的创新或者主动行为的时候进行报告。用什么来确定创新或主动？我喜欢用“惊喜”作为启发式规则。如果程序员做了某事，使得你或他人感到惊喜，那么可能是他们采取了一些意想不到的创新或者主动。这里的关键是“喜”和“惊”的结合。如果你只是很高兴，但并不感到惊讶，那么很可能就意味着只是做得很好。如果你感到惊讶，但并不高兴，那么尽管他们可能试图创新或者主动，但缺乏高兴意味着他们一定做错了什么（放入其他一些类别，这里不讨论跟踪）。当“惊喜”的神奇组合出现时，在我的估计中，然后发生了一些值得注意的事情，值得跟踪。虽然我觉得“惊喜”的启发式规则有效，但称为惊喜的数据元素听起来有些滑稽。我不确信你是否乐于这样向你的经理询问（开玩笑）：“你对这个项目有多少惊喜？”或者这样说：“哇，我今天有一个真正的惊喜！”最好使用更成熟以及体现重要性的说法（特别是这确实是一个重要的数据）。因此，对我个人而言，我称为“附加项”或者“加分”。服务于跟踪的目的，我选择将主动和创新结合在一起，它们非常相似而且经常重叠。请记住，程序员可以在任何任务上，分配的或未分配的，或帮助别人时，展示创新性和主动性。和帮助他人一样，对于有用的指标来说，我认为保持程序员呈现的创新性和主动性的次数就足够了，尝试收集更多的细节，包括创新性和主动性的特定类型，或者涉及的时间和工作量，并不会带来多少好处。再次重申，保持简单会使得你的团队更易于跟踪它们。跟踪主动和创新很重要，我建议：
让团队成员在程序员呈现显著的创新或主动性时报告。要求团队领导为每一个程序员保持这些事件的数量记录。 相关资源：程序员度量：改善软件团队的分析学 azw3