小型团队软件开发：以RUP为中心的方法——软件工程系列 (2008 年度畅销榜NO.571 )

你希望改善下一个项目所采用的开发过程吗？也许你想综合使用Rational统一过程（RUP）和敏捷开发方法（例如极限编程）中的最佳实践方法。如果是这样，买这本书吧！\r\n 本书描述了一个完整的软件开发项目，从最初的客户接触直到软件交付。通过案例分析，它描述了一个小型的分布式团队如何设计并应用一个成功的开发过程。但这并不是对一个完美案例的分析，案例中包含了有效的和无效的做法，说明了团队在下一个项目中可能需要做出哪些改变。作者鼓励你评估他们的结果，并在你的下一个项目中使用从本书中汲取的经验教训。\r\n 本书所覆盖的重要主题包括：\r\n 在开发人员、开发过程和开发工具之间达到平衡；认识到软件开发主要在于人的努力；\r\n 使用RUP作为小型项目的适当基础；组合RUP和敏捷开发原则来建立可用的开发过程；\r\n 配置一个可支持项目成果以帮助其更有效工作的开发过程；\r\n 在项目进程中调整开发过程；\r\n 选择开发工具来支持小型的分布式团队；\r\n 有效地与客户打交道。\r\n 无论你是项目领导、程序员，还是开发团队的其他成员，本书都会向你展示如何激发特定开发过程的力量来显著提高团队的生产力。

译者序\r\n序言\r\n前言\r\n第1章 写在开始 \r\n　1.1 组成团队 \r\n　1.2 后续内容 \r\n第2章 在小型项目中使用开发过程\r\n　2.1 什么是小型项目？ \r\n　2.2 对小型项目运用的开发过程如何？ \r\n　2.3 从使用RUP开始 \r\n　2.4 让团队成员参与的技巧 \r\n　2.5 照规矩办事 \r\n　2.6 参考信息 \r\n　2.7 小结 \r\n第3章 人员、过程与工具 \r\n　3.1 人员 \r\n　3.2 过程 \r\n　3.3 工具 \r\n　3.4 什么会出错？ \r\n　3.5 小结 \r\n第4章 项目启动：项目成员形成团队 \r\n　4.1 结合成一个团队 \r\n　4.2 编写开发案例 \r\n　4.3 关于我们进度的报告 \r\n　4.4 为初始阶段建立迭代计划 \r\n　4.5 小结 \r\n第5章 初始阶段：我们开始取得进展 \r\n　5.1 项目前景：设定目标 \r\n　5.2 处理和管理需求 \r\n　5.3 定义初始用例 \r\n　5.4 项目管理 \r\n　5.5 建立开发环境 \r\n　5.6 迭代评估 \r\n　5.7 这听起来确实像瀑布式 \r\n　5.8 小结 \r\n第6章 细化阶段：建立框架 \r\n　6.1 细化阶段的目标 \r\n　6.2 生成测试和测试计划 \r\n　6.3 建立PSP Tools的架构 \r\n　6.4 对工具环境的改变 \r\n　6.5 推迟建立数据库 \r\n　6.6 范围管理：尽早并经常进行剪裁 \r\n　6.7 不能安装该产品是什么意思？ \r\n　6.8 对细化阶段进行评估 \r\n　6.9 小结 \r\n第7章 细化阶段详情 \r\n　7.1 开始细化阶段 \r\n　7.2 PSP Tools用户界面 \r\n　7.3 PSP Tools数据库 \r\n　7.4 单元测试 \r\n　7.5 小结 \r\n第8章 构造阶段：构建PSP Tools \r\n　8.1 再次调整开发环境 \r\n　8.2 构造阶段的目标 \r\n　8.3 构造阶段计划：项目的心跳 \r\n　8.4 实现过程加速 \r\n　8.5 在构造阶段中前进 \r\n　8.6 为什么开发会加速？ \r\n　8.7 其余的构造阶段迭代 \r\n　8.8 每个人都会在某个时候需要朋友：结对编程 \r\n　8.9 在构造阶段进行测试 \r\n　8.10 预见团队成员的变化 \r\n　8.11 小结 \r\n第9章 构造阶段详情 \r\n　9.1 精细调节用户界面 \r\n　9.2 完成数据库 \r\n　9.3 测试 \r\n　9.4 小结 \r\n第10章 移交阶段：交付PSP Tools \r\n　10.1 什么是移交阶段？ \r\n　10.2 向移交阶段过渡 \r\n　10.3 移交阶段的目标 \r\n　10.4 需求怎么样了？ \r\n　10.5 移交阶段的代码变更 \r\n　10.6 独立测试人员的重要性 \r\n　10.7 产品打包 \r\n　10.8 用户培训 \r\n　10.9 我们完成了吗？ \r\n　10.10 小结 \r\n第11章 事后分析：如何改进下一版？ \r\n　11.1 进行事后回顾的益处 \r\n　11.2 引导事后分析回顾 \r\n　11.3 我们的事后分析回顾 \r\n　11.4 为下一个项目团队进行清理 \r\n　11.5 变化的地形 \r\n　11.6 PSP Tools的将来 \r\n　11.7 小结 \r\n附录A Rational统一过程介绍 \r\n　A.1 通向RUP之门 \r\n　A.2 RUP的关键概念 \r\n　A.3 RUP里程碑 \r\n　A.4 小结 \r\n附录B 个体软件开发过程概述 \r\n　B.1 个体软件开发过程 \r\n　B.2 目标与关注的重点 \r\n　B.3 结论 \r\n附录C 极限编程介绍 \r\n　C.1 主要的价值 \r\n　C.2 极限编程实践方法 \r\n推荐读物

本书不是一本关于RUP、敏捷开发过程或者项目管理的教材，而是一份来源于实际工作的“战地”报告。它记录了一个小型的分布式团队，经历许多变化最终成功地完成任务，向用户交付一个有价值的、可用的软件产品的过程。在本书中，这些“战士们”以直述的方式讲述了他们的故事，没有试图去“执导”有关的内容。 我经常听到：“我们不需要采用一个开发过程，因为我们的项目又小又简单。”可能你也有类似的感觉。但是，实际上你总会采用某种开发过程，而且这一过程很可能是临时发明出来的。在我们的行业中有一种普遍存在的印象，就是一个预先描述好的开发过程只适合于大公司、用于大型项目、管理几百个开发人员；而对于小型项目来说，这种开发过程只会使开发人员过得更加痛苦。在本书中，你将会看到一个很小的团队在解决一个中等的项目时，如何按照他们的需要采用和剪裁RUP这样一个描述化的开发过程。他们并没有因为采用这一开发过程而增加过多的正规性。他们只选择了那些对自己有用的要素，甚至采用了类似PSP（Personal Software Process，个体软件开发过程）、极限编程（eXtreme Programming）以及其他一些敏捷开发方法。 我也经常听到：“让我看看你到底是如何做的。”成功项目的例子和某些不成功项目的反例常常是导致开始采用一个新开发过程的关键。仅仅埋头于书本中或者网站上，苦读一页页有关某种理想处理方法的描述，对于我们大多数人来说都太抽象了。包装好的、与理论严格匹配的完美示例没有太多的说服力。本书最大的价值在于，它带领读者接触到一个实际项目中的真实经历，包括了其中的失败、错误的开始以及各种限制；而作者以批判的眼光来分析他们所采取的做法，以及这些做法为什么会成功或者失败。我们从自己的经验以及与别人经验的对比中进行学习。“噢，是的，我知道这种模式；我也曾经处于这种境地。啊，你是这样解决的。” 本书讨论了在传统的开发过程（包括RUP）中都没有涉及到的问题。作者大胆地探索了关于开发人员、关于形成一个团队的力量、关于分布式环境中的通信联系、关于使用基于Internet的协作工具等方面的内容，而所有这些要素都是当前许多小型开源软件项目的组成部分。 最后，本书强调了一个常常在计划中标明了，而在赶着完成任务的过程中通常被遗忘的关键性的实践步骤：自省（self-reflection），有时也被称为事后分析（post-mortem）或者回顾（retrospective）。这一步骤就是暂时停下，回头看看我们做过的、我们是如何做的，看看哪些做法有效，哪些做法无效，以及导致这种结果的原因。而这整本书就是一个非常完整的事后分析的极好例子，坦白而谦虚。本书不能代替你没有做的那些事后分析和回顾，但是可以让你意识到可能错过了哪些东西。 那么，哪些人需要使用这本书以及何时需要这本书？可能性有很多：如果你刚接触现代的开发过程，如RUP、敏捷开发方法、PSP等等，那么本书可以让你了解它们的精髓，而不用深入到细节中去。如果你不确定该如何处理小型的分布式项目，你将可以学到极有价值的内容，这些内容的作者也曾经问过自己那些你可能会提出的问题。他们对这些问题曾经做出过选择，这些选择的对与错都通过最终的结果反映了出来。你很可能发现一些熟悉的模式，从书中的解答和解决方案中学会一些东西；这意味着在你自己的项目中犯的错误会更少。如果你是这些方法的专家，那么本书将为你打开新的途径——如何结合不同的方法或者缩减一个开发过程，并告诉你自省的价值。 我从这本书中学到了许多关于RUP的知识，并学会了从不同的角度来看待它。感谢Gary、Jas、Liz和Chris与我们分享他们的经验。 ——Philippe Kruchten于加拿大温哥华

Gary Pollice拥有近35年的软件开发经验。他在开始写作本书时是Rational软件公司RUP方面的元老，后来转向教育行业，担任Worcester Polytechnic Institute计算机科学系的实践学教授。
Liz Augustine在软件行业工作了20多年，先是作为软件开发人员，现在是一位技术文档作者。在其职业生涯中，她在项目中的主要职责是帮助软件开发人员更有效地工作。
Chris Lowe为DEC公司、Funk软件公司、Rational软件公司和IBM公司开发过软件。在业余时间里，Chris是Toastmasters International的成员，也是所在社区教堂的键盘手和歌手，是波士顿科学博物馆的志愿者，还是一名业余木工。
Jas Madhur从1985年开始在加拿大温哥华的高技术园区工作。他是最早的RUP团队的一员，后来担任过顾问，建立了一家e-learning公司。他在不列颠哥伦比亚大学教授软件工程过程学，还是国际系统工程协会(International Council of Systems Engineering,INCOSE)的成员。

软件开发的目标是向用户交付具有一定价值的产品。为了提高工作效率，你必须在开发人员、开发过程与开发工具之间维持适度的平衡。每个人似乎都有自己最喜欢的开发工具、技巧和开发过程。软件公司把开发工具和方法卖给你，帮助你提高构建软件时的效率。顾问们向你宣讲他们的方法，试图让你相信他们知道如何帮助你的机构和项目团队做得更好。而我们开发人员则不停地学习新的技术、采用新的工具，来帮助我们在更短的时间里以更高的质量完成更多的工作。 我们这些作者在各种软件项目中工作和对之进行观察的时间累计起来超过了七十五年。根据这些年中所得到的经验，我们得出一个结论，很可能一些聪明的读者也已经想到了：每一个项目都不一样，那些帮助某个团队取得了巨大成功的方法如果不具有通用性，可能会导致另一个团队的惨痛失败。每个团队都需要确定如何使用一个特定的开发过程，然后不断地进行调整才能取得进步。 而在这种不会停止的变化面前，一个项目团队如何知道改变哪些做法可以获得最大的效果？我们的答案是，依靠学习尽可能多的技术，依靠学习有效使用支持不同技术的开发工具，然后确定哪些组合可以工作得最好，以及它们在什么情况下最有效。这也意味着一个不断学习的过程。 好的程序员从其他的程序员那里学习。他们通过查看代码和阅读关于不同编程方法的书籍进行学习。测试人员通过学习测试专家的技巧、研究测试设计方案和学习如何使用新技术与新工具来获得提高。实际上，每一个独立的实践者都可以从其他从事相同工作的人那里，或者通过观察范例来学到知识。每个实践者都需要形成自己高效工作的风格，既作为独立的个人也作为一个更大的团队的一员。团队也一样需要利用其他团队如何工作的范例，来形成自己团队协同工作的风格。本书是关于一个小型团队如何开发一个软件工具的例子。它是关于我们做了什么以及为什么这样做的一本大事记。我们尝试着解释了为什么某些做法有效（或者无效），并讨论了下一次我们会改变些什么。在此过程中，我们特别指出了所获得的经验和教训，并提供了一些将这些经验通用化的思路。 读者所要做的，就是观察我们所做的工作并汲取我们的经验。如果你正在从事小型的软件开发项目，你将立刻根据我们的经历发现一些问题。你可能已经面临一些我们曾遭遇的问题，并按照自己满意的方式解决了，或者你仍在试图找到合适的解决方法。我们希望本书能够为你提供一些有用思路，帮助你选择和使用合适的开发工具，与他人一起有效地工作，并选择最适合你个人和所在团队风格的技术。 本书的所有作者都曾在软件行业的不同类型项目中工作了许多年，从很小的项目到很大的项目都曾涉及。我们对自己的工作都充满热情。我们在为Rational软件公司（现已被IBM公司收购）工作时相互结识。启动此项目的Gary曾经在第一个Rational Suite项目中工作，然后转到Rational Unified Process，即RUP团队工作。Liz和Chris曾和Gary一起在Rational Suite团队中工作，而Jas是RUP团队的成员。 我们看到过采用RUP或者其他开发过程并取得成功的项目，我们也看到过同样采用这些开发过程却失败了的项目。我们希望将要讲述的这个项目能取得成功。我们认为自己确实成功了。更重要的是，我们的客户认为我们成功了，这就是我们的故事，希望你能够喜欢它。 关于本书 在本书中，我们讲述了我们如何作为一个团队一起工作的故事。我们谈及了面对的一些技术障碍以及克服它们的方法。我们描述了遇到的一些模式以及我们如何将它们应用于自己的团队、项目以及代码。我们说明了这个小团队如何发展了一种在成员之间以及与用户之间进行有效交流的方法。我们还讨论了所采用的不同技术和方法，并根据不同的开发方法学，如RUP、极限编程（XP）等等，进行了调整。 本书并不包含任何一种特定软件开发技术的全部技术细节。它并没有描述一个开发过程。它并不是关于编写高效的代码、调试方法、测试技巧、需求管理或者过程工程的书。不过本书涉及了所有上述主题。 PSP Tools项目 本书是关于我们开发一个软件项目——PSP Tools的经历的大事记。PSP Tools的目标是为Watts Humphrey的PSP（Personal Software Process，个体软件开发过程）提供自动化的支持。在版本1中，我们为支持PSP等级1实现了计时器和数据收集工具。（关于PSP的更多内容，请参见附录B。） 本书包含了屏幕截图、表格以及其他反映我们工作进展的材料片段。为了使读者可以了解我们的实际工作方式，我们据实地展现了自己的经历以及最终的软件，而不是理想化地解释我们希望如何工作。在本书的网站www.awprofessional.com/titles/0321202945，包含了我们的所有代码、其他一些非代码的项目制品、到其他有用网站的链接以及其他后来发生的新闻。我们也很希望能够听到大家的意见，无论是对此书的反映，还是关于你自己的软件开发经历。我们的电子邮件地址是psptools@yahoo.com。 本书的组织结构 本书的组织结构如下：第1～3章介绍此项目的相关情况。我们介绍了自己进行软件开发的方法；对于在开发人员、开发过程与开发工具之间维持平衡的重要性的观点；及对PSP Tools项目的描述。 第4、5、6、8、10和11章分别从团队和过程的角度说明了这个项目。我们讨论了RUP的不同阶段以及我们在每一阶段中做了什么。 第7章和第9章提供了有关我们所处理的代码和使用的技术的详细情况。这两章并不是对整个应用的全面展示，而是用于体现一些代码的风格并解释我们所做的一些技术决策。我们希望这两章能够鼓励你从本书的网站下载整个项目内容来进行更深入的研究。 附录中提供了一些主题的信息，如RUP、PSP和XP，我们假设你对它们已经有一定程度的了解。 谁需要阅读此书？ 如果你是下列人士之一，那么你应该阅读此书： 一个正在寻求有关的技术指南，以使得团队整体以及其中的个人都能更有效率工作的项目领导者。书中也讨论了我们所使用的开发工具以及它们的替代产品，还提供了关于如何使用类似RUP之类的开发过程来帮助、促进交流的实践性建议。 一个工作于小型项目的独立实践者（一个程序员、一个测试员或者一个分析师）。本书可以帮助你学会如何在不增加无理负担的情况下，与团队中的其他成员进行交流。这里推荐了一些可能会有帮助的工具，并展示了如何有效地应用一种开发过程来指导、帮助你集中注意力，而不是给你增加负担。 一个工作于开源项目的独立实践者。本书没有专门讨论开源开发，但确实提供了一些类似于开源项目的经验。它提供了一个如何组织分布于不同地点的团队开展工作的范例。显示了这个团队如何调整其工作风格与使用的开发工具，以适应地理的分隔、完全不同的开发工具以及在相互独立的网络上进行工作。 其他对小型项目或者敏捷开发技术感兴趣，并对它们如何与其他开发过程（如RUP）结合感到好奇的独立实践者。 致谢 如果没有很多人的努力与贡献，本书将不可能得以出版。然而对于文中出现的任何错误，我们将承担相关责任。我们要感谢以下人士，他们的工作使得本书内容更为丰满、有趣和可信。 Gary 感谢整个开发团队。你们中的每一个人都在整个项目过程中提供了自己的见解、知识、努力与支持。 Raj Srinivasan在我们急需测试人员的时候加入进来，提供了有所侧重的、有益的问题报告。 我要特别感谢Philippe Kruchten和Per Kroll，从他们那里我领会了RUP的精神，从而形成了我自己在小型项目中使用RUP的风格。敏捷开发社区中的许多活跃分子教会了我很多事情，我试图将它们包含于我个人的开发过程中。 我尤其感谢与Bob Martin、Ron Jeffries和Randy Miller的交流。我确信其他的作者和我一样感谢为本书提供了极有价值的见解的审阅者们。 除了Per Kroll和Philippe Kruchten，我们很荣幸地请James Dunion、Magnus Lyckå、Bob Martin、Dan Rawsthrone和Chris Soskin对我们的工作进行了审阅。我们也很感谢来自于Rational软件公司的支持。 最后，我们感谢Addison-Wesley出版公司那些过去和现在帮助我们完成本书的人们，他们是：Paul Becker、Mary O’Brien、Brenda Mulligan、Amy Fleischer、Patrick Cash-Peterson，以及我们有才华的、仁慈的编辑 Rebecca Greenberg。感谢你们付出的时间和无尽的耐心。 Liz非常感谢我的经理Karl Hakkarainen，他支持并鼓励我在此项目中进行工作。感谢Gary领导了这一项目，同时感谢其他作者——Chris、Jas和Gary——在完成项目的过程中与他们一起工作非常开心。最后，我还要感谢本书的审阅者们，他们充满理解力的、大量而风趣的评论促使此项目富有成果。 Jas 真诚地感谢Gary、Liz和Chris，感谢你们的善意、友好、见解与支持。 Chris 我想感谢与我同一办公室的Steve Zerfas。他一直忍受着作为PSP项目一个组成部分的大量会议电话。他也比任何人更多地听我说：“在PSP项目中，我们……”。如果没有我的经理Dave Zygadlo的宽宏许可，我将无法在此项目中工作。他即使在“午夜项目”不时地延伸到白天后仍保持着活力。 最后，我希望感谢我的妻子Carmen，她对我写程序到深夜或长途旅行去拜访Gary从无怨言，而且始终欢迎Gary在来参加编程讨论时访问我们家。