Quick-Kill 项目管理

 （ 出处）
这是我今天在美国著名的Dr.Dobb开发网站上看到的一篇关注度很高的文章。我恰巧使用过文中讲的（或类似的）方法，而且效果不错，所以把它翻译过来作为参考。

原文：Quick-Kill Project Management

译文：

Quick-Kill 项目管理

作者：Andrew Stellman & Jennifer Greene 翻译：tianxinet（胖猴）－－最近致力于研究、介绍一些“最佳实践”

怎样进行敏捷的(smart)软件开发，即使面对“不可能的”时间表？

Andrew和Jennifer 是 “实用软件项目管理（Applied Software Project Management）”的作者(O'Reilly & Associates)。 在www.stellman-greene.com 可以联系到他们。

（译者注：文中lead developer、lead都可以认为是team leader，因为在小型团队中这些角色往往都是重合的，但也可以根据不同情况各安其位）

假如你是一个5人小组的lead developer，你在一个项目中工作了几周，小组才刚刚上路。你的小组成员包括高级架构师到刚刚走出校门的初级程序员。这时候你的上司把你叫到办公室，告诉你高层主管刚刚在电话里训斥了他，他希望你的项目在昨天完成。而当终于完成的时候，已经超过许诺日期很长时间了。用户有一项工作要作，并且这个软件是必须的。如果软件不能工作，或不能工作的很好，你最好去更新你的简历。

这是你最后一次加入这种高压力状况的小组，这种项目是一场恶梦。小组成员已陷于错误的歧路很多天，你不得不扮演英雄，每个周末投入其中工作40小时去修正严重的设计问题。和高级经理开冗长的会议，顽固的bug好像永远不能搞定，经常工作到深夜。当小组终于交付了一些东西，用户却恨它。似乎用户点击每一个button都会有一个bug，而他们期望的特性却从没有在交付的软件中出现。

Quick Kill
许多小组发现他们每天都处于类似的境况，lead developer面对严峻的考验。lead developer未必直接管理他的小组，但他负责把软件“送出门去”，他受到小组的尊重，当他作出一个决定，人们通常愿意追随他。但lead developer的工组不是管理而是开发，他需要花费大多数时间设计方案、设计软件、构建代码。

Quick-kil项目管理由3个方法组成，这些方法让lead能够使他们的项目产物满足老板的期望和用户的需求：
• 前景和范围文档（Vision and scope document）
• 工作分解安排（Work breakdown structure,WBS）
• 代码复查（Code review）

这些方法中的每一个只需要少许时间来执行，并且可以帮助小组避免一些最常见和代价高昂的项目缺陷。使用它们，leads能极大的增进交付满意软件的几率。

前景和范围文档(Vision and scope document): 6 小时
如果一个小组不能真正理解所构建软件的“内涵”(context)，他们很可能在整个项目过程中都作出糟糕的决定。这些糟糕的决定浪费小组的宝贵时间去修正，如果没修正，又会导致项目不能符合用户的需要而损害小组和用户的良好关系。（如果）对项目的真正范围(scope)没有很好理解，小组唯一能预见的事就是被人“在屁股后追”（urgency），他们脱离了试图满足的需求。程序员能够看到自己的单个程序，但是脱离了大的构想。这是导致项目延迟和失败的最大单一原因。

幸运的是，有一个简单直接和容易执行的经验来帮助小组避免这些问题――花不超过一天的时间写一份前景和范围文档，并帮助小组避免数周的改写和错误的开始。

写一份前景和范围文档的第一步是和项目的干系人（stakeholders）交谈。不幸的是，谁是项目干系人不总是显见的。Lead应该找出最受项目影响的人――要么他打算使用软件，要么软件不开发出来他就有麻烦。干系人通常乐于谈他们的需要，这正是lead developer――和其他小组成员，如果可能的话――应该和干系人谈的。和每个干系人谈不超过一个小时来获取他们的需求。

前景和范围文档应该是简明的、不超过两页（见下表）。通过和干系人交谈得到的所有信息应该加到“问题陈述”部分。

1. 问题陈述
a. 项目背景
b. 干系人
c. 用户
2. 方案前景（Vision）
a. 前景陈述
b. 功能规格(Features)列表
c. 将不会被开发的功能规格（Features）

（此处省略对此文档撰写的一些说明，见原文）

引用

补上这段说明的原文：
Table 1: Vision and scope document outline.

 

The Project Background section is a summary of the problem that the project solves. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should cover the reasons why the problem exists, the organization's history with this problem, any previous projects that were undertaken to try to address it, and the way that the decision to begin this project was reached.

The Stakeholders section is a bulleted list of the stakeholders. Each stakeholder may be referred to by name, title, or role ("support group manager," "SCTO," "senior manager"). The needs of each stakeholder are described in a few sentences. The Users section is similar, containing a bulleted list of the users. As with the stakeholders, each user can either be referred to by name or role ("support rep," "call quality auditor," "home web site user"); however, if there are many users, it is usually inefficient to try to name each one. The needs of each user are described.

The needs of the users and stakeholders are the most important part of this document. Unless the team understands the needs that drive the project, they may end up with a narrow focus, causing them to waste time addressing problems that are of little importance to the stakeholders. It's easy to build great software that solves the wrong problems, but the only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. That's the purpose of project planning.

The "vision" part of the vision and scope document refers to a description of the goal of the software. All software is built to fulfill needs of certain users and stakeholders. The team must identify those needs and write down a Vision Statement (a general statement describing how those needs will be filled). The goal of the Vision Statement section is to describe what the project is expected to accomplish. It should explain the purpose of the projects. This should be a compelling reason, a solid justification for spending time, money, and resources on the project.

The List of Features and Features That Will Not Be Developed sections contain a concise list of exactly what will and won't be built. Before writing these sections, the team should write the rest of the document and have an open discussion of the needs that they are trying to fill. Every single feature in each list should be built to address a specific need listed in the Problem Statement section. Often the team comes up with a feature that seems obvious, but that turns out not to really address a need. Features like this should be described in the Features That Will Not Be Developed section.

 

工作分解安排(Work Breakdown Structure,WBS): 2 小时
搞定了功能规格（features），开始针对这个功能规格工作之前，lead应该和小组一起提出对每一个功能规格的评估（estimate）列表。许多开发者在评估时会遇到很多麻烦，幸运的时有一些指导方针可以使评估过程简单可靠。

评估是重要的，因为它要求小组成员从头到尾考虑项目的每个方面。大多数程序员承认有这种不安的感觉：伴随着他们（原先）假定的任务的实现，原来（似乎）简单的问题会变得越来越棘手。如果其他小组的成员依赖这些工作，它可能把整个项目拖入混乱。好的评估经验可以避免经常发生的灾难。评估一个项目要求小组预先给出完成项目的步骤，并且提出每一步需要几天（或周，或小时），找出这些数字的唯一方法是整个小组坐下来考虑许多稍后在项目中可能被遗漏的细节。

做评估的第一步是把项目分解成一个完成最终产品要做的任务列表。这个列表叫做“工作分解安排（work breakdown structure，WBS）”。有许多方法把一个项目分解成一个WBS。lead developer应该把小组成员组织在一起开会讨论任务列表。

一个有用的准则是――任何项目都可以分解成10～20个任务。对于大项目来说（比如航天飞机），任务是非常大的；对于小项目（象简单的计算器程序），这些任务很小。

一旦小组成员就WBS达成一致，可以开始讨论每一个任务，以使他们能够对每一个任务提出评估。在项目的开端，小组成员没有做评估需要的所有信息；然而，他们需要提出数字。去处理这些不完善的信息，他们必须做一些关于待处理工作的假设（assumption）。通过做假设，小组成员能够为后面可能添加的信息预留位置，使评估更加精确。

假设是评估的重要关键，如果两个人对完成一个任务需要多长时间有争执，很可能他们对产品和生产产品的策略做的假设不同。换句话说，任何争执通常都是关于执行这个任务需要什么，而不是完成任务所要做的努力。例如，为一个设置计算机时钟的工具给出相同的前景和范围文档（vision and scope document），但是一个开发者可能假设做一个命令行接口，另一个开发者假设做一个结合系统控制面板的图形界面。

通过帮助另一个程序员讨论这些假设，并且就他们的分歧达成临时决议，lead能够帮助他们就此任务达成一致评估。Lead应该一个接一个地提出每一个任务，并且小组应该决定每一个任务需要多长时间。每次遇到争执，就意味着有遗漏的假设，Lead应该与其他小组成员一道准确地指出那些遗漏的假设是什么。当这些假设被发现时，应该记下来。当讨论过程和更多的假设被记下来，小组成员会对项目了解的更多，并且将要开始就软件怎样被构建做决定。这帮助小组就每一个任务的评估达成一致。

最终WBS应该由任务列表、每个任务的评估、任务的假设组成。提出WBS中10～20个任务的假设大概会用去小组1个小时的时间。创建WBS以及做评估的总时间大约2小时。这对于一个5人小组的基本评估应该时足够的。但是，如果是一个大项目，就需要把项目分成很多块，然后每一块用2小时去评估。

代码复查（Code Reviews）: 每次复查2.5 小时
在一次代码复查中，小组检查一个代码样本并且修正它的任何缺陷(defect)。一个缺陷是一个不能象程序员想要的那样运行的代码块，或者可以改进的代码块（比如让它更易读或提高它的性能）。

执行代码复查是一个帮助小组构建更好软件的有效方法。除了帮助小组发现并修正bug外，代码复查对于程序员进行被复查代码的交叉培训(cross-training)以及帮助初级开发者学习新的编程技术是有益的。最重要的是，当开发者知道随后有人要阅读的时候会趋向于写更好的代码。

代码复查的第一个任务是选择检查的代码样本。复查每一行代码是不可能的，因此程序员要选择哪一部分的代码需要复查。如果复查的代码选择的正确，代码复查会是有效的。多数项目中，大量缺陷集中在相对小部分的代码中。如果代码选择的好，那么复查能帮助小组揪出缺陷，轻易地节省远比复查花费的时间更多的时间，如果这些缺陷留在软件中，稍后会需要更多的时间来追踪和修正。

对于lead developer来说选择正确的代码样本并不困难。好的复查候选代码可能实现一个棘手的算法、使用一个难弄的API或者对象接口、需要特殊的专门技术去维护、或者可能使用了一个新的编程技术。这对于在一个软件中任何缺陷都将导致灾难的高风险部分选择代码样本是特别有用的――不仅仅是因为那些代码可能有更多的缺陷，还因为更多人会沿着这条线索去维护软件。当有大范围的修补时，引入缺陷的风险很高。

准备复查时，lead分发代码的打印稿（带有行标号）给每一个小组成员。小组成员分别花费半小时通读（如果可能并执行）代码样本一次，他们尽量指出代码是否真的在干作者想让它干的事。他们应该查找准确性、可维护性、可靠性、可控性、安全、可扩展性、复用性、效率问题。这些问题的任何一个都应该被看作是一个缺陷。每一个小组成员尽可能多的发现缺陷，并在打印稿上做标记。

准备完后，team leader把大家集中起来开复查会议。代码复查开始是由lead developer（大声地）阅读一段代码样本。他不是逐字阅读代码，而是做一个该代码块的简明描述。如果任何人（包括lead）不能理解这些代码在干什么或不同意给出的阐述，代码作者要解释这些代码应该完成什么，有时一个小组成员能够提出一个更好的、更加清楚的方法来完成同样的事情；通常只是大概说明这些代码的用途。

然后小组成员应该讨论代码中发现的任何缺陷，这时lead必须扮演会议的仲裁者。如果任何人发现一个缺陷，lead应该判断小组是否能够提出一个办法修正它，如果判断能，小组应该提出解决办法；如果判断不能，把它作为未决问题以便随后修正。另外，lead向包含复查记录(log)的表格中添加一行，每个发现的缺陷在这个表格中都有对应的行，每行列出包含缺陷的代码行号、鉴别人、以及一个怎样解决缺陷的描述（或者标记该问题为未决的）。在记录(log)的顶部，lead应该记下会议召开的时间以及复查的是哪一段代码。

复查会议应该不超过2小时。如果持续时间超过2小时，那么将来应该选择一个更短的代码样本来复查。会议结束后，lead应该把记录mail给小组成员，并且指定代码负责人修正缺陷。一旦缺陷被修正，lead应该复查更新的代码并确认代码被正确的修正。