Extreme Programming介绍

Extreme Programming介绍

计划

 User stories的编写

 开发计划的制定

 经常构造版本

 Load Factor因子的确定

 将项目分解为各个迭代期

 每个迭代期开始时制定计划

 人员集中

 站着开每日晨会

 当实施遇到困难时及时修正XP

设计

 简单化.

 采用编程规范

 设计时使用CRC卡片

 使用Spike Solution 方法

 不要过早添加新功能

 尽可能保持程序的简洁性

编码

 始终获得用户的支持

 代码的书写必须按照规范

 所有代码均采用配对开发

 一次只能有一对开发人员进行Release

 代码经常集成

 代码共享

 将优化放在最后

 不要加班

测试

 所有代码均需进行单元测试

 在Release之前所有代码必须通过单元测试

 Bug发现后应马上测试

计 划

l         User stories的编写

l         制定开发计划

l         经常构造版本

l         Load Factor因子的确定

l         将项目分解为各个迭代期

l         每个迭代期开始时制定计划

l         人员集中

l         站着开每日晨会

l         当实施遇到困难时及时修正XP

 

User Stories

User stories与use case类似，它主要是在Plan Game过程中对时间以及开发风险进行评估。此外它还用于代替传统开发中所写得大量的需求文档。User stories是由用户来写的，在其中要写出所有需要系统完成的功能，在此也可以描述用户界面。User stories必须采用用户的术语来写，而不能采用任何技术术语。后期的功能测试也是信赖于此，并由此判定功能是否完成，是否正确。User stories必须足够的详细，这样才能对开发工作量有一个比较准确的评估。一个User stories应对应1至3周的工作量，如果超过3周就应当将其继续细分。一个典型的项目一般由80+/-20个User stories构成。User stories的另一个特点就是它是面对用户的，因此在其中不应包含任何有关技术、数据库以及算法在内的术语。我们应当将精力放在用户的需要以及GUI方面。

Planning Game

通过Planning Game阶段，我们可以对整个项目制定一个开发计划表，并且以后还要依靠此计划表制定出每个迭代期的开发表。它应当是技术人员以及市场人员共同协商的结果。Planning Game的主要工作是评估每个User stories所需的工作量（以理想情况下的工作日为单位）、风险以及优先级。具体执行时，首先将所有的User Stories打印出来或者是写在卡片上，然后将其放在一起，由用户以及开发人员一起对它们进行优先级划分，确定实现的先后顺序，最终的结果是：尽早提供一个有用的、可测试的并且在商业上有意义的早期版本。此外最好能在前期就将高风险的功能加以实现。Load factor在此用于判断实现User stories需要多少时间，以及在指定的日期之前我们可以完成那些内容。Load Factor是基于理想的工作日而定的。

经常构造版本

在Planning Game阶段，我们发现了那些从商为角度上看有意义的功能，在实现过程中应尽可能早地实现这些功能，也就是说要经常构造版本，并及时地将有关版本其交付给用户试用。采用这种方式的好处在于，我们可以及时从用户处获得有用的反馈信息，否则等到开发的后期才获得这些信息，此时留给我们进行改动的时间也不多了。

Load Factor

Load Factor用于度量项目的开发速度。Load Factor相当于在理想状态下完成一个任务所需花费的工作时间。一开始时我们并不能确切地知道Load Factor是多少，通常可以设置为2或者3，但在以后的开发过程中可以不断对其进行修正。如果在开发中发现Load Factor与最初所设置的值有较大的差别，那我们就需要对Planning Game进行相应的调整了。在项目进入维护阶段以后，同样需要对Load Factor进行调整。

迭代开发

迭代开发为开发过程增添了灵活性，一般来说，应将整个项目划分为若干个不超过两到三周的迭代期。注意：不要过早制定开发计划，而应在每个迭代期开始时通过计划会议制定本迭代期的开发计划。此外不要提前实现任何不在本迭代期计划中的功能！只有这样才能保证对变化的需求的及时响应。

迭代期开发计划的制定

在每个迭代期开始时才制定相应的开发计划。一般迭代期的长度应控制在一到四周之内，计划的制定是依前期Planning Game中为每个迭代期所选择的User Stories而定的。 User Stories以及测试中出错的问题在此均转换为开发任务，并被写在卡片上。任务一定要填写的足够详细以便为本迭代期制定计划。每个任务应能在一至三个理想的工作日中加以完成。开发人员分配到任务后再根据自身的情况加以估计需要多长时间才能完成。Load Factor在此用于评估本迭代期的开发工作量是否过多或过少。最终的开发时间的估计等于理想开发时间再乘以Load Factor。如果工作量过大，则应减少此周期中所需完成的User Stories。如果User Stories的完成进度慢了下来，那就要注意了。通过是将难的任务放在前期，容易的放在后期，这样就可以保证开发速度越来越快。

在此应注意以下几点：不要添加额外的灵活性，除非现在必须这样做；不要添加新功能，除非其已列在计划中，否则会减缓开发进度；注意Load Factories的变化，以便及时改进开发计划。

人员集中

将开发人员集中起来，这样可以避免有关信息的丢失以及开发的瓶颈。配对开发一方面可以提高开发质量，另一方面可以防止由于人员流失造成开发进度受阻。

站着开每日晨会

每天早上大家站在一起开个会，以便相互讨论所遇到的问题，解决方案，确定团队的工作重点。所有人均站着并围成一个圆圈以避免长时间的行讨论，而且可以增加大家对讨论内容的重视。

通常开会时我们的大部分精力并没有放在会议主题上，大量的开发时间浪费在很多琐碎的小事上。同时由于项目成员参加了过多的此类会议，损失了大量的项目资源，从而造成了开发进度的失控。由于参加人员不多，大部分此类会议可以直接在计算机前开，所以可以在讨论中直接浏览代码并对新的想法加以验证。

当实施遇到困难时及时修正XP

    当实施遇到困难时及时修正XP。在制定XP时不可能考虑到每个项目的特殊情况，所以在实施XP时也不要想象着它可以满足你的项目的所有需求，或者是它可以不加修改地直接在你所在的环境中执行。在实施过程中应及时开会讨论那些内容是有效的，那些是没有效果的，并不断对XP加以修正以提高项目组的开发水平。

设 计

l         简单化

l         Choose a system metaphor

l         在设计中使用CRC卡片

l         Create spike solutions to reduce risk

l         不要过早添加新功能

l         尽可能保持程序的简洁性

简单化是关键

    通过将复杂的设计简单化将会节省大量的时间。因此如果你发现某些复杂的设计可以采用简单的方法加以实现时，采用简单的方式。记住：尽可能采用简单的方法，尽可能长时间的采用简单的方法，如果没有将其包含在计划中一定不要提早实现新功能。但同时应注意：保持设计的简单化是一个并不轻松的工作。

采用编程规范

系统中变量、类以及方法的命名均应采用约定的规则。统一的命名对了解他人的设计以及代码的重用均是十分重要的。

CRC卡片

使用“类、职责、协作”（CRC）卡版进行系统设计。采用CRC的一个好处在于它可以使你自然地采用面向对象的方法加以思考问题，另外它还可以让更多的人加入到系统的设计过程中，从而使设计更加合理与健壮。

    一个的CRC卡片代表一个独立对象的实例。在卡片的上边记录有类的名称，在卡的左边列出了此类所要实现的功能，在卡的右边列出了与此类相关的其它类的名称。通过将所有的CRC卡放在一起，不同的人负责一个或几个CRC卡，大家一起协同工作以模似当前所设计的软件最终动态的运行情况：哪个类发出一个消息，哪个类接收到这个消息并执行某一特定的动作…。采用上述“走读”方式，我们可以方便地发现设计中的问题。总得来看，此处的CRC方法与在ROSE中采用Class Diagram是相同的。如果发现有过多的人同时在移动/谈话，则可以限制一次站起并移动卡片的人的总数。只有当一个人坐下后才能允许其它人站起来。

采用CRC卡的一个不利之处在于它缺乏设计文档。当然也可以将所有卡中的内容保存在一个文档之中。

使用Spike Solution 方法

为了解决一个技术或者设计上的问题，我们可以采用“Spike Solution”方式（类似于我们常说的“技术原型”）。此方法只关心所要解决的问题本身，而不关心其它内容。大部分的“Spike Solution”是一个粗糙的不能再用的程序，一般试验完成后就不再用了。使用这种方法的目的是减少技术问题的风险，并且可以提高我们对User Stories评估的准确性。

不要过早添加新功能

保持产品功能的单一性，不要添加你认为以后可能会用到的代码。只有10%的多余代码会在以后用到，因此过早加入多余的代码会导致你浪费90%的时间。多余的代码及功能还将降低开发速度并浪费开发资源。所以只做计划中要做的事情。

保持程序的简洁性

很多时候，当程序的结构已被改的支离破碎，或者程序代码已被改的面目全非时，我们仍试图将其维持下去。但这一些均不会发生在XP中。在XP中，一旦发现上述情况就会将原有的结构/代码推翻重新进行设计/编码。虽然看起来这样的花费比维持原有状况代价更大，但从长远的角度来看将会节省更多的人力资源。不论在程序开发中哪一个阶段，如果发现程序中存在冗余的代码、无用的函数以及过时的设计，删掉它们！这在XP中被称为“Refactor”。

通过Refactor可以避免程序的冗余以及复杂化，使之尽量简化。只有这样才能保证代码容易为他人理解、修改以及扩充。不要等到系统已混乱不堪时再花时间去解决问题。

编 码

l         始终获得用户的支持

l         代码的编写必须符合规范

l         所有代码均应采用配对编程方式加以开发

l         一次只能有一对开发人员进行Release

l         经常集成

l         代码共享

l         将优化放在最后进行

l         不要加班

始终获得用户的支持

在XP开发中有一条原则是：始终保持与用户的联系。用户不但可以帮忙开发团队，而且是开发团队的一部分。在XP的各个阶段中均需要与用户的交流，最好是坐在一起面对面的交流。如果可能的话，最好在开发团队中分配一至多名用户。需要注意的一点是：在此我们需要的是用户中的专家，而不是新手。

User Stories是由用户在开发人员的帮助下编写的，并且用户需要帮助确保系统所需的功能均已涵盖在User Stories中。

计划阶段，用户帮助开发人员为每个迭代期选择需实现的User Stories，确定每个开发周期的长短。如果有商业目标的改动，应由用户做出最终的决定。迭代期确定的最终原则是让用户尽早拿到一个可用的早期版本。

编程规范

    编码时一定要遵守编程规范，以使代码具有可读性，易于为项目组中其它人员所理解。

配对编程

    所有的代码均应在采用配对编码方式下产生，即由两个开发人员共同编写。配对编程在不影响开发周期的前提下提高了软件的质量（多用15%的时间，但提高软件质量23%）。

按顺序Release代码

     因为并行开发的原因，所以同一时刻可能有多对开发人员在对代码进行Release，由于大家均没有将自已的当前改动放到服务器中，所以在这种情效况下进行的Release并不能保证最终所有代码全部更新后再次Release的正确性。为此应当规定：同一时刻只能有一对开发人员在进行Release，当其保证有关代码正确并更新至服务器后才允许其它开发人员对其私有代码进行Release。

经常集成

为了提早发现问题，尽可能地经常地进行代码集成，最好不要超过一天。通过代码集成可以发现不同部分之间的配合问题，如果集成的周期过长，将会导致修改成本的上升。并且通过经常集成代码，可以保证当前服务器上始终有一个可用的版本。另外，采用此方法，还可以更好地实现代码的重用。

代码共享

    确保项目组中的每个人均能看到所有的代码，并且为了修改BUG可以对每个源代码文件进行修改。这样可以避免由于某个人的缺席造成开发中的瓶颈。此外应让所有开发人员对程序的整体结构有一个清晰的认识，而不要将有关知识只掌握在一两个人头脑中。

最后做优化

只在开发的后期才进行优化。不要在开发的过程中想当然地认为何处是瓶颈，只有实际测试之后才能发现真正的瓶劲。首行保证代码能工作，然后保证工作正确，最后再想办法提高运行速度（Make it work, make it right, then make it fast）。

不要加班

    不要加班，这样会榨干开发人员的精力并减弱开发积极性。如果是为了保证按时完成计划而加班的话，那么最终无论你怎么做，均无法实现这个目标。正确的做法是：减少软件所要实现的功能或者延长开发时间。在开发进度延后的情况下增加开发人员同样也是不可取的。

测 试

l         所有的代码必面做单元测试

l         版本发放之前所有代码必须通过单元测试

l         发现一个BUG后就要为其创建一个测试用例

单元测试

单元测试是XP开发方法中的基石。与其它的单元测试方法有所不同，XP中的单元测试具有以下特点：首先你需要创建或者下载（从www.XProgramming.com中下载）一个单元测试框架以便实现自动化的单元测试；第二点，必须测试所有的类（可以利用VC中的Profile功能进行代码的覆盖性测试）；最后，在编写代码之前就必须先考虑有关测试的内容。

在编码之前就考虑测试可以使开发人员对需求具有更好的理解，对程序结构会有更好的把握，并且在代码开发完后马上就可以进行测试，及时获得有用的反馈信息。没有经过.测试的代码是不允许被包括在Release版本中。

只有当所有的代码均进行并且通过了单元测试之后，才能Release一个新版本。

针对每个User Stories应创建相应的功能测试。功能测试属于黑盒测试，由用户来判断测试结果是否正确，并且它的执行必须在Release之前。测试时最好有自动测试工具。

一旦发现一个BUG，立即为其创建一个相应的测试用例，以防止以后再次出现此类问题。

Extreme Programming总结

XP的主要特点

       是一个轻量级的软件开发过程

最大限度地满足用户的需求

       强调团队的协作

       强调项目管理（基于评估以及制定计划）

       将有限的时间投入到真正的开发中（抛弃不必要的会议、文档以及评审）

       见效快

XP适用对象

    是一个轻量级的开发过程

适用于2 – 10人，3个月 – 1年的小型项目

适用于需求经常变更以及高风险的项目

XP在实施中的四个主要特点

       沟通、简单化、反馈、勇气 (Communication, Simplicity, Feedback, and Courage.)

Communication takes place between people, documents are secondary.

XP与RUP的关系

       是RUP的最小实现集（A minimal RUP process）

又被称之为dX （Object Oriented Analysis and Design with Application, 3th）

       dX在表述上采用了RUP的表述形式

XP实施中的注意事项

       以体系结构为中心 （architecture-based）（has a very strong architecture focus）

       以用户需求驱动 （requirement-driven）

       强调软件的良好的内部结构

       并不排斥分析及设计（包含在代码中，没有多余的外部文档）

如何开发实施XP

可以从一个全新的项目开始

可以针对正在进行的项目开始

可以全部采用XP的方法

可以只采用部分XP的方法

参考资料

       www.extremeprogramming.org

       www.XProgramming.com

       www.objectmentor.com

       《Design Patterns》

       《Software Architecture》

XP工作流程图