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应该复查更新的代码并确认代码被正确的修正。

评论

14 楼 forfail 2007-03-11  

我觉得文中谈得也是属于比较理想的情况：

1、例如对于outsourcing的情况，双方确认需求等等就不一定会得到一个比较理想的结果。
2、项目评估 ，对于新技术下的应用，如何评价项目成员单体评估的有效性，合理性等等。
3、code review,作为lead developer,手头还有相应的开发工作，这code review 的时间还不得不衡量一番。
4、还要充当调速器，抵御客户和领导等外来造成的波动。

13 楼 tianxinet 2006-12-03  

china2wto 写道

老板先是设定一个不可能做到的时间表，程序员只能安照这个计划做，到了时间做不完，老板一看急了，说先做个简单版本，去掉一些功能，修改一些需求，因为网站刚开始不需要哪些功能，将来可以不断增加，程序员发现，按照此时的需求变更，一些设计需要改变才能符合，需要有一定量的返工，这又是多出来的事情，然后按照新的计划表继续开发，结果还是完不成。。。。。（递归循环），每次都是超过时间计划。

像这样的情况怎么办呢？

这个在现实中或许没有完美的解决办法，因为对于大多中小公司来说，生存是第一位的，而不是规范，合理，优雅...
这个问题是客户和项目组共同的事情，做需求的时候就要理解哪些是核心需求，依次可以有功能的优先级，在依次有技术架构的优先级，技术点的优先级，等等，先解决用户最关心的问题，锦上添花的可以缓一缓，当然，一句经典的废话是“具体问题具体分析”，客户focus在哪里？真正的功能还是表面的华丽？这个已经不是技术问题，也不是管理问题了，这应该是生意上的直觉或感觉？

12 楼 china2wto 2006-12-02  

抛出异常的爱 写道

死亡环?
跳吧...
如果还不想跳
看看上面我写的东西...
血淋淋的东西啊...

PS:顺序不要变化....

死亡环

我突然发现“死亡环”可以成为这个主题的副标题！
有多少项目是一个不断恶性循环的过程呢？我想很多吧！

11 楼 clamp 2006-11-30  

"不行就删除某些功能先往外推"这句话很重要啊
老板可以决定进度，但是技术人员可以决定范围，或者告诉老板一组可能的范围/质量值，让老板选择。

10 楼 china2wto 2006-11-30  

clamp 写道

china2wto 写道

老板先是设定一个不可能做到的时间表，程序员只能安照这个计划做，到了时间做不完，老板一看急了，说先做个简单版本，去掉一些功能，修改一些需求，因为网站刚开始不需要哪些功能，将来可以不断增加，程序员发现，按照此时的需求变更，一些设计需要改变才能符合，需要有一定量的返工，这又是多出来的事情，然后按照新的计划表继续开发，结果还是完不成。。。。。（递归循环），每次都是超过时间计划。

像这样的情况怎么办呢？

1、技术人员为什么要答应不可能做到的时间表呢？
2、技术人员有责任把“将要发生什么”告诉老板，辅助其做出判断
不管级别是老板、项目经理、技术组长还是程序员，任何一个人只要知道更多的细节，都有责任在自己的范围内做出合理的估算并且拒绝执行不合理的计划。

首先说一下，老板并没有恶意的设定时间表，而是老板并不对项目开发在行，他只懂得赚钱，只知道，什么时候市场要做哪一步，如果项目没有完成到一定程度，市场就没法开展。开发市场的步骤一环套一环，开始了，就没法刹车，在某个时间就必须交出一个可以推出去的简单版本，根据市场情况不断的增加功能，所以就产生了以上的情况。我想很多会做市场的老板，也许都会遇到这个问题吧。怎么样权衡市场和开发进度？技术人员说，这个时间表不可能，老板会说出一万个市场的理由说，必须完成，不行就删除某些功能先往外推，所有的跑市场的人都等着项目呢！等你慢慢做，做好了，客户们逃跑了！

也许一开始老板的整个计划中，市场人员计划就先启动了。
也许老板没有很多钱，如果不加快速度，钱就会烧完。

9 楼 clamp 2006-11-29  

china2wto 写道

老板先是设定一个不可能做到的时间表，程序员只能安照这个计划做，到了时间做不完，老板一看急了，说先做个简单版本，去掉一些功能，修改一些需求，因为网站刚开始不需要哪些功能，将来可以不断增加，程序员发现，按照此时的需求变更，一些设计需要改变才能符合，需要有一定量的返工，这又是多出来的事情，然后按照新的计划表继续开发，结果还是完不成。。。。。（递归循环），每次都是超过时间计划。

像这样的情况怎么办呢？

1、技术人员为什么要答应不可能做到的时间表呢？
2、技术人员有责任把“将要发生什么”告诉老板，辅助其做出判断
不管级别是老板、项目经理、技术组长还是程序员，任何一个人只要知道更多的细节，都有责任在自己的范围内做出合理的估算并且拒绝执行不合理的计划。

8 楼 抛出异常的爱 2006-11-29  

china2wto 写道

老板先是设定一个不可能做到的时间表，程序员只能安照这个计划做，到了时间做不完，老板一看急了，说先做个简单版本，去掉一些功能，修改一些需求，因为网站刚开始不需要哪些功能，将来可以不断增加，程序员发现，按照此时的需求变更，一些设计需要改变才能符合，需要有一定量的返工，这又是多出来的事情，然后按照新的计划表继续开发，结果还是完不成。。。。。（递归循环），每次都是超过时间计划。

像这样的情况怎么办呢？

死亡环?
跳吧...
如果还不想跳
看看上面我写的东西...
血淋淋的东西啊...

PS:顺序不要变化....

7 楼 china2wto 2006-11-29  

老板先是设定一个不可能做到的时间表，程序员只能安照这个计划做，到了时间做不完，老板一看急了，说先做个简单版本，去掉一些功能，修改一些需求，因为网站刚开始不需要哪些功能，将来可以不断增加，程序员发现，按照此时的需求变更，一些设计需要改变才能符合，需要有一定量的返工，这又是多出来的事情，然后按照新的计划表继续开发，结果还是完不成。。。。。（递归循环），每次都是超过时间计划。

像这样的情况怎么办呢？

6 楼 tianxinet 2006-11-11  

deadline，呵呵，说句老实话，这么多年，很少见准确按时完成的项目（项目导向或产品导向都是），最糟糕的就是delay、delay、delay...，不过也不是那么悲观，甚至有提前完成的。基本上运用一些行之有效的手段，还是可以做到项目的可控性，这也是我对最佳实践比较感兴趣的原因。

5 楼 抛出异常的爱 2006-11-07  

OneEyeWolf 写道

往大里扯，就是Rapid development。
　　上面只是一些best practices.
　　要想在进度的压迫下，能够有清醒的头脑进行Rapid development，就必须掌握软件过程中的整个生命周期中的best practices.因为过程中任一个环节存在反模式，就可能全尽覆没，如对于变更处理上的失策，设计上的失败，内部管理失控，项目风险估计不足等。
　　避免重复在同一个地方摔倒。就要清楚并避免陷入进度延期的反模式，也要清楚项项目管理中的常见的假象，不能被迷惑，失去对项目真实进度的判断。
　　希望楼主能提供多一点实际项目中的一些操作。

一个在deathday前挣扎的人说(那个人是我):"
1.知道自己要干什么(多花点时间真的很值)
2.估计干完一个东西要多长时间(估计的人需要有经验)
3.完成这个BUG的重要度(如有多个BUG在等待时就非常有用)
4.死亡时间是什么时候.(担心是没必要的作不完是肯定的)
5.非常恶心的备用方案是什么(如人工输入,凭闭此功能)
"
以上如果对你有帮助那么我这几天的辛苦也没白废

4 楼 tianxinet 2006-11-07  

刚刚到Dr.Dobb，发现这篇文章仍然是top5，相当有生命力的一篇文章，补上原来未翻译的一段文档撰写说明，不再翻译，可以参考看看。

3 楼 tianxinet 2006-08-02  

to OneEyeWolf:
没错,最佳实践很需要,现在对于脱离与实际工作结合的方法的论述多到令人生厌的地步,所以我才翻了这篇文章,帖子的开头我已经说过,这也是我自己在实际工作中用到过的.

to chengren:
你当然可以那样作,你的工作你作主,只要很好的搞定就行,呵呵

2 楼 chengren 2006-07-30  

前景和范围文档中 我认为记录下相关的假设、风险也是同样重要的。

毕竟后面我们需要在工作中小心的验证这些内容。

1 楼 OneEyeWolf 2006-07-30  

往大里扯，就是Rapid development。
　　上面只是一些best practices.
　　要想在进度的压迫下，能够有清醒的头脑进行Rapid development，就必须掌握软件过程中的整个生命周期中的best practices.因为过程中任一个环节存在反模式，就可能全尽覆没，如对于变更处理上的失策，设计上的失败，内部管理失控，项目风险估计不足等。
　　避免重复在同一个地方摔倒。就要清楚并避免陷入进度延期的反模式，也要清楚项项目管理中的常见的假象，不能被迷惑，失去对项目真实进度的判断。
　　希望楼主能提供多一点实际项目中的一些操作。