xp1

如何分析需求，如何记录需求，如何将需求映射为设计，这些永远是需求分析中最为重要的问题。XP提倡以一种简单实用的态度来对待需求，而在软件开发的历史中，需求分析从来都是最需要严谨对待的工作流程。究竟谁是对的？ 故事 每个人都喜欢听故事，这也许是从小就养成的习惯。如果能够把需求分析工作变成听故事的过程，那该有多好。需求分析人员写出一个个优美的故事，开发人员边看故事，边实现故事。也许这就是XP的设计思路所在。用户故事，XP把需求变成了一个个故事，摒弃了枯燥无味的需求稳定。文档的作用是传递信息，如果失去这个意义，再优秀的文档也没有任何用处。但是，完整细致、厚达数十页的需求文档是否真的能够达到沟通的目标呢？对于大多数而言，恐怕看到文档的厚度就已经心生惧意了吧。好吧，我们通过很多的辅助手段，可以强制要求开发人员都投入大量的精力来研究、学习复杂的需求文档。但是这厚厚的需求文档真的能够完整的记录所有的需求吗？更糟糕的是，需求是会发生变化的，到时候如何维护这份需求文档呢？回想精益原则，我们可以判定，这种处理需求的方式一定会产生大量的浪费。将需求做的尽善尽美需要成本，项目组的人员熟悉需求需要成本，维护文档需求成本，解决不一致的问题也需要成本。那么，我们可以针对这几点做一个分析： 需求的文档是否要尽善尽美？需求文档的最大目标是将信息从业务人员传递给开发人员（当然也会存在其它的目的，例如作为合同的组成部分）。那么，文档是否完美和能否实现沟通效果并没有直接的关系。 开发人员怎么才能够快速理解需求？文档的制作融入了制作者的思想，因此他人理解总是需要一定的时间的。解决问题的思路有两个：一是提供标准通用的做法；二是简化文档，简单的东西总是要容易理解，但简单的东西并不等同于制作容易。 维护文档需要成本。不管如何，维护成本始终是无法避免的，关键在于，能否降低这部分的成本呢？维护成本和文档数量、复杂度成正比，因此文档的数量要尽可能的少、复杂度要降低。此外，减少维护的次数也是关键的因素之一，在讨论精益原则的时候我们说尽可能推迟决策就是这个意思。 针对以上的几点，XP提出了自己的实现思路－用户故事。用户故事简单，每个人都会写，每个人也都能理解，改变起来也很容易。但用户故事只是对系统功能的一个简单的描述，他并不能提供所有的需求内容，因此，在XP中，用户故事的实践需要现场客户的支持。用户故事之所以简单，是因为它只是开发人员和客户之间的一种契约，更详细的信息需要通过现场客户来获得支持。 活用 XP：(五)测试管理 无论从那一点上来看，要保证软件的质量，测试工作是少不了的。而测试往往又是经常被忽略的。对于敏捷方法，精益编程而言，如何保证测试的有效性？如何减小测试的成本？是测试中首要考虑的两个问题。 测试过程 要做好测试可不是一件容易的事情。测试工作和软件开发密切相关，却又自成体系。测试并不是一个单独的阶段或活动，测试本身就是一个过程，具有自己的生命周期，从测试计划开始，到测试用例的制定，测试的结构设计，测试代码的编写。测试的生命周期和软件开发生命周期拧在一起，相互影响。当然，我们还是那句老话，罗马不是一天建成的。对我们来说，还是从简单的开始。 在我们谈及精益编程理论的时候，曾经讨论过全面质量管理的概念：生产过程的每一个环节都需要为质量负责，而不是把质量问题留给最后的质检员。这对于软件开发有着很好的借鉴。软件开发中最头疼的就是质量问题，因为人的行为过于不确定了。在经过漫长的软件开发周期之后，软件渐渐成型，但是缺陷也慢慢增多，试图在最后的关头解决长期积累的问题并不是一个好的做法。软件开发到了这种时候，发现和修改缺陷需要付出很大的代价。 我们说，最后关头的测试并不是不重要，但是，软件质量问题应该在整个软件过程中予以重视。 测试的最小单位 测试问题的很重要的思路在于测试的管理上，如何管理一个项目中所有的测试，以及它们相关的文档，相关的代码，如何定义测试人员的职责，如何协调测试人员和开发人员之间的关系？ XP的测试优先和自动化测试实践是一个非常优秀的实践，我们也曾不止一次的提到该实践，但是对XP强调的单元测试，很多人都有一些误解： XP中提供的例子过于简单，无法和生产环境相结合。XP中的单元测试只是为测试提供了一个具体的操作思路，但是它并不能取代其它的测试原理。如何进行测试，如何组织测试，如何管理测试，这些都要由不同的软件组织自己来进行定义。 测试代码本身不能够适应变化。黑盒测试的理想状况是外部行为不因为内部行为的改变而改变。当需求或是设计发生变化的时候，一段代码的内部行为需要改变，但是外部行为却不需要变化，这样，针对外部接口进行的单元测试同样不需要改变，但是这个规则一旦被违反，我们就需要付出同时改变测试代码的双重代价了。因此，测试代码的设计本身就是很讲究的。 单元测试（有时候也称为类测试）是代码级别的测试，是测试的最小单位。XP非常看重这个最小单位。我们观察测试优先框架XUnit，发现它使用组合模式将大量的最小单位的单元测试组织起来，形成完整的测试网。所以，XP的思路非常的简单：最小单位的测试能够做好，全系统的测试就能够做好。这个思路未必就正确，但是注重最小单位的测试的思路是绝对正确的。每个部件都正确，最后的软件未必正确，但任何一个部件不正确，最后的软件一定是不正确的。 活用 XP：(六)强化沟通 结对编程是本系列文章讨论的最后一个主题，也是备受争议的一个主题。为什么一个人的工作要两个人来完成，这对于老板来说简直就是犯罪。和前面的主题类似的，我们要学习和应用一项实践，关键的还是要把握其实质。 沟通为王 沟通问题是一个项目成功最重要的因素之一。一个项目可能并没有什么正式的软件过程，但是只要团队成员能够进行有效的沟通，项目成功的可能性就很大，但是如果项目中缺乏有效的沟通渠道，再优秀，再严谨的软件过程也没有用。优秀的软件方法学，总是会在沟通渠道的建立，推动有效沟通上花费大量的精力。我们分析RUP、XP等方法学，都会看到很多这样的实践。沟通对一个项目而言是重要的，砸桓鋈砑橹跃透匾恕４映て诶纯矗诓磕芄唤杏行Ч低ǖ淖橹芄坏玫胶芎玫姆⒄梗欠垂矗诓抗低ú怀┑淖橹岢鱿趾芏嗟奈侍狻? 在软件开发过程存在的一个很大的问题就是沟通不畅的问题。事实上，这个问题并不仅仅在一个开发过程中存在，在整个软件组织内都将长期的存在，并成为阻碍软件组织发展的一大障碍。这样的说法可能过于理论化，但是我们只要想想，如果现在的项目中，一个主力程序员离开的话，是否会给项目，甚至组织带来重大的影响，就能够理解这段话的含义了。造成这种现象的主要问题是程序是分散在各个程序员手中的。各个代码块就像是程序员们的私有财产一样，神圣不可侵犯。 更为糟糕的是，任何一个程序员都不愿意阅读他人的代码，比起理解别人的代码，程序员们宁可自己重新编写代码，这导致另一个严重的问题――软件组织中大部分的工作都是重复的，以至于程序员天天忙于开发代码，却难以把精力放在更有价值的地方（关于什么是更有价值的地方，我们在下文会详细的描述）。 在一些项目中，我们经常看到这样一种开发环境：每个程序员都拥有个人的隔离空间，彼此之间不进行交流，甚至有时候他们整天不说一句话。在和项目中的一位主力程序员进行沟通之后，我们发现了他们的真实想法： 项目非常紧张，团队成员之间的关系非常的微妙，主力程序员必须要保持自己的主力地位，对他们来说，必须努力写出优秀的代码，同时，你还需要承担项目进度的压力，并提防着其它的程序员。将程序掌握在手中是自己安全感的来源。压力如此之大，他们不得不每天工作12个小时以上。程序开发就如同噩梦一样。 虽然未必所有的团队都如此不良的开发人文环境，但是或多或少都存在一些不好的环境因素。可以肯定的说，没有多少人愿意在这样一个开发环境中工作。这些环境因素都影响了沟通问题的形成。 XP的四大价值观中的一项就是沟通。XP中的沟通范围很广，有开发人员和客户之间的沟通（我们在需求和故事一章中也提到了沟通问题），有程序员和设计师之间的沟通，有程序员和测试人员之间的沟通。但是本文的重点集中在开发团队内部，即，如何改进开发团队内部的沟通质量。 改进沟通的实践－结对编程 XP方法论非常强调营造一种轻松的开发氛围，重视人的价值胜于重视过程。沟通是XP的一大价值观。XP中大量的实践是围绕沟通这个价值观设计的。例如，用户故事，现场客户，代码集体所有权等等，但是我们这里要强调的，是结对编程这一实践。本文中不对结对编程做介绍，这方面的资料有很多，没有必要在这里浪费笔墨。本文要讨论的，是我们如何在项目的角度上考虑结对编程。 结对编程是一种非常有效的改善沟通的方法。一对编程人员是协作过程中最基本的沟通单元。在经典的XP方法中，结对编程指的是两个程序员在同一时间、同一机器前，主动的共同的解决统一问题。也许经理们听到这句话的第一个反应就是："这不可能，我花了两倍的钱，却只做一个人的事情！"事实上，结对编程运用得当的话，是能够提高工作效率的，不但体现在进度上，还体现在代码质量、以及项目风险上。