文档介绍：Quick-Kill Quick-Kill 项目管理
项目管理
* 。我恰巧使用过文中讲的(或类似的)方法,而且效果不错,所以把它翻译过来作为参考。 
原文:Quick-Kill Project Management 
译文: 
Quick-Kill 项目管理 
作者:Andrew Stellman & Jennifer Greene      翻译:(胖猴)--最近致力于研究、介绍一些“最佳实践” 
怎样进行敏捷的(smart)软件开发,即使面对“不可能的”时间表? 
Andrew和Jennifer 是“实用软件项目管理(Applied Software Project Management)”的作者(O'Reilly & Associates)。 可以联系到他们。 
(译者注:文中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.