快速软件开发(有效控制与完成进度计划)/软件项目管理系列丛书 (2008 年度畅销榜NO.1152 )

提高软件开发的速度，按进度计划完成项目，是软件开发项目管理最常见和最难解决的问题。本书在总结了包括微软公司在内的美国软件业成千上万个软件开发项目的实践经验、研究成果、经验教训的基础上，详细列出了几十种经实践证明可以直接在软件开发中应用，以提高开发速度的最佳实践方法、开发策略、实用技巧等，帮助开发人员和项目经理在了解软件开发中最常见错误的基础上，根据自身实际情况，制定出满足项目进度、成本、质量与其他目标要求的最佳方案。\r\n本书获得美国Jolt卓越软件开发图书奖，被誉为软件开发最好的实践指南。本书作者是多家世界知名软件公司(包括微软公司)的顾问,《IEEE Software》的总编，Construx Software 的总工程师。\r\n读者对象：技术领导、软件开发人员、软件项目经理、软件企业管理人员。\r\n

软件开发人员基本上是处于进退两难的境地中，一方面他们为解决开发中所碰到的各种问题，工作太刻苦，挤不出时间钻研有效的实用技术，另一方面，如果他们不学习掌握软件快速开发的方法，他们就永远不会有足够的时间。 摆在他们面前的问题是，在“尽快交工”计划的压力下，如何在开发进度与软件质量之间达到最理想的平衡。如果开发人员需要放弃看电影。读报纸。购物。休闲。锄草或与孩子玩耍的所有时间，连续工作20天才能按计划完成开发项目，那么，怎么可能指望他们投入很多精力研究软件可用性方面的问题呢?也就是说，除非我们把对项目进度的控制作为软件从业人员的必修课程，并为开发人员和经理们留出学习这方面专业知识的时间，否则，对开发人员来说，将会很难有足够的时间进行有关方面知识的学习。 软件开发时间的问题普遍存在。一些调查表明，2／3的项目超出了估算的时间(Lederer and Prasadl992，Gibbsl994，Standish Group1994)。大型项目平均超出计划交付时间的20％到50%,项目越大，超出计划的时间越长(Jones 1994)。一直以来，开发速度的问题都是软件开发业必须解决的头等问题(Symonsl991)。 虽然软件开发速度缓慢的现象普遍存在，但有些机构还是在进行快速的开发。调查人员发现，同一行业的两家公司生产效率的差别有可能为10：1，甚至更大(Jonesl994)。 本书的目的在于为当前是“10：1”中“1”的一方提供所需的信息，帮助他们向“10”的一方转移。本书将帮助你把项目变为可以控制，从而以更短的时间向用户交付功能更为丰富的产品。 在阅读本书时，你可以只看你感兴趣的内容，而无须阅读整本书，不管你的项目处于何种阶段，你都会在书中找到能够帮助你改善当时境况的实用内容。 本书适用对象 慢速的开发会对软件开发中的每个人造成影响，包括开发人员、项目经理、项目委托人和软件的最终用户，甚至包括其家庭和朋友，每个项目组在解决开发速度缓慢的问题时都有其各自的困难，本书将对常见难点逐一加以讨论。本书旨在帮助开发人员和项目经理理解什么是可行的，帮助经理和用户认识哪些是可实现的，同时也讲述了开发人员。项目经理和用户之间可行的沟通方式与方法，从而使得他们能够共同找到一条最佳的途径以满足项目计划、成本、质量与其他目标的要求。 1、技术领导 本书主要为技术领导或项目经理而编写，如果你是这样的角色，你可能经常要为提高软件开发速度承担主要责任，本书将告诉你如何去做，同时也描述了开发速度的限制，这将为你准确区分可实现过程与想象过程打下坚实基础。 本书中有些实用方法完全是技术性的，作为技术领导，学习并实施这些方法你应该没有问题，而另外一些实用方法则更多的是基于管理方面的考虑。可能你会问：“此处为什么包括这些内容?”在编写本书时，我做了这样一个简单的假设，即你是一个超级技术领导，你比快速的黑客还快，比疯狂的经理还强，能够同时解决技术问题与管理问题。我知道，有时这可能并不现实，但做这样的假设， 可以让我专注地讨论中心的议题，不必分心去描述“如果你是经理，这样做，如果你是开发人员，那样做。”我做的另一个假设是，技术领导同时肩负技术与管理工作，而不仅像字面想像的那样。技术领导经常肩负着为高层领导提供技术建议的职责，本书将帮助他们更好地完成这方面的工作。 2、程序员 很多软件项目都是由程序员个人或自行管理的项目组来承担的，事实上，这就将参与项目的技术人员推到了技术领导的角色上。如果你是处于这一角色，那么本书将帮助你提高开发速度，基于同样的原因，也可以帮助你成为一个好的技术领导。 3、项目经理 项目经理有时认为实现快速软件开发主要是技术工作。然而，作为一个项目经理，常常也会像开发人员一样，在改善软件开发速度方面有很多事情要做。 本书将描述许多管理层面上的快速开发实用方法，当然，你也可以阅读技术方面的实用方法，以便更好地理解开发人员所做的一切。 本书的主要特色 我是以“软件开发人员的直觉”，围绕“为什么我们常见的快速开发方法都基本失败了”这一中心来构思本书的。书中讲述的所有实践活动都是特定环境下开发人员实际工作的真实写照，正是这个原因，本书提倡在学习使用书中的方法时，应根据自身情况， 自己做一些小小的变革。 我个人对于软件开发的观点是，软件项目可以基于多种目的进行优化，如基于最低错误率、基于最快执行速度、基于最佳用户接受度、基于最佳维护性、基于最低的成本、基于最短开发周期等等。软件工程方法的一个主要目的就是要平衡得失：你能够通过降低质量要求、降低可用性要求、开发人员超时工作等手段优化开发时间吗?当项目结束的时间逼近时，你最终要压缩哪些环节? 本书将回答这些关键性的权衡问题及其他一些问题。 1、立刻用于提高开发速度 可以在你特定的项目中采用本书所描述的策略和最佳实践方法，尽可能地提高开发速度。通常，大多数人都能够通过采用本书中的策略和实践方法使开发速度大大改善。我可以说，对任何软件项目，你总会在书中找到若干适用的方法。根据你的项目情况，“最佳开发速度”有可能并不像你期望的那样快，这不仅仅是运气，也与你没有使用快速开发语言，或还在使用过时的代码，或工作在不利于生产的嗜杂环境中有关。 2、快速软件开发对传统理论的倾斜 本书中描述的有些方法并不属于典型的快速开发方法，如风险管理。软件开发原理和生命期计划，这些通常被看做典型的“好的软件开发方法”，而非快速开发方法的范畴。然而，这些方法具有深刻的开发速度内涵，许多情况下，也称它们属于快速开发这一主题。本书将这些方法在提高开发速度方面的实践，纳入到了与此相关的其他一些快速开发的实践方法中。 3、实践方法的重点 对有些人而言，“实践”意味着“编码”，对这些人，我必须承认本书并不“很实践”。我避免基于编码的“实践方法”主要有两个方面的原因：第一，我已经写过一本800页的有关编码实践方法与技巧的书籍(Code Complete，Microsoft Press，1993)，有关编码，我已没有更多要说的了，第二，许多有关快速开发的关键要素并非基于编码，而是一种策略和理念，有时，更是一种实践而非理论。 4、快速阅读结构 我尽可能以更为实用的方式来组织本书的快速开发资料。本书的前两部分描述了快速开发的策略和理念，其中有约50页左右的案例讨论，所以你可以清楚地看到策略和理念在实践中的作用。案例以明显的形式排版，如果你不喜欢这些案例研究，可以很方便地跳过。本书的其余部分是由一系列的快速开发实践构成，这些实践也以便于快速查找的方式编排，你可以根据自己项目的需要，很方便地找到感兴趣的内容。本书描述了怎样使用这些实践中的方法，使用该方法使计划进度缩短的程度，以及伴随而来的风险。 我在书中也采用了一些图标和特殊文字，用来帮助你快速找到与你目前阅读内容有关的其他信息，指出应避免的典型错误，最佳实践中容易忽视的盲点，或查找书中提到的定量的支持信息。 5、有关快速软件开发的新思路 在软件开发领域，快速开发方面的谈论颇多。最近许多毫无价值的开发方法都打着“快速开发实践”的招牌，开发人员对这些所谓的“开发实践”非常气愤。尽管有些“实践”也还是有用的，但它们真正的作用被开发人员的冷嘲热讽所掩盖。 每种工具的提供者和每种方法的倡导者都想让人相信，他们的工具与方法可以满足你在开发中的所有需要。而本书的目的，就是指导你正确分析快速开发方面的各种资源，就像要将小麦从谷壳中分离出来一样，帮助你找到快速开发的真谛。 本书提供了一个可操作的模型，该模型可以帮助你客观地分析快速开发的工具，以及决定怎样将其为你所用。当一个人来到你的办公室说：“我刚从GigaCorp公司获知，一种功能强大的新型工具可以将我们进行软件开发的时间缩减80％!”，你可能想知道这时你应做何反应。我无须讲述任何有关GigaCorp公司和它们新型工具的内容，当你读完本书的时候，你就会知道这种时候应该提什么样的问题，应该如何一分为二地判断GigaCorp公司这种说法的可信程度，以及如果你决定采用这样的工具，应该怎样将它们集成到你的开发环境中去。与其他的快速开发书籍不同，我并不认为所有的鸡蛋都可以放到同样尺寸的篮子里。不同的项目具有不同的需求，而一种方法很难解决项目计划中的所有问题。我一直以不能说是刻薄，也至少是挑剔的眼光看待这些快速开发实践的有效性，并一再假设这些实践不能很好地工作。书中我也再访了一些曾大肆宣传的实践方法与工具，即便它们没有以前宣传的那样有用，但对其真正有用部分还是应该倡导的。 6、为什么本书会有如此之厚 信息系统、商业封装软件、军事应用以及软件工程领域的开发人员都各自发现了一些有价值的快速开发实践方法，但不同领域的人员之间可能很难彼此交流经验。本书从每个领域收集最有价值的实践活动，很多快速开发的资料是首次汇总在了一起。 是否每个想了解快速开发的人都有时间读完这几百页的书呢?可能性很小，大多是读到一半的时候可能就不得不简化那些无关紧要的部分。作为补救措施，我将本书结构组织成便于快速阅读与选择性阅读的形式，在旅行途中或等车期间，也可以只翻阅一下简短的摘录部分。第1章和第2章包含有理解快速开发产品所必须的一些内容，读完这些章节后，你就可以任意选择自己感兴趣部分来阅读。 为何编写本书 项目客户和项目经理对慢速开发问题的第一个反应经常是加大项目计划进度的压力，让开发人员超时工作。有75％的大型项目和将近l00％的超大型项目计划进度压力过重(Jonesl994)，将近60％的开发人员说他们感到工作压力在增加(Glass1994c)，美国的开发人员每周工作时间在48～50小时(Krantzl995)，甚至更多，许多人认为工作负担过重。 在这样的环境中，软件开发人员的总体工作满意度在过去的15年中大幅度下降就不足为奇了(Zawacki1993)。项目的进度计划依靠对开发人员工作的拼命挤压来完成，导致开发人员工作负担过重，他们很自然会告诉他们的朋友与家人说，这一领域毫无乐趣可言。 显然这一领域还是有乐趣的，我们大多数人以前都从事过这样的工作，因而我们并不苟同编写软件只是为获得报酬的说法。当然，在开发过程中的讨论会上确实会有一些不愉快的事情发生，这些不愉快大多会与快速开发的话题密切相关。 是该在软件开发人员与项目进度这个海洋中设置一道堤坝了，本书中我试图树立一个堤坝标杆，确保大海那边的狂潮不致打乱开发人员的正常生活。 致谢 首先，衷心感谢本书的项目编辑Jack Litewka，感谢他在本书编辑出版过程中提出的建设性意见。同时也感谢Peggy Herman和Kim Eggleston为本书所做的精美设计，Michael Victor的图表、Mark Monlux的插图与说明。感谢Sally Brunsman，David Clark，Susanne Freet，Dean Holmes，Wendy Maier和Heidi Saastamoinen对本项目的顺利运作所做出的贡献。还有很多朋友为本书的出版做出了各种各样的努力，有些人没有直接打过交道，但我也衷心向他们表示感谢(主要有艺术家Jeanie McGivern，ArtSource的生产经理Jean Trenary和微软出版社排版及校样管理员Brenda Morris、Richard Carey、Roger LeBlanc、Patrick Forgette、Ron Drummond、Patricia Masserman、Paula Thurman、Jocelyn Elliott、Deborah Long和Deyon Musgrave) 。 通过对数以百计图书与文章的挖掘与分析奠定了本书的基础构架，微软公司的技术资料馆为此提供了无法估量的帮助。Keith Barland为此付出艰辛的劳动与宝贵的时间，对此提供帮助的技术资料馆其他工作人员包括Janelle Jones、Christine Shannon、Linda ShaW、Amy Victor、Kyle Wagner、Amy Westfall和 Eilidh Zuvich。 本书也从大量的他人审阅中获益匪浅。A1Corwin。Pat Forman。Tony Garland。Hank Meuret和Matt Peloquin从头到尾对本书进行了仔细推敲，感谢他们对本书所做的工作，使得你手中的本书并不像当初我写完的样子!同时我也从Wayne Beardsley、Duane Bedard、 Ray Bemard、Bob Glass、Sharon Graham、Grey Hitchcock、Dave Moore、Tony Pisculli、 Steve Rinn和Bob Stacy收到大量有益的意见与建议。David Sommer(11岁)也为本书的图14—3的最后定稿提出了一个好建议，谢谢David。最后，我要感谢我的夫人Tammy，感谢她精神上的支持与恢谐和幽默。我必须迅速开始我第三本书的编写工作了，以便她能停止取笑我，还管我叫业余作者!