敏捷开发(含极限编程xp

2014-03-19 19:28:06 happylee6688 阅读数 8620
上篇文章,我们探讨了什么是敏捷开发,以及敏捷开发的方法学。在这篇文章中,我们将继续讨论敏捷开发中的问题——XP极限编程。

在讨论之前,先让我们来了解一下XP极限编程产生的背景,软件业所具有的共同的问题。

背景

  • 软件越来越复杂
  • 需求越来越多变
  • 过程越来越规范
了解了背景之后,那么就会想问,到底什么是极限编程呢?下面我们就做一个简单的介绍。

XP概述


极限编程(eXtreme Programming),是一种全新的、轻量级的、灵巧的软件开发方法,是一种软件工程方法学。它强调程序设计团队与业务专家之间的紧密协作、面对面的沟通(比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法,更注重软件开发中人的作用。

核心价值观

  • 沟通(Communication)

     问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。XP认为项目成员之间的沟通是项目成功的关键,并把沟通看作项目中间协调与合作的主要推动因素。因此,项目相关人员之间进行充分、多渠道(最好面对面)的沟通是很有必要的。

  • 简单(Simplicity)

     XP假定未来不能可靠地预测,在现在考虑它从经济上是不明智的,所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。 在系统可运转的前提下,做最简洁的工作,坚定的专注于最小化解决方案;在开发中不断的优化设计,时刻保持代码简洁、无冗余。需求尽量的简单,设计尽量的简单,代码尽量的简单,文档尽量的简单。

  • 反馈(Feedback)

     尽快获得用户的反馈,并且越详细越好,使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈:小交付、短迭代、测试先行等。XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。

  • 勇气(Courage)

     这是最重要的核心价值。因为XP强调要“拥抱变化”,因此对于用户的反馈,提倡积极面对现实和修改问题的勇气,如放弃已有代码,改进系统设计等;勇敢的重构;所有人拥有代码;敢于极限(把好的方法做到极致)。XP认为,软件开发中,人是最重要的一个方面。在一个软件产品的开发中,人的参与贯穿其整个生命周期,是人的勇气来排除困境,让团队把局部的最优抛之脑后,达到更重大的目标。

12个实践原则

  • 规划策略(Planning Game)

     以业务优先级和技术估计为基础,决定下一版本发布的范围。


  • 结对编程(Pair Programming)

     结对编程是一种编程模式。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试用例,一起编码,一起单元测试,一起整合测试(Integration Test),一起写文档等。基本上所有的开发环节都一齐肩并肩地,平等地,互补地进行开发工作。

     结对编程是让两个人共同设计和开发代码的实践。结对者是全职合作者,轮流执行键入和监视;这提供了持续的设计和代码评审。不是两个人做一个人的事情。 

  • 测试(Testing)

     测试驱动开发,是指在编码开始之前,首先将测试写好,而后再进行编码,直至所有的测试都得以通过。即所谓的先测试,再编码;代码未动,测试先行。 通常包括,Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test等。

  • 重构(Refactoring)

     重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改,以改进代码的内部结构。重构是一种有纪律的、经过训练的、有条不紊的代码整理方法,可以将整理过程中不小心引入错误的可能性降到最低。改进软件的设计,Refactoring帮助重新组织代码,重新清晰地体现结构和进一步改进设计。

  • 简单设计(Simple Design)

     系统应设计得尽可能简单。

  • 代码集体所有权(Collective Code Ownership)

     代码集体所有权强调的是整个团队,而非个人,即“我们”的代码,而不是“我”的代码。 团队中的任何人都可以改动任何一段代码,但改动后的代码必须通过所有相关的测试。

  • 持续集成(Continuous Integration)

     持续集成的思想是任何时候只有一项任务完成,就集成新代码,构造系统并测试。持续集成是每日构建\每晚构建的一种极限形式,是XP的重要基础。

     测试先行是持续集成的一个重要前提。持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合,越频繁越好;集成及测试过程的自动化程度越高越好。每次只有一个PAIR在整合,而且必须运行功能测试。

     需注意,持续集成需要良好的软件配置变更管理工具的有效支持。 
 


  • 现场客户(On-site Customer)

     客户是Team成员,在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求,运行验收测试,接收发布的系统。

  • 小型发布(Small Release)

     发布过程应该尽可能地自动化、规范化。不断地发布可用的系统可以告诉客户你在做正确的事情。客户使用发布的系统,可以保证频繁地反馈和交流。保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。降低开发风险。随着开发的推进,发布越来越频繁。所有的发布都要经过功能测试。 

  • 每周40小时工作制(40-Hour Work)

    “不加班,不熬夜”。XP要求项目团队人员每周工作时间不能超过40小时,加班不得连续超过两周,否则反而会影响生产率。

  • 编码规范(Code Standards)

     XP 强调通过指定严格的代码规范来进行沟通,尽可能减少不必要的文档。类型包括:格式、代码结构、命名约定、错误处理、注释等。 

  • 系统隐喻(System Metaphor)

     XP通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。

开发过程


用户代表提出用户故事,项目组据此进行讨论、提出隐喻,在此活动中有可能要进行系统结构的Spike。在隐喻和用户故事的基础上,根据用户设定的优先级制订交付计划,然后开始多个迭代过程,在迭代期内产生的新用户故事不在本迭代内解决,以保证开发不受干扰。经验收测试通过后交付使用。



适用范围


XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的 代价来满足用户未来的需求,XP在平衡短期和长期利益之间做了巧妙的选择。

结束语


XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。XP的思想启发我们如何学习和对待快速变化、多样的开发技术。

2017-09-12 22:23:22 Suirenka 阅读数 657

1.敏捷过程

目的:为了使软件开发团队具有高效工作和快速响应变化的能力。

4个价值观宣言:

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划


2.极限编程(eXtreme Programming ,XP)

Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。


2012-06-28 01:30:51 yangzhenping 阅读数 3911
Agile Modeling and eXtreme Programming (XP)
敏捷建模和极限编程(XP)



Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner.  On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software projects taking an agile approach such as eXtreme Programming (XP),  Dynamic Systems Development Method (DSDM), and Scrum to name a few.  Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored.  Furthermore, although XP clearly includes modeling as part of its process it is not as explicit about how to do so as many developers would prefer.  Hence an opportunity for AM.  Luckily XP, like AM, is also an agile practices-based methodology which makes the conceptual fit between the two methods much easier than between AM and a process such as the Rational Unified Process (RUP) the topic of the article Agile Modeling and the Unified Process.  

敏捷建模(AM)是一个实践为基础的软件过程,其范围是描述如何以一个有效和灵活的方式建模和建立文档,在AM主页,我指定AM的目标之一是如何应用软件工程建模技术,如敏捷方法解决的问题,比如极限编程(XP),动态系统开发方法(DSDM),和Scrum等等。因为XP的范围远远比AM大,XP涵盖整个开发生命周期,它是一个候选的AM技术,可定制的“基过程”。此外,虽然XP显然包括建模过程的一部分,但是许多开发人员宁愿不清楚它是如何做到这一点。因此有机会给AM。幸运的是XPAM一样,也是一个灵活的实践为基础的方法,这使得适合之间的两种方法比之间时要容易得多,如统一软件开发过程(RUP)的文章敏捷建模与统一过程的主题。


Table of Contents
目录


Setting the record straight
弄清真相
XP and AM?  
XP和AM?
AM throughout the XP lifecycle 
AM贯穿整个XP的生命周期 
How do you make this work?  
你如何做这项工作?


1. Setting The Record Straight
1。弄清真相

There are several common misconceptions that people seem to have regarding modeling on an XP project.  The three most common misconceptions are that you don’t model on an XP project, that you don’t document on an XP project, or that if you do model your only options are the modeling artifacts of the UML.  I’ll address these misconceptions in turn in this section, but first I want to explore why they occur so that you can recognize other misconceptions when they arise.  From what I can gather based on the conversations on the AM mailing list the source of these misconceptions is often the result of one or more of the following:

有几个常见的误解,人们似乎已经对一个XP项目的建模。 3种最常见的误解是,你没有建模在一个XP的项目上,你不记录在一个XP项目上,或者说,如果你做模型的唯一的选择是UML的建模构件。我会在本节轮流来处理这些误解,但首先我想探讨他们为什么会发生的,以便在他们出现时你可以认出其他误解。从我收集的基础上在AM的谈话邮件列表列出这些误解的根源往往是一个或多个以下的结果:

Second-hand knowledge of XP.  The Internet is a major source of information for many developers, in particular newsgroups and emails from colleagues.  As people learn a new technique they often join a newsgroup or mailing list, such as the extremeprogramming list, and start monitoring the group/list.  Someone will post something, which may not be accurate, and many people will accept it as official, particularly when they haven’t had an opportunity yet to try it out for themselves.  Don’t believe everything that you hear.  
XP过时的知识。互联网是一个许多开发人员信息的主要来源信息,特别是同事的新闻组和电子邮件。随着人们学习一门新的技术,他们往往加入新闻组或邮件列表,如extremeprogramming极限编程列表,并开始监测组或者列表。有人会发表某些东西,这可能是不准确的,很多人会接受它作为官方的,特别是当他们已经没有机会为自己尝试。不要相信你听到的一切。

Questionable sources of information regarding XP.  It’s often hard to determine the quality of published material, be it electronic or printed form.  Sometimes honest mistakes are made, that’s happened to me more than once, and sometimes people publish misleading information on purpose.  When you’re just learning a new subject you often cannot distinguish between high-quality sources of information and questionable ones.  If you base your understanding on questionable sources it is very easy to get the wrong idea about XP. 
关于XP中的可疑信息来源。这往往很难确定公布的材料的质量,无论是电子或印刷形式。有时候,诚实的错误,这是发生在我身上不止一次,有时人故意发布误导性信息。当你刚开始学习一个新的课题,你往往不能区分高品质的信息来源和可疑的信息来源。如果你根据你对问题的来源的理解,这是很容易得到关于XP的错误观念。

Difficulty seeing beyond their current environment.  Many developers find themselves in less-than-ideal environments.  XP requires you to adopt practices that are often foreign to your current environment, pair programming and test-first development are new to most organizations, and sometimes these practices simply aren’t feasible to adopt.  If you cannot adopt the practice of pair programming then XP isn’t going to work for you, but instead of proclaiming that XP doesn’t work in their environment many people will instead proclaim that XP doesn’t work at all.  The reality is that XP does in fact work in the right situations, it is just that your situation may not be one of the right ones.
很难看出超出他们当前的环境下。许多开发人员发现自己在低于理想的环境。XP需要您采取的做法,往往是在当前的环境之外,对结对编程和测试优先开发的大部分组织是新的,有时这些做法根本是不可行的采用。如果你不能通过结对编程的实践,然后XP是不会为你工作,但很多人宣布XP根本不能用,而不是宣布XP并不在他们的环境中工作。现实的情况是,XP的确能工作在合适的情况下,事实上,这仅是您的具体情况可能并非正确做法中的一种。

Too much focus on the word “extreme”.  XP’s name is both one of its greatest strengths its greatest weaknesses.  Because of the name when some people hear XP’s advice to travel light, to reduce the amount of documentation that you create and maintain, that they instead translate it to “create no documentation at all”.  That’s extreme, right?  Or they’ll hear XP’s advice to use simple modeling techniques such as user stories and CRC cards and somehow translate that advice to “you don’t model at all.”  That’s extreme, right?  Sigh.
过多集中于“极限”的字。 XP的名字,既是其最大的优点,亦是其最大的弱点之一。因为当一些人听到XP的意见来轻装上阵,以减少您所创建和维护的文档的数量,,他们反而把它翻译为“根本不用创建文档”。这就是极限,对吗?或者他们会听到XP的意见去一些简单的建模技术,比如用户故事和CRC卡(注:Class类别, Responsibility责任, Collaborator辅助者),或者换种方式说“你根本不必建模”这就是极限,对吗?哎.

In this section I will set the record straight regarding the three most common issues concerning modeling and XP:
在本节中,我将弄清楚最常见的三种关系建模和XP的问题:

  Modeling is Part of XP  
  建模是XP的一部分
  Documentation happens 
  建立文档的发生
  XP and the UML?
  极限编程和统一建模语言?


1.1 Modeling is Part of XP
1.1 建模是XP的一部分

User stories are a fundamental aspect of XP and artifacts such as Class Responsibility Collaborator (CRC) cards are common to XP efforts.  User stories provide a high-level overview of the requirements for a system -- they are reminders to have a conversation with your project stakeholders regarding their requirements -- and are used to as a primary input into estimating and scheduling, and drive the development of acceptance test cases.   CRC cards are used to explore structure, perhaps for conceptual modeling to understand the problem domain or for design to work through the structure of your software.  User stories and CRC cards are both models, see the Artifacts for AM article, so therefore modeling is clearly a part of XP.  XP developers will also create sketches, often on a whiteboard or a piece of paper, whenever user stories and CRC cards aren’t the best option.  In Extreme Programming Explained, the first book written about XP, Kent Beck includes hand-drawn sketches of class diagrams and other free-form diagrams.  In fact, in the second edition he includes a mind map in the inside cover overviewing XP. The bottom line is that modeling is a fundamental aspect of XP, something that I explore in detail in this article.
用户故事是XP和加工品的基本方面,如类责任合作者(CRC)卡对XP的努力来说是很普遍的。用户故事为一个系统需求提供了高层次的概述 - 他们有一个与您的项目利益相关者对他们的要求谈话提醒 - 被用来作为主要输入到估计和调度,并推动发展验收测试用例。 CRC卡是用来探讨结构,也许是为概念建模的理解问题域,或通过你的软件的结构来设计工作。用户故事和CRC卡都是模型,请参阅我的文章的加工品,因此建模显然是一个XP的一部分。 每当用户故事和CRC卡是不是最好的选择,XP的开发者也将创建草图,经常在白板上或一块纸上。在极限编程已说明过的,关于XP编写的第一本书,Kent Beck包括类图和其他自由形式的图的手绘草图。事实上,他在第二版包括在里面覆盖概览XP的脑海映像。底线是,建模是一个XP的基本方面,我在这篇文章中详细探讨。

1.2 Documentation Happens
1.2 建立文档的发生


Documentation is also an important part of XP.  Ron Jeffries offers the following advice:
文件也是一个XP的重要组成部分。罗恩·杰弗里斯提供以下建议:

“Outside your extreme programming project, you will probably need documentation: by all means, write it.  Inside your project, there is so much verbal communication that you may need very little else.  Trust yourselves to know the difference.” 
"极限编程项目外,你可能会需要的文件:通过各种手段,把它写出来。在你的项目中,有这么多的口头沟通,而您可能需要很少其他的。相信自己知道其中的差别。"

There are several interesting implications of that statement.  First and foremost, the XP community recognizes that documentation should be produced for people external to your team, people that AM would term project stakeholders.  Second, it points out that verbal communication between team members reduces the need for documentation within the team.  This is the result of project team members being co-located, making communication easier, as well as aspects of XP such as Pair Programming and Collective Ownership that promote communication between developers.  As I discuss in the article on Communication documentation is only one form of communication, one that is typically the least effective, that can be easily replaced by more effective techniques such as face-to-face communication.  Third, it recognizes that sometimes you do in fact need internal documentation for your team.  This is consistent with the advice presented in Extreme Programming Installed where the authors point out that information resulting from conversations with your project stakeholders regarding user stories are captured as additional documentation attached to the card.  More on this in the Section A Closer Look At the XP Lifecycle.  Fourth, it suggests that XP team members should know when documentation is required and be allowed to act accordingly.  Fifth, it implies that you should trust the team and give them control over their own destiny.  This can be hard in many organizations.  If the team is untrustworthy then you have a serious problem that needs to be dealt with, this is true regardless of whether they are following XP, or if they are trustworthy but your organizational culture doesn’t allow you to act based on that trust then once again you have a serious problem to deal with.  Another problem is that when you are an outsider to an XP team, when you haven’t been actively involved in the conversations and interactions that have replaced the need for documentation, that it appears that there isn’t enough documentation.  When this is the case, instead of forcing the team to write documentation instead invest the time to determine if they need the documentation that you believe is missing – suggest the documentation to the team, and if there is an actual need for it then they’ll create it.  As Ron Jeffries likes to say, “It’s called Extreme Programming not stupid programming”.  Finally, the most important implication for XP teams is that if you need documentation then write it.
声明有一些有趣的影响。
首先,XP社会认识到,文件应为你的团队外部的人,那些人,是我会长期项目的利益相关者产生。

第二,它指出,团队成员之间的口头沟通,减少了队内的文档需要。这是项目团队成员的合作,使沟通更容易,以及XP的方面,如对编程和集体所有权,促进开发商之间的沟通。正如我在文章中讨论通讯文件是只有一种形式的沟通,一个是一般至少有效,可以如面对面沟通,更有效的技术容易被取代。

第三,它承认,有时你事实上,确实需要为您的团队的内部文件。这是极限编程提出的意见是一致的安装在那里的作者们指出,信息与项目利益相关者的对话关于用户故事捕获卡连接到其他文档。在此更在第一个关于建立更紧密看看XP的生命周期。

第四,建议XP团队成员应该知道什么时候文件是必需的,是允许采取相应的行动。第五,它意味着,你应该信任的团队,并给予他们控制自己的命运。在许多组织中,这是很难。如果球队是靠不住的,那么你有一个严重的问题,需要处理,这是真实的,不管他们是否遵循XP,或者如果他们是值得信赖的,但您的组织文化不允许你,信任的基础上采取行动,然后再一次,你有一个严重的问题来处理。

另一个问题是,当你是一个XP团队,局外人当你有没有积极参与谈话相互作用,已经取代了对文档的需要,似乎没有足够的文件。何时这种情况下,而不是迫使团队写文档,而不是投资,如果他们需要时间来确定您认为是文件丢失 - 建议文档队,如果有实际需要为它然后,他们将创建它。正如罗恩·杰弗里斯喜欢说,“这就是所谓的极限编程没有愚蠢的编程”。

最后,XP团队最重要的意义是,如果您需要的文件,然后把它写入。

The need for documentation on an XP project is reduced by several of its practices.  First, because of test-first development and a focus on acceptance testing there is always a working test suite that shows that your system works and fulfills the requirements implemented to that point.  For the developers, these tests act as significant documentation because it shows how the code actually works.  When you think about it, this makes a lot of sense.  When you are learning something new do you prefer to read a bunch of documentation or do you look for source code samples?  Many developers prefer to start at source code samples, and the test suite provides these samples.  Second, XP’s focus on simplicity and practice of refactoring result in very clean and clear code.  If the code is already easy to understand, why invest a lot of time writing documentation to help you to understand it?  This applies to both internal and external documentation – why add comments to code that is already clear and unambiguous?  If the code isn’t so, then refactor it to improve its quality or as a last resort write documentation.  Even though some development environments make it easy to include documentation in your code, Java’s Javadoc utility is such an example, you only want to invest in documentation when it makes sense to do so and not just because it is easy.
一个XP项目的文档需要减少一些做法。
首先,因为测试先行的开发和验收测试的重点始终有一个工作的测试套件,表明你的系统的工作原理和满足的要求落实到这一点。对于开发商,这些测试作为显著的文档,因为它显示了如何实际工作的代码。当你想想看,这使得很多的意义。当你学习新的东西,你喜欢读一堆文件,或者你看看源代码样本?许多开发人员喜欢源代码样本,并开始测试套件提供了这些样品。
第二,XP的非常干净,清晰的代码重构结果的简单和实践上的焦点。如果代码已经是很容易理解,为什么投资了很多时间写文档,以帮助你了解它吗?这适用于内部和外部的文件 - 为什么添加代码,已经是明确和毫不含糊的意见?如果代码是不是这样,然后重构它,以提高其质量或作为最后的手段写文件。即使一些开发环境中可以很容易包括在您的代码中的文档,Java的javadoc工具是一个这样的例子,你只希望在文档中进行投资时是有意义的这样做,不仅因为它很容易。

What confuses many people regarding XP and documentation is that XP doesn’t specify potential documents to create during development.  This is unlike the RUP which suggests a slew of potential project artifacts.  Instead, the suggestion is to work together with your project stakeholders in an environment of rapid feedback and trust them to determine the things that they need, not just documents but any type of project enhancements.  Once again, you need to have the courage to trust the people involved with the project.  In the article Agile Documentation I discuss a collection of documents that you may choose to create and provide advice for when to consider creating them.
什么迷惑了许多人关于XP的文件是XP不指定潜在的开发过程中创建的文件。这是不同于RUP,这意味着一个潜在的项目工件的回转。相反,建议是与项目利益相关者在一个快速反馈的环境共同努力,相信他们能够确定的事情,他们需要的不只是文件,但任何类型的项目增强。再次,你需要有这样的勇气,信任与参与该项目的人。敏捷文档在文章中,我讨论的文件的集合,您可以选择以创建和提供建议时,要考虑他们创造的。

One of the greatest misunderstandings people have about XP regards concept of traveling light – many people believe that it means you don’t create any documentation, but nothing could be further from the truth.  What traveling light actually means is that you create just enough models and documentation, too little or too much puts you at risk.  As I suggest in Agile Documentation a good rule of thumb to ensure that you’re traveling light is that you shouldn’t create a model or document until you actually need it – creating either thing too early puts you at risk of wasting your time working on something you don’t actually need yet. 
一个最大的误解,人们对XP有一个轻装上阵的概念 - 许多人认为,这意味着你不创建任何文件,但没有可能进一步从真相。轻装上阵,实际上是指的是你创建只是足够模型和文件,太少或太多置于风险之中。我建议在敏捷文档的一个很好的经验规则,以确保你轻装上阵,你不应该创建一个模型或文件,直到你真正需要它 - 创造任何东西,过早让你在浪费你的时间工作的风险你但实际上并不需要。

An important thing to understand about documentation on an XP project is that it is a business decision, not a technical one.  This is consistent with AM’s philosophy regarding documentation, discussed in Agile Documentation.  Jeffries says it best:
一个XP项目的文档了解一件重要的事情是,它是一个商业决定,而不是一个技术之一。这是AM的理念敏捷文档中所讨论的有关文件,一致。杰弗里斯说,最好的:

“If there is a need for a document, the customer should request the document in the same way that she would request a feature: with a story card.  The team will estimate the cost of the document, and the customer may schedule it in any iteration she wishes.”
如果有需要的文件,客户应以同样的方式,她会要求功能要求文档:用一个小故事卡。该小组将估计文件的成本,客户可以安排她希望在任何迭代。

1.3 XP and The UML
1.3 极限编程和统一建模语言?

See the article XP and the UML?  Clearly the Wrong Question to be Asking
看到这篇文章XP和UML?显然问错了问题

2. AM and XP?
2. AM和XP?

AM should be tailored into an existing, full lifecycle methodology, in order to improve its approach to modeling.  Because modeling is clearly a part of XP, see above, the potential exists for AM to add value to an XP project.  This assumes of course that there is possible to tailor AM into XP, I believe it is and argue so below, and that you can do so without detracting from what currently exists within XP.  In particular, XP’s practices of refactoring and test-first development clearly do a very good job of filling in for two critical goals – promoting clean design and thinking through your design before writing code – that are typically associated with traditional modeling processes.  My experience is that both refactoring and test-first development are complementary to AM and arguably enablers of several AM practices, as I argue below.  In this section I explore the following issues:
AM应调整到一个现有的,完整的生命周期方法,以改善其建模方法。因为模型显然是一个XP的一部分,见上面,存在潜在AM添加一个XP项目的价值。这当然假设是有可能进入XP定制AM,我相信这是认为这样下面,你可以做而不减损目前在XP中存在。特别是,重构和测试优先发展的XP的做法显然填补两个关键目标的一个非常好的工作 - 促进您的设计,编写代码之前,洁净的设计与思考 - 通常与传统的建模过程。我的经验是,重构和测试优先发展是相辅相成的,我可以说是几个AM做法引擎,我认为以下。在本节中,我探讨了以下问题:

  The potential fit between AM and XP 
  AM和XP之间的潜在适合
  Refactoring and AM  
  重构和AM
  Test-first development and AM  
  测试先行的开发和AM
  Which AM practices to adopt? 
  我将采取哪种AM实践?

2.1 The Potential Fit Between AM and XP
2.1 AM和XP之间的潜在适合

A critical issue that must be addressed is how well AM fits with XP.  Table 1 lists the practices of AM and either maps them to existing principles or practices of XP or discusses the potential fit of the AM practice when it is not explicitly a part of XP.  Because XP was used as a foundation for AM many of the practices map straight to XP.  However, because AM’s focus is on modeling several practices are clearly new, hence the potential for AM to bring value to an XP project.
必须解决的一个关键问题是如何我适合用XP。表1列出了AM的做法和他们现有的原则或XP的做法,或讨论潜在的合适的AM实践时,它是没有明确的XP的一部分或者地图。因为XP是用一个AM的基础的做法,许多映射直接到XP。然而,因为AM的工作重点是模拟几种做法显然是新的,因此潜在AM的XP项目带来价值。

Table 1. Applicability of AM Practices on an XP Project.

表1。在一个XP项目上AM实践的适用性。

AM Practice

敏捷建模实践

Fit With XP

适用于极限编程

Active Stakeholder Participation

利益有关者积极参与

This practice is simply a new take on XP’s On-Site Customer practice.  AM uses the term project stakeholder in place of customer and focuses on the concept of their active participation, hence Active Stakeholder Participation and not On-Site Stakeholder.

这种做法简直是对XP的现场客户实践的新的起飞。AM在顾客的地方使用的长期项目的利益相关者,并着重对他们的积极参与,因此活动的利益相关者的参与,而不是网站上的利益相关者的概念。

Apply Modeling Standards

应用建模标准

This is the AM version of XP’s Coding Standards practice.

这是AM版XP的编码标准的做法。

Apply Patterns Gently

轻量级应用模式

This practice reflects the YAGNI principle to the effective application of patterns within your system, in conformance to XP’s practice of Simple Design.

这种做法反映YAGNI原则模式的有效应用在您的系统,符合XP的设计简单的做法。

Apply the Right Artifact(s)

采用正确的加工品

This practice is not explicitly described by XP principles and practices although is very much aligned with XP philosophies of “if you need it do it” and using the most appropriate tool or technique for the job at hand.

这种做法是不明确XP的原则和做法,虽然是非常与XP的哲学相一致的“,如果你需要做”,用手头的工作最合适的工具或技术。

Collective Ownership

集体拥有权

AM has adopted XP’s Collective Ownership practice.

AM已通过XP的集体所有权的实践。

Create Several Models in Parallel

创建并行的几种模式

This is a modeling-specific practice.  XP developers can clearly work on several models – such as CRC cards, acceptance test cases, and sketches – if they choose to do so.

这是一个建模的具体实践。 XP开发人员可以清楚地工作的几种模式 - 如CRC卡,接受测试的情况下,和草图 - 如果他们选择这样做。

Create Simple Content

创建简单的内容

This is complementary XP’s Simple Design practice that advises to keep your models as simple as possible.

这是互补XP的简单设计的做法,建议保持尽可能简单的模型。

Depict Models Simply

简单地描绘模型

This is complementary XP’s Simple Design practice that suggests that your models do not need to be fancy to be effective, perfect examples of which are CRC cards and user stories.

这是相辅相成的XP的简单设计实践表明,你的模型不需要看中的是有效的完美的例子,这是CRC卡和用户故事。

Discard Temporary Models

丢弃临时模型

This practice reflects XP’s Travel Light principle, which AM has adopted, explicitly advising you to dispose of models that you no longer need.

这种做法反映了XP的轻装上阵的原则,AM已通过,明确建议你,你不再需要处理模型。

Display Models Publicly

公开显示模式

This practice reflects XP’s (and AM’s) value of Communication, principle of Open & Honest Communication (adopted by AM), and reflects its practice of Collective Ownership.

这种做法反映了XP的(和AM)通信,开放和诚实的沟通原则(被AM采纳)的价值,并反映其集体所有权的实践。

Formalize Contract Models

正式联系模型

This practice is not currently reflected within XP, well perhaps in its “if you need to then do it” philosophy.  This practice was included in AM to provide guidance for how to deal with the very common situation of integrating with other systems.

这种做法目前尚未反映在XP中,或许在其“如果你需要,然后做”的经营理念。这种做法被列入我对于如何处理与其他系统集成的很常见的情况提供指导。

Iterate to Another Artifact

迭代到另一个加工品

This practice explicitly states, in a general form, the practice of XP developers to iterate between working on various artifacts such as source code, CRC cards, and tests.

这种做法明确规定,在一般的形式,XP的开发实践迭代之间的各种文物,如源代码,CRC卡,测试工作。

Model in Small Increments

以较小的增量模型

This practice supports XP’s iterative and increment approach to development.  Both XP and AM prefer an emergent approach to development and not a big design up front (BDUF) approach. 

这种做法,支持XP的迭代和递增的发展方针。 XP和AM都喜欢发展的应急办法,不是前面的大设计(BDUF)方法。

Model With Others

与其他模型

This is the AM version of XP’s Pair Programming practice.

这是AM版XP的结对编程实践。

Prove it With Code

用代码证明

This is the AM version of XP’s Concrete Experiments principle.  In fact, it was originally called Concrete Experiments although was renamed when it was evolved into a practice.

这是AM版XP的原则混凝土实验。事实上,它最初被称为具体的实验虽然改了名,当它被演变成一种做法。

Reuse Existing Resources

重用现有的资源

This concept is not explicitly included in XP, although it clearly isn’t excluded either.  XP developers are practical, if there is something available that can be appropriately reused then they will likely choose to do so.

这个概念没有明确包括在XP中,虽然这显然是不排除。 XP的开发是可行的,如果有东西可用可适当重用,那么他们很可能会选择这样做。

Single Source Information
单源的信息
The goal of storing information in a single place reflects the XP concept of traveling light.
将信息存储在一个地方的目标,反映的轻装上阵XP的概念。

Update Only When it Hurts

仅当触碰到是更新

This practice reflects AM and XP’s Travel Light principle, advising that you should only update an artifact only when you desperately need to.

这种做法反映了AM和XP的旅行轻的原则,建议你应该只更新一个神器,只有当你迫切需要。

Use the Simplest Tools

使用简单的工具

This practice reflects AM and XP’s Assume Simplicity principle and is consistent with XP’s preference for low-tech tools such as index cards for modeling.

这种做法反映了AM和XP的简单性原则,是XP的低技术手段,如建模的索引卡的偏好是一致的。


The fact that AM’s practices are complementary to XP isn’t sufficient; there should also be a philosophical alignment between the two methodologies as well.  I believe that there is.  First, AM has adopted the four values of XP – Courage, Simplicity, Communication, and Feedback – and added a fifth one, Humility, one that is clearly compatible with XP.  Second, the principles of AM are closely aligned with those of XP.  Nine of eighteen are adopted directly from XP, and the remaining ones – Software is Your Primary Goal, Enabling the Next Effort is Your Secondary Goal, Model With a Purpose, Multiple Models, Content is More Important Than Representation, Everyone Can Learn From Everyone Else, and maximize stakeholder ROI – are clearly compatible with XP’s philosophies.  The three modeling-specific principles may cause a hard-core XP developer to pause for a moment, but on reflection should not prove arguable.  Model With a Purpose advises that you shouldn’t work on a model without good cause, Multiple Models says that you have a wide range of techniques available to you that you may choose to apply (including but not limited to CRC cards, user stories, and the diagrams of the UML).

事实上,AM的做法是相辅相成的XP是不够的,以及两者之间的方法也应该是一个有哲学对齐。我相信有。首先,AM已通过XP的四个价值观 - 勇气,简单,沟通,反馈 - 增加了五分之一,谦逊,一个显然是与XP兼容。

第二,AM的原则与XP中的密切配合。八九十是通过直接从XP,其余的 - 软件是你的首要目标,使下一步的努力是你的第二个目标,模型的目的,多种模式,内容更重要比表示,每个人都可以学习别人和最大化利益相关者的投资回报率 - 显然是与兼容XP的理念。三种建模的具体原则可能会导致暂停硬核XP片刻开发的,但反思不应该证明值得商榷。模型有目的的建议,你不应该无正当理由工作模型,多模型,说你有一个广泛的技术提供给您,您可以选择适用于(包括但不限于CRC卡,用户故事,和UML的图)。

2.2 Refactoring and AM
2.2重构和AM

Refactoring is a technique to restructure code in a disciplined way, a technique that is a fundamental practice of XP.  The basic idea is that you make small changes to your code, called refactorings, to support new requirements and/or to keep your design as simple as possible.  The advantage of refactoring is that it enables programmers to safely and easily evolve their code to fulfill new requirements or to improve its quality.
重构是一种技术来重组一个有纪律的方式,这是一个XP的基本实践的技术代码。基本的想法是,你做小改动你的代码,称为重构,以支持新的要求和/或保持你的设计尽可能简单。重构的好处是,它使程序员可以轻松,安全地发展他们的代码,以满足新的要求,以提高其质量。

Is refactoring compatible with AM?  Yes.  Refactoring is a coding technique whereas AM does not address programming-related issues, therefore there is no technical overlap between the two.  What about a conceptual overlap?  AM address design modeling and refactoring addresses design improvement of source code.  This begs the question “What do you do when you have an existing design model and you refactor your code?”  Although it’s an interesting question, the real issue is that you have two artifacts, a design model and source code, that describe the design of your system.  One has changed, the source code, now you need to decide whether or not you wish to update the model.  The way that you originally arrived at the model is irrelevant to this issue, you could have gotten there because you took an AM approach to develop it, you could have taken a BDUF approach, or you could adopted an existing model and are coding to it (for example, several organizations have developed persistence frameworks based on the design that I present at http://www.ambysoft.com/persistenceLayer.html).  The issue is irrelevant of the type of design model, be it a UML class diagram, CRC cards, a physical data model, or a procedural structure chart.  The good news is that AM provides advice for how to deal with such a situation, in particular the practice Discard Temporary Models suggests that you should consider whether you really need the design model and then if not get rid of it and the practice Update Only When it Hurts suggests that it’s often reasonable to have artifacts such as the design model and the code out of sync.
重构与AM是兼容的?是。重构是一种编码技术,而我并没有解决编程相关的问题,因此,两者之间是有没有技术的重叠。一个概念的重叠是什么?地址设计模型和重构地址的源代码的设计改进。这引出的问题:“你做什么时,你有1现有的设计模式和你重构你的代码”虽然这是一个有趣的问题,真正的问题是,你有两个工件,一个设计模型和源代码,描述设计您的系统。一个已经改变,源代码,现在您需要决定您是否要更新模型。您最初在到达模型的方式是与这个问题无关,你可以得到,因为你拿了一个AM的方法来开发,可以采取BDUF方法,或者你可以通过现有的模型和编码(例如,一些组织已经开发出持久性框架的基础上设计的,我目前在http://www.ambysoft.com/persistenceLayer.html)。问题是设计模型的类型无关,它是一个UML类图,CRC卡,物理数据模型,或者程序结构图。好消息是,AM提供如何处理这种情况的意见,特别是实践丢弃临时模型表明,你应该考虑你是否真的需要设计模型,然后如果不摆脱它与实践的更新只当它伤害的建议,它是合理的,有文物,如设计模型和代码同步。

So how do you apply AM and refactoring together?  Simple.  Apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and refactor your code as you normally would have.  If you discover that you need to attempt a major refactoring, get the team together to discuss it, modeling whenever appropriate, then approach the major refactoring as you would have in the past: as a collection of small refactorings. 

那么,你如何适用于AM和重构?简单。申请我建模时你输入到你的编程工作,使用这些模式,并重构您的代码,你通常会在适当的做法。如果你发现你需要尝试一个重大的重构,得到团队一起讨论,建模,然后适当的时候方法的主要你将不得不在过去的重构:作为一个小的重构集合。


Modeling tools that reverse-engineer your code can prove valuable when you are refactoring code, particularly when you are unfamiliar with that code. Many developers think visually, they grasp information communicated via pictures more readily than they do information communicated textually, so CASE tools that quickly import a bit of code and create diagrams from them can be very useful.  It's quite common for CASE tools to import object-oriented source code, perhaps written in Java or C++, and generate UML class diagrams that show the static structure of the code and UML sequence diagrams that depict its dynamic nature.  These diagrams can be used to quickly understand the existing code, the first step in refactoring it.
建模工具,逆向工程的代码可以被证明是有价值的,当你重构代码,尤其是当你不熟悉的代码。许多开发商认为,在视觉上,他们掌握更容易比他们传达文本信息,通过图片传达的信息,因此CASE工具,快速导入的代码位,并从他们创建图表是非常有用的。CASE工具导入Java编写的面向对象的源代码,也许这是相当普遍的或C + +,生成UML类图显示的代码和UML序列图的描绘,其动态性质的静态结构。这些图可用于快速理解现有的代码,在重构的第一步。

2.3 Test-First Development and AM
2.3 测试先行的开发和AM

Test-first development is a development practice where you work in very short cycles where you consider a test, write the test and business code for it, get it to work, then continue.  These tests are collected into a development integration testing suite that must be successfully run whenever code is submitted into your shared repository.  This practice is integral to XP.
你在很短的周期,你认为测试工作,测试先行的开发是一个发展的实践,写的测试和业务代码,得到它的工作,然后继续。这些测试收集到的发展集成测试套件必须成功运行时代码提交到您的共享库。这种做法是不可或缺的XP。

Is test-first development compatible with AM?  Yes.  Like refactoring, test-first development is more of a coding practice so there is little opportunity for technical overlap.  However, there is room for conceptual overlap because test-first development clearly delves into the realm of detailed design since it provides developers with an opportunity to think through their code before they write it (as well as important feedback regarding their code).  If you’ve chosen to do a little modeling before writing your code, perhaps to think through an issue larger than a single test case, then that’s okay.  In fact, it may even make your test-first development efforts easier, because you've thought things through better.  
测试先行的开发与AM兼容吗?是。像重构,测试先行的开发是一个编码实践,因此有技术重叠的机会很少。然而,有概念重叠的地方,因为测试先行的开发明确详细设计领域的深入研究,因为它提供了一个机会,想通过他们的代码之前,他们把它写(以及重要的反馈,对他们的代码)的开发。如果你选择了编写代码之前,做一点点的模型,也许是想通过一个问题大于一个测试用例,然后没关系。事实上,它甚至可以使您的测试先行的开发方面的努力,更容易,因为你想通过更好的东西。

How do you apply AM within a test-first development environment?  As with refactoring, simply apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and iterate between modeling, testing, and programming as needed.  For more details, read the AMDD article.
如何申请我在测试先行的开发环境?至于与重构,简单地套用AM在适当的做法,当你建模,输入到你的编程工作中使用这些模型,迭代建模,测试和编程之间需要。有关详细信息,请阅读的AMDD文章。

2.4 Which AM Practices to Adopt?
2.4 采用哪种AM实践?

Only the ones that add value to what your team is trying to accomplish.  Ideally that will at least be the core practices of AM, therefore it would be fair to claim that you are in fact “doing AM”, and perhaps even adopt the supplementary practices as well.  It is important to note that your goal isn’t simply to be able to say that you’re agile modeling, it is to improve your productivity as software developers.
只有你的团队,努力实现增加值。理想的情况下,将至少是AM的核心做法,因此这将是公平的要求,事实上,“做AM”,甚至采取补充的做法,以及。重要的是要注意,你的目标不只是要能说,你是敏捷建模者,它是作为软件开发人员来改善您的生产力。

3. AM Throughout the XP Lifecycle
3. AM贯穿整个XP的生命周期 

To explain how the practices of AM can be applied on an XP I will work through a portion of the SWA Online Case Study and show how  modeling is used throughout the XP lifecycle in the article AM and XP: AM Throughout the XP Lifecycle. 
解释如何使AM实践可以应用在一个XP上,我将努力通过部分的SWA在线为例,展示如何建模是整个XP的生命周期在AM和XP的文章:在整个XP的生命周期。

4. How Do You Make This Work?
4. 你如何做这项工作?

How should you approach modeling during development on an XP project?  Beck suggests that you should apply the XP practice of Small Initial Investment and draw a few pictures at a time.  He states that the XP strategy is that anyone can design with pictures all they want, but as soon as a question is raised that can be answered with code then the designers must turn to code for the answer.  In other works you should then seek Rapid Feedback to discover whether your pictures are on target by following the AM practice Prove it With Code.
你应该如何对待一个XP项目的开发过程中的建模?贝克建议,你应该适用于小的初始投资的XP实践和时间绘制了几张图片。他指出,XP的策略是,任何人都可以设计图片所有他们想要的,但只要作为一个问题提出,可以用代码回答,然后设计者必须把答案代码。在其他作品中,你应该寻求快速反馈,发现你的照片是否目标是通过以下的AM实践证明它的代码。

When should you consider modeling during development on an XP project?  Whenever creating a model is more effective that writing code.  In other words, follow the AM principle maximize stakeholder ROI and the AM practice Apply the Right Artifact(s).
当你应该考虑一个XP项目的开发过程中的建模?每当创建一个模型是更有效地编写代码。换句话说,按照AM的原则,最大限度地发挥利益相关者的投资回报率和采用正确的加工品的AM实践。

How should you model?  Follow AM’s practice Use the Simplest Tools and prefer tools such as index cards, whiteboards, and Post It notes over more complicated CASE tools.  Simple tools tend to promote interaction and communication, two factors that are critical to your success.  Although XP favors the use of index cards to record user stories, CRC models, and story tasks there is nothing wrong with using a CASE tool as long as its use provides positive value to your effort.
你应该如何建模?遵循AM的实践,用最简单的工具和喜欢索引卡,白板等工具,并张贴注意到以上的更复杂的CASE工具。简单的工具,往往促进互动和交流,您的成功是至关重要的两个因素。尽管XP有利于使用索引卡来记录用户的故事,CRC模型,和剧情任务,只要使用一个CASE工具,它的使用提供了积极的价值你的努力没有错。

How should you document?  XP teams prefer to write clean, easy-to-understand source code – their philosophy is that only the source code is in sync with the source code.  However, remember that AM’s principle Model With A Purpose states that you should understand the needs of a model/document’s audience.  If the audience for documentation is your system’s users or your senior management then clean source code isn’t going to do it, instead you will need to develop external documentation for this audience.  Your stakeholders should request this documentation and should understand the costs involved, one of which is the fact that any time you spend writing documentation isn’t spent writing software, and be willing to accept those costs.
你应该如何记录?XP团队喜欢写干净,易于理解的源代码 - 他们的理念是,只有源代码是在与源代码同步。但是,请记住,我的原则与目的国模型,你应该了解模型/文档的观众的需求。如果观众文件系统的用户或高级管理人员,然后干净的源代码不打算这样做,而不是你将需要开发这个观众的外部文档。你的利益攸关方应请求这个文件,并应了解所涉及的费用,其中之一是没有花任何时间花在编写文档编写软件,并愿意接受这些费用的事实。

XP developers need to recognize that you can model on an XP project, that modeling is in fact a part of XP already with its existing application of user stories and CRC cards.  More importantly, XP developers must abandon any preconceived notions that they may have about modeling - that big modeling up front (BMUF) is the only approach to modeling, that models are permanent documents that must always be updated, that you need to use complex CASE tools to model, and that the UML defines the only models available to you - and approach modeling from a new perspective.  One such perspective was presented in this article, that you can tailor Agile Modeling (AM) into a software process based on eXtreme Programming (XP) and still remain effective as software developers.
XP开发人员需要认识到,你可以模拟一个XP项目,该模型实际上是一个XP的一部分已经与现有的应用程序其用户故事和CRC卡。更重要的是,XP的开发必须摒弃任何先入为主的观念,他们可能有大约建模 - 大,前面建模(BMUF)的模型,模型是必须始终更新的永久文件是唯一的办法,你需要使用复杂的情况下工具的UML模型,并定义唯一的车型为您提供 - 从一个新的视角和方法建模。这样一个观点,在这篇文章中,你可以定制敏捷建模(AM)到极限编程(XP)的基础上,仍然有效的软件开发商的软件过程。


Reference sit: http://www.agilemodeling.com/essays/agileModelingXP.htm

2010-03-12 20:33:00 ostrichmyself 阅读数 27968

敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别,

 

发现一篇外文, 见解非常深刻, 特将其翻译一把.

 

原文(DIFFERENCES BETWEEN SCRUM AND EXTREME PROGRAMMING )在此:

 

http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming

 

作者总结的大致区别如下:

 

区别之一:  迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

 

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰

 

区别之三: 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

 

别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”

 

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

 

作者建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

 

非常不错, 文武之道,有张有弛。

 

 

该博客之后有很多人提出了异议, 稍后将其推出,  看看其它敏捷高手是如何看待这个问题的, 也防止误导读者:

 

待续。。。。

 

 

 

 

 

 

 

 

 

 

2010-03-16 22:56:00 liyangbing315 阅读数 8498

敏捷开发与极限编程

简介

      2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发过程的方法很多,主要有:SCRUM, Crystal,特征驱动软件开发(Feature Driven Development, 简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme programming ,简称XP).极限编程(XP)是于1998Smalltalk社群中的大师级人物Kent Beck首先倡导的。

极限编程(XP)

      极限编程(XP)是敏捷软件开发中最著名的一个,它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

极限编程 是一门针对业务和软件开发的规则,它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论,XP使开发者能够更有效的响应客户的需求变化,哪怕是在软件生命周期的后期。它强调,软件开发是人与人合作进行的过程,因此成功的软件开发过程应该充分利用人的优势,而弱化人的缺点,突出了人在软件开发过程中的作用。极端编程属于轻量级的方法,认为文档、架构不如直接编程来的直接。XP实际上是一种经历过很多实践考验的一种软件开发的方法,它诞生了大概有5 年,它已经被成功的应用在许多大型的公司,如:Bayeris che LandesbankCredit Swis s LifeDaimlerChryslerFirst Union National Bank Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调,XP 是以开发符合客户需要的软件为目标而产生的一种方法论,XP 使开发者能够更有效的响应客户的需求变化,哪怕在软件生命周期的后期。同时,XP 也很强调团队合作。团队包括:项目经理,客户,开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。XP 强调四种价值:交流,简易,回馈,勇气。XP 程序员之间紧密的相互交流,XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。
XP
是与众不同的,它有点象快步的舞蹈。XP 开发过程包括许多的小卡片,独立的看,这些小卡片没有什么意义,但是当它们组合在一起,一幅完整的美丽的图片就可以看见,XP方法有别于传统软件开发,它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
XP
属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解,的轻重是指用于软件过程管理和控制的、除程序量以外的文档量的多少。XP等轻量开发方法认识到,在当前很多情况下,按传统观念建立的大量文档,一方面需要消耗大量开发资源,同时却已失去帮助预见、管理、决策和控制的依据的作用。因此必须重新审视开发环节,去除臃肿累赘,轻装上阵。
一、XP的核心思想
     
从长远看,早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块,并且强调测试、代码质量和及早发现问题。通常,通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。
二、XP的十二种方法
     
规划策略(The Planning Game)
     
结对编程(Pair programming)
     
测试(Testing)
     
重构(Refractoring)
     
简单设计(Simple Design)
     
代码集体所有权(Collective Code Ownership)
     
持续集成(Continuous Integration)
     
现场客户(On-site Customer)
     
小型发布(Small Release
     
每周40小时工作制(40-hour Week
     
编码规范(Code Standards
     
系统隐喻(System Metaphor
三、XP的四个核心价值
     
极限编程中有四个核心价值是我们在开发中必须注意的:沟通(Communication)、简单(Simplicity)、反馈(Feedback)和勇气(Courage)。

XP
沟通、简单、反馈和勇气来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程必须重量才能成功的传统观念。

XP
精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键,是用沟通、简单、反馈和勇气的态度来对待XP;轻松愉快地来感受XP的实践思想;自己认真实践后,通过对真实反馈的分析,来决定XP对自己的价值;有勇气接受它,或改进它。

四、XP 带给我们的变化

通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗?XP认为事实并非如此。

一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍,这意味着一个项目每年要花200 万美元在程序员身上,而仅仅花10 万美元在电脑设备上。很多聪明的程序员说:我们如此聪明,发现一种方法可以节省20%的硬件开销,然后他们使得源程序大而且难懂和难以维护,他们会说:但是我们节省了20%或者2 万美元每年,很大的节省。反之,如果我们写我们的程序简单而且容易扩展,我们将至少节省10%的人力开销,一笔更大的节省,这是你客户一定会注意到的一些事情。

另外一个对客户来说很重要的问题就是程序的BUGS XP 不只是强调测试,而且要求正确的测试。测试必须是能自动进行的,以便为程序和客户提供一个安全的环境。在编码的所有阶段,我们不断增加测试用例。当找到 bug 时,我们就添加新的测试,一个紧密的安全网就这样产生了。同一个BUG 不出现两次,这些一定会引起用户的注意。你的客户必须注意的另外一件事情:XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

一般情况下,客户只有在系统被开发完成以后能真正去体会它。XP 却不一样,它通过加强客户的反馈来缩短开发的周期,同时获得足够的时间来改变功能和获得用户的认同。在XP 中,你的客户应该明确的知道这一点。

XP
开发过程的大多的革命是在软件开发的方法上,代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

五、我们什么时候用XP

XP
方法的产生是因为难以管理的需求变化,从一开始你的客户并不是很完全的知道他们要的系统是怎么样的,你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变,这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内,需要一个相当难开发的系统,而且对于你的项目组来说,这个系统是一个新的挑战(从来没有做过),那风险就更大了,如果这个系统对于整个软件行业来说都是新的挑战,那么它的风险就更大了,采用XP 将可以减少风险,增加成功的可能。

XP
方法是为小团体开发建立的,在2-10 个人之间。假如你的团体恰好合适,你就不需要用其他的软件工程方法了,就用XP ,但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意,在需求一惯呈动态变化或者高具有高风险的项目中,你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

XP
方法需要一个扩展的开发团体,XP 团体不仅仅包括开发者,经理、客户也是其中的一员,所有的工作一环扣一环,问问题,商讨方法和日程,增加功能测试,这些问题的解决不仅仅涉及到软件的开发者。

另一个需要是可测试性,你必须能增加自动的单元测试和功能测试,然而在你进行这个需求的时候,你会发现有许多的问题很难测试,这需要充分发挥你的测试的经验和智慧,而且你有时还要改变你的设计以便它可以更容易的进行测试。记住:那儿有需求,那儿就应该有测试的方法。

XP方法的好处的清单上,最后一条是生产力。在同样的合作环境下,XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是:在规定的时间生产出满足客户需要的软件。假如对于你的开发来说,这是很重要的方面,你就可以选择XP 了。

下面是极限编程的有效实践:

1.     完整团队XP项目的所有参与者(开发人员,客户,测试人员)一起工作在一个开放的场所中,他们是同一个团队的成员,这个场所的墙壁上随意悬挂着大幅的,显著的图表以及其它一些显示他们进度的东西。

2.     计划游戏计划是持续的,循序渐进的,每两周,开发人员就为下两周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。

3.     客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4.     简单设局团队保持设计恰好和当前的系统功能相匹配,它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西。并且包含尽可能少的代码。

5.     结对编程所有的产品软件都是由两个程序员,并排坐在一起在同一台机器上构建的。

6.     测试驱动开发编写单元测试是一个验证行为,更是一个涉及行为。同样,他是一种编写文档的行为,编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。

7.     改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净,具有表达力。

8.     可持续的速度,团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑,极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程,极限编程是一种优良的,通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

 

敏捷开发

人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。

敏捷软件开发宣言:

个体和交互      胜过  过程和工具

可以工作的软件  胜过  面面俱到的文档

客户合作        胜过  合同谈判

响应变化        胜过  遵循计划

虽然右项也有价值,但是我们认为左项具有更大的价值

我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意。

即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势。

经常性地交互可以工作的软件,交互的间隔可以从几个星期到几个月,交互的时间间隔越短越好。

在整个项目开发期间,业务人员和开发人员必须要天天都在一起工作。

围绕被激励起来的个体构建项目,给他们提供所需的环境和支持,并且信任他们能够完成工作。

在团队工作内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度,责任人,开发者和用户应该能够保持一个长期的,恒定的开发速度。

不断地关注优秀的技能和好的设计增强敏捷能力。

简单是最根本的。

最好的构架,需求和设计出于自组织团队。

每隔一定的时间,团队会在如恶化才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

敏捷团队依靠变化来获取活力,团队几乎不进行预先设计,因此,不需要一个成熟的初始设计,他们更愿意保持设计尽可能的干净,简单,并使用许多单元测试和验收测试作为支援,这保持了设计的灵活性,易于理解性,团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计,为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则加以避免,这些原则是:

 单一职责原则(SRP)

就一个类而言,应该仅有一个引起它变化的原因

开放-封闭原则(OCP)

软件实体应该是可以扩展的,但是不可修改。

Liskov替换原则(LSP)

子类型必须能够替换掉它们的基类型。

依赖倒置原则(DIP)

抽象不应该依赖于实现细节,细节应该依赖于抽象。

接口隔离原则(ISP)

重用发布等价原则(REP)

重用的粒度就是发布的粒度

共同封闭原则(CCP)

包中所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生产生影响,而对于其他的包不造成任何影响

共同重用原则(CRP)

一个包中的所有类应该是共同重用的

无依赖原则(ADP)

在包的依赖关系图中不允许存在环

稳定依赖原则(SDP)

朝着稳定的方向进行依赖

稳定抽象原则(SAP)

包的抽象程度应该和其稳定程度一致

敏捷设计是一个过程,不是一个事件,它是一个持续的应用原则,模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能简单,干净和富有表现力。