在本书中，GaryPollice、LizAugustine、ChrisLowe和JasMadhur四位作者以自己的亲身经历说明了如何在一个小型团队、小型项目中应用Rational统一过程。其中包含了对开发过程中各种做法的原因和结果的全面分析，说明了开发团队如何对开发过程与开发环境进行动态的调整。本书的主要内容包括：如何在开发人员、开发过程和开发工具之间寻求平衡，并且在软件开发的整个过程中动态地维持这种平衡；如何组合RUP和敏捷开发原则中的多征方法来建立团队自身的开发过程，并且在项目进程中对开发过程进行适当的调整；如何选择适当的开发工具来对团队的活动提供支持，尤其是对于一个小型的分布式团队需要考虑哪些问题；客户的参与和意见关系到软件产品最终能否有效地满足客户需求。软件开发的目标是向用户交付具有一定价值的产品。为了提高工作效率，你必须在开发人员、开发过程与开发工具之间维持适度的平衡。每个人似乎都有自己最喜欢的开发工具、技巧和开发过程。软件公司把开发工具和方法卖给你，帮助你提高构建软件时的效率。顾问们向你宣讲他们的方法，试图让你相信他们知道如何帮助你的机构和项目团队做得更好。而我们开发人员则不停地学习新的技术、采用新的工具，来帮助我们在更短的时间里以更高的质量完成更多的工作。我们这些作者在各种软件项目中工作和对之进行观察的时间累计起来超过了七十五年。根据这些年中所得到的经验，我们得出一个结论，很可能一些聪明的读者也已经想到了：每一个项目都不一样，那些帮助某个团队取得了巨大成功的方法如果不具有通用性，可能会导致另一个团队的惨痛失败。每个团队都需要确定如何使用一个特定的开发过程，然后不断地进行调整才能取得进步。而在这种不会停止的变化面前，一个项目团队如何知道改变哪些做法可以获得最大的效果？我们的答案是，依靠学习尽可能多的技术，依靠学习有效使用支持不同技术的开发工具，然后确定哪些组合可以工作得最好，以及它们在什么情况下最有效。这也意味着一个不断学习的过程。好的程序员从其他的程序员那里学习。他们通过查看代码和阅读关于不同编程方法的书籍进行学习。测试人员通过学习测试专家的技巧、研究测试设计方案和学习如何使用新技术与新工具来获得提高。实际上，每一个独立的实践者都可以从其他从事相同工作的人那里，或者通过观察范例来学到知识。每个实践者都需要形成自己高效工作的风格，既作为独立的个人也作为一个更大的团队的一员。团队也一样需要利用其他团队如何工作的范例，来形成自己团队协同工作的风格。本书是关于一个小型团队如何开发一个软件工具的例子。它是关于我们做了什么以及为什么这样做的一本大事记。我们尝试着解释了为什么某些做法有效（或者无效），并讨论了下一次我们会改变些什么。在此过程中，我们特别指出了所获得的经验和教训，并提供了一些将这些经验通用化的思路。读者所要做的，就是观察我们所做的工作并汲取我们的经验。如果你正在从事小型的软件开发项目，你将立刻根据我们的经历发现一些问题。你可能已经面临一些我们曾遭遇的问题，并按照自己满意的方式解决了，或者你仍在试图找到合适的解决方法。我们希望本书能够为你提供一些有用思路，帮助你选择和使用合适的开发工具，与他人一起有效地工作，并选择最适合你个人和所在团队风格的技术。本书的所有作者都曾在软件行业的不同类型项目中工作了许多年，从很小的项目到很大的项目都曾涉及。我们对自己的工作都充满热情。我们在为Rational软件公司（现已被IBM公司收购）工作时相互结识。启动此项目的Gary曾经在第一个RationalSuite项目中工作，然后转到RationalUnifiedProcess，即RUP团队工作。Liz和Chris曾和Gary一起在RationalSuite团队中工作，而Jas是RUP团队的成员。我们看到过采用RUP或者其他开发过程并取得成功的项目，我们也看到过同样采用这些开发过程却失败了的项目。我们希望将要讲述的这个项目能取得成功。我们认为自己确实成功了。更重要的是，我们的客户认为我们成功了，这就是我们的故事，希望你能够喜欢它。关于本书在本书中，我们讲述了我们如何作为一个团队一起工作的故事。我们谈及了面对的一些技术障碍以及克服它们的方法。我们描述了遇到的一些模式以及我们如何将它们应用于自己的团队、项目以及代码。我们说明了这个小团队如何发展了一种在成员之间以及与用户之间进行有效交流的方法。我们还讨论了所采用的不同技术和方法，并根据不同的开发方法学，如RUP、极限编程（XP）等等，进行了调整。本书并不包含任何一种特定软件开发技术的全部技术细节。它并没有描述一个开发过程。它并不是关于编写高效的代码、调试方法、测试技巧、需求管理或者过程工程的书。不过本书涉及了所有上述主题。PSPTools项目本书是关于我们开发一个软件项目——PSPTools的经历的大事记。PSPTools的目标是为WattsHumphrey的PSP（PersonalSoftwareProcess，个体软件开发过程）提供自动化的支持。在版本1中，我们为支持PSP等级1实现了计时器和数据收集工具。（关于PSP的更多内容，请参见附录B。）本书包含了屏幕截图、表格以及其他反映我们工作进展的材料片段。为了使读者可以了解我们的实际工作方式，我们据实地展现了自己的经历以及最终的软件，而不是理想化地解释我们希望如何工作。在本书的网站www.awprofessional.com/titles/0321202945，包含了我们的所有代码、其他一些非代码的项目制品、到其他有用网站的链接以及其他后来发生的新闻。我们也很希望能够听到大家的意见，无论是对此书的反映，还是关于你自己的软件开发经历。我们的电子邮件地址是psptools@yahoo.com。本书的组织结构本书的组织结构如下：第1～3章介绍此项目的相关情况。我们介绍了自己进行软件开发的方法；对于在开发人员、开发过程与开发工具之间维持平衡的重要性的观点；及对PSPTools项目的描述。第4、5、6、8、10和11章分别从团队和过程的角度说明了这个项目。我们讨论了RUP的不同阶段以及我们在每一阶段中做了什么。第7章和第9章提供了有关我们所处理的代码和使用的技术的详细情况。这两章并不是对整个应用的全面展示，而是用于体现一些代码的风格并解释我们所做的一些技术决策。我们希望这两章能够鼓励你从本书的网站下载整个项目内容来进行更深入的研究。附录中提供了一些主题的信息，如RUP、PSP和XP，我们假设你对它们已经有一定程度的了解。谁需要阅读此书？如果你是下列人士之一，那么你应该阅读此书：一个正在寻求有关的技术指南，以使得团队整体以及其中的个人都能更有效率工作的项目领导者。书中也讨论了我们所使用的开发工具以及它们的替代产品，还提供了关于如何使用类似RUP之类的开发过程来帮助、促进交流的实践性建议。一个工作于小型项目的独立实践者（一个程序员、一个测试员或者一个分析师）。本书可以帮助你学会如何在不增加无理负担的情况下，与团队中的其他成员进行交流。这里推荐了一些可能会有帮助的工具，并展示了如何有效地应用一种开发过程来指导、帮助你集中注意力，而不是给你增加负担。一个工作于开源项目的独立实践者。本书没有专门讨论开源开发，但确实提供了一些类似于开源项目的经验。它提供了一个如何组织分布于不同地点的团队开展工作的范例。显示了这个团队如何调整其工作风格与使用的开发工具，以适应地理的分隔、完全不同的开发工具以及在相互独立的网络上进行工作。其他对小型项目或者敏捷开发技术感兴趣，并对它们如何与其他开发过程（如RUP）结合感到好奇的独立实践者。致谢如果没有很多人的努力与贡献，本书将不可能得以出版。然而对于文中出现的任何错误，我们将承担相关责任。我们要感谢以下人士，他们的工作使得本书内容更为丰满、有趣和可信。Gary感谢整个开发团队。你们中的每一个人都在整个项目过程中提供了自己的见解、知识、努力与支持。RajSrinivasan在我们急需测试人员的时候加入进来，提供了有所侧重的、有益的问题报告。我要特别感谢PhilippeKruchten和PerKroll，从他们那里我领会了RUP的精神，从而形成了我自己在小型项目中使用RUP的风格。敏捷开发社区中的许多活跃分子教会了我很多事情，我试图将它们包含于我个人的开发过程中。我尤其感谢与BobMartin、RonJeffries和RandyMiller的交流。我确信其他的作者和我一样感谢为本书提供了极有价值的见解的审阅者们。除了PerKroll和PhilippeKruchten，我们很荣幸地请JamesDunion、MagnusLyck？、BobMartin、DanRawsthrone和ChrisSoskin对我们的工作进行了审阅。我们也很感谢来自于Rational软件公司的支持。最后，我们感谢Addison-Wesley出版公司那些过去和现在帮助我们完成本书的人们，他们是：PaulBecker、MaryO’Brien、BrendaMulligan、AmyFleischer、PatrickCash-Peterson，以及我们有才华的、仁慈的编辑RebeccaGreenberg。感谢你们付出的时间和无尽的耐心。Liz非常感谢我的经理KarlHakkarainen，他支持并鼓励我在此项目中进行工作。感谢Gary领导了这一项目，同时感谢其他作者——Chris、Jas和Gary——在完成项目的过程中与他们一起工作非常开心。最后，我还要感谢本书的审阅者们，他们充满理解力的、大量而风趣的评论促使此项目富有成果。Jas真诚地感谢Gary、Liz和Chris，感谢你们的善意、友好、见解与支持。Chris我想感谢与我同一办公室的SteveZerfas。他一直忍受着作为PSP项目一个组成部分的大量会议电话。他也比任何人更多地听我说：“在PSP项目中，我们……”。如果没有我的经理DaveZygadlo的宽宏许可，我将无法在此项目中工作。他即使在“午夜项目”不时地延伸到白天后仍保持着活力。最后，我希望感谢我的妻子Carmen，她对我写程序到深夜或长途旅行去拜访Gary从无怨言，而且始终欢迎Gary在来参加编程讨论时访问我们家。本书不是一本关于RUP、敏捷开发过程或者项目管理的教材，而是一份来源于实际工作的“战地”报告。它记录了一个小型的分布式团队，经历许多变化最终成功地完成任务，向用户交付一个有价值的、可用的软件产品的过程。在本书中，这些“战士们”以直述的方式讲述了他们的故事，没有试图去“执导”有关的内容。我经常听到：“我们不需要采用一个开发过程，因为我们的项目又小又简单。”可能你也有类似的感觉。但是，实际上你总会采用某种开发过程，而且这一过程很可能是临时发明出来的。在我们的行业中有一种普遍存在的印象，就是一个预先描述好的开发过程只适合于大公司、用于大型项目、管理几百个开发人员；而对于小型项目来说，这种开发过程只会使开发人员过得更加痛苦。在本书中，你将会看到一个很小的团队在解决一个中等的项目时，如何按照他们的需要采用和剪裁RUP这样一个描述化的开发过程。他们并没有因为采用这一开发过程而增加过多的正规性。他们只选择了那些对自己有用的要素，甚至采用了类似PSP（PersonalSoftwareProcess，个体软件开发过程）、极限编程（eXtremeProgramming）以及其他一些敏捷开发方法。我也经常听到：“让我看看你到底是如何做的。”成功项目的例子和某些不成功项目的反例常常是导致开始采用一个新开发过程的关键。仅仅埋头于书本中或者网站上，苦读一页页有关某种理想处理方法的描述，对于我们大多数人来说都太抽象了。包装好的、与理论严格匹配的完美示例没有太多的说服力。本书最大的价值在于，它带领读者接触到一个实际项目中的真实经历，包括了其中的失败、错误的开始以及各种限制；而作者以批判的眼光来分析他们所采取的做法，以及这些做法为什么会成功或者失败。我们从自己的经验以及与别人经验的对比中进行学习。“噢，是的，我知道这种模式；我也曾经处于这种境地。啊，你是这样解决的。”本书讨论了在传统的开发过程（包括RUP）中都没有涉及到的问题。作者大胆地探索了关于开发人员、关于形成一个团队的力量、关于分布式环境中的通信联系、关于使用基于Internet的协作工具等方面的内容，而所有这些要素都是当前许多小型开源软件项目的组成部分。最后，本书强调了一个常常在计划中标明了，而在赶着完成任务的过程中通常被遗忘的关键性的实践步骤：自省（self-reflection），有时也被称为事后分析（post-mortem）或者回顾（retrospective）。这一步骤就是暂时停下，回头看看我们做过的、我们是如何做的，看看哪些做法有效，哪些做法无效，以及导致这种结果的原因。而这整本书就是一个非常完整的事后分析的极好例子，坦白而谦虚。本书不能代替你没有做的那些事后分析和回顾，但是可以让你意识到可能错过了哪些东西。那么，哪些人需要使用这本书以及何时需要这本书？可能性有很多：如果你刚接触现代的开发过程，如RUP、敏捷开发方法、PSP等等，那么本书可以让你了解它们的精髓，而不用深入到细节中去。如果你不确定该如何处理小型的分布式项目，你将可以学到极有价值的内容，这些内容的作者也曾经问过自己那些你可能会提出的问题。他们对这些问题曾经做出过选择，这些选择的对与错都通过最终的结果反映了出来。你很可能发现一些熟悉的模式，从书中的解答和解决方案中学会一些东西；这意味着在你自己的项目中犯的错误会更少。如果你是这些方法的专家，那么本书将为你打开新的途径——如何结合不同的方法或者缩减一个开发过程，并告诉你自省的价值。我从这本书中学到了许多关于RUP的知识，并学会了从不同的角度来看待它。感谢Gary、Jas、Liz和Chris与我们分享他们的经验。——PhilippeKruchten于加拿大温哥华
鄂公网安备 42010302001612号 