敏捷开发极限编程论文_极限编程敏捷开发 - CSDN
  • 最近两周的时间里,我看了73篇极限编程论文,其中68篇是主要写结对编程论文。在这些论文中,我看到了各个国家的文章,欧洲,北美,澳洲,少量亚洲的论文,其中看到了大概四五篇来自国内大学与国外大学或者研究...

    最近两周的时间里,我看了73篇极限编程的论文,其中68篇是主要写结对编程的论文。

    在这些论文中,我看到了各个国家的文章,欧洲,北美,澳洲,少量亚洲的论文,其中看到了大概四五篇来自国内大学与国外大学或者研究机构合作的论文。

    国内这些大学的名字就不提了。

    我看到美国的一些结对编程的论文参与的学生数量从几十到一千多人,部分研究时间长达三年。当然那个大学在这三年间发表了多篇论文,其中关于结对编程方面的论文有五篇之多。

    看到了一篇国内某大学一学生与国外一华人留学生合写的论文,后来在另一篇论文中发现了内容与之类同的论文,只不过,后者是这个华人留学生和另外一个外国人合写的。另外,后者的文章内容数据更充实,论点的依据数据更准确,基本上可以认定前者是后者抄袭后修改出来的。

    国内关于结对编程方面的那几篇论文都存在如下问题:

    1、参与试验者背景不明,不知道是不是学生,或者即使知道是学生也不知道学生的情况,都是大学生,硕士生或者还是博士生,大学是大学几年级学生。而在国外的多数论文中对此都有很明确的说明:大学新生,高年级学生或者大学毕业生,男性,女性,少数民族等等个性与背景条件等等。

    2、参与试验者的数量较少,没有见到那个国内这方面的论文中涉及到的试验者超过六个。基本上都是六个人组成两个结对组合和独立开发者四对。而在国外的论文中也有六个的方式,除了六个以外,还有十二个,一百多个,几百个,一千三百多个参与者等等不一而足。

    3、试验时间或者试验项目情况不明确,文中很少提到具体的试验时间或者项目的数量与情况,只有一篇提到是12个任务组成。而在国外的论文中会提到项目试验的时间,诸如400小时的开发时间或者全部试验周期为多少年多少学期内进行,或者按照项目的数量来进行评估,诸如12个项目任务以及这些项目都来源于那里,是游戏类项目,还是其他类别的项目等等。

    我是为了撰写我的交换编程论文而查阅的相关资料,这些学术论文都是一个朋友从自动化所内的网络上帮我从一个学术论文网站上下载下来的,因为其他的ip都无法从这个网站上下载东西,这些学术网站是收费的,好像还比较昂贵。

    上面只是一些现象的评论,今天没时间继续了,下次再说吧。

     

    补充:

    看到一个朋友说我只写出这么一点东西,的确我写的很少,不过,我看这些文章不是为了总结这篇文字,这篇文字只是副产品而已。呵呵,主要的东西是为了撰写交换编程的论文,看看国内外相关的学术研究状况。目前这篇文章已经基本上完成。

    展开全文
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    背景

    我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些问题,自己在实施敏捷的过程也存在很多的疑惑(毕竟原来没有学过,和真实的经历,体会),所以最近一直在学习敏捷,看敏捷的视频和阅读相关资料,同时结合自己实施敏捷的经验,通过分享博文进行一下简单的总结,目的有四:
    1. 详细的介绍和学习一下敏捷开发
    2. 和CSDN的大牛们一起分享交流,学习,提高一下
    3. 总结实施敏捷过程中的问题,不断反思,不断提高
    4. 最后,希望对不了敏捷的朋友有一定的帮助

    什么是敏捷开发

    敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

    怎么理解呢?

    • 首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。

    • 其次,敏捷开发都具有以下共同的特征:

      1. 迭代式开发
      2. 增量交付
      3. 开发团队和用户反馈推动产品开发
      4. 持续集成
      5. 开发团队自我管理
    • 最后,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。

    具体方式

    上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

    Scrum,极限编程(XP)精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

    除了Scrum和XP,对于上面的其他开发方式,我也只是简单了解,大家可以多查查相关的资料。

    我们可以简单的对比一下Scrum和XP:
    1. 在开发的过程中,你可以采用Scrum方式也可以采用XP方式;
    2. Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的。

    敏捷开发宣言

    《敏捷宣言》

    我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

    个体与交互 重于 过程和工具
    可用的软件 重于 完备的文档
    客户协作 重于 合同谈判
    响应变化 重于 遵循计划

    在每对比对中,后者并非全无价值,但我们更看重前者

    敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

    敏捷开发十二原则

    在敏捷开发中,我们遵循以下准则:

    1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7. 可用的软件是衡量进度的主要指标。
    8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11. 最佳的架构、需求和设计出自于自组织的团队。
    12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

    敏捷开发宣言比较抽象,但是敏捷开发十二原则就非常具体了,相信用过敏捷的人都知道,上面的十二原则都是开发过程的经验总结。看到十二条原则,一一的对比我们公司在实施敏捷的过程,还存在一些问题,这些问题直接导致了低效率的,不顺畅的敏捷,例如:最后一条,团队要定期反省,这点做的就不好,造成团队的积极性降低,开发效率下降,而且很难作出调整,甚至我开始也是拒绝的,有了这些原则作为指导,我们可以更加从容的实施敏捷。

    敏捷开发十二原则是我们实践的具体指导方针,它可以指导我们实施更加成功的敏捷。当我看到这些内容时,真有一种如饥似渴的感觉,真想一下子都把他们装进我的脑子里。书到用时,方恨少。及时补充自己永远都不晚。

    总结

    敏捷的思想今天算是深入人心了,后面的具体方法就是教会我们如何实施敏捷。有了这些思想,整个世界都开始美好了。

    下篇博文,进入我们的重点简单介绍Scrum以及Scrum的流程,敬请关注。

    展开全文
  • 12个核心实践翻译自论文 ——Extreme-Programming-A-Case-Study-in-Software-Engineering-Courses 一、在正式翻译论文之前,本人就个人查阅资料的相关情况,先对Extreme-Programming做一个简要概述: ...

    12个核心实践翻译自论文

    ——Extreme-Programming-A-Case-Study-in-Software-Engineering-Courses

     

    一、在正式翻译论文之前,本人就个人查阅资料的相关情况,先对Extreme-Programming做一个简要概述:

             极限编程是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

    “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目,其开发过程应该是平稳的、高效的和快速的,能够做到一周40小时工作制而不拖延项目进度。

    XP在制定需求方面,提倡客户是项目开发的队伍中的一员;在设计阶段提倡测试先行;在编码阶段提倡结对编程。

    基于敏捷的核心思想和价值目标,XP要求项目团队遵循13个核心实践

    团队协作(Whole Team)、规划策略(The Planning Game)、

    结对编程(Pair programming)、测试驱动开发(Testing-Driven Development)

    重构(Refactoring)、简单设计(Simple Design)

    代码集体所有权(Collective Code Ownership)、持续集成(Continuous Integration)

    客户测试(Customer Tests)、小型发布(Small Release)

    每周40小时工作制(40-hour Week)、编码规范(Code Standards)

    系统隐喻(System Metaphor)

     

                                                                                        ——以上内容引自百度文库

     

    二、12个核心实践论文翻译

    1、规划策略(The Planning Game):将业务与开发团队聚集到一起,共同决定需求的特征将会最大化业务价值。在XP中收集需求的相关技术与传统软件方法有着根本的不同。首先,客户需求使用自然语言写成的,非正式的“用户故事”卡片,与用例相似。这些卡片没有形式化,彼此之间没有关系和依赖,不容易被识别。软件开发人员将时间估算和客户分配到每张卡片的优先级。开发人员和客户一起玩“规划游戏”,在这个游戏中,用户选择那些包含一个月左右的短期增量交付的最重要内容的用户故事。客户接受并尝试每个短的执行增量。然后,重新检查其余的用户故事以查找可能的需求和/或优先级变化,并且为下一个执行增量重新开始计划游戏。

    2、小型发布(Small Release):一个包含了一系列有用特征的简单系统可以尽早的投入生产并且可以在较短周期期内频繁更新。XP通过3-4周的短期发布提高了螺旋式发展的速度。每次发布结束时,客户都会审阅中间产品,识别缺陷并调整未来的需求。

    3、隐喻(Metaphor):每个项目都有一个“名称系统”和描述,有助于指导各方之间的发展过程和交流。XP相信每个应用程序都应该具有基于简单隐喻的概念完整性,这就解释了系统工作的本质。例如,一个大的XP项目是克莱斯勒的工资系统。 这个项目的隐喻是,工资系统就像一条装配线,其中小时零件被转换成美元零件,所有零件都被组装并产生薪水。

    4、简单设计(Simple Design):只要满足当前业务需求,最简单的设计总是用于构建应用程序。无论如何,随着时间需求的变化,不要担心未来的需求。重构实践(见下文)将确保设计的高标准。XP致力于超级简单的设计。他们强调程序员不应该试图预测未来的需求,并相应地产生更复杂的设计。开发人员应该遵循简单的设计实践和“做可以工作的最简单的事情”。

    5、测试(Testing):XP遵循“测试优先”的方法,即在添加新功能之前,编写测试来验证软件。然后开发该软件以通过这些测试。使用XP开发的软件始终得到验证。进行两种类型的测试,单元和功能测试

          5.1、单元测试:广泛的自动化白盒测试用例是在生产代码之前编写的。这些自动化测试被添加到代码库中。在程序员可以将他们的代码集成到代码库之前,他们必须通过他们自己的测试用例的100%,以及在代码库中写过的每个测试的100%。这可确保新代码在不破坏其他人的代码的情况下实现新功能。

          5.2、功能测试:传统上,项目管理技术是基于开发人员自己评估他们的任务已完成的。或者,XP推广使用功能测试用例跟踪来计算项目完整性。XP将此评估称为“项目速度”。功能测试用例基于客户场景。当功能测试用例成功通过时,可以认为指定功能已正确实施。项目的完整性基于已通过的功能测试用例的百分比。团队成员可以明确地计算这个度量。

          5.3、自动化测试:编写测试是不够的,你必须运行它们。单元测试全部收集在一起,每当程序员向代码库发布任何代码时(代码对通常每天发布两次或更多),每一次程序员测试都必须正确运行。百分之百,所有的时间!开发者有兴趣使用适当的自动化测试框架,例如 JUnit和NUnit,来控制和简化重复测试和持续集成的任务。这意味着程序员可以立即获得关于他们如何做的反馈。另外,随着软件设计的改进,这些测试提供了非常宝贵的支持。

    6、重构:重构是在保留(而不是改进)其功能的同时改进代码结构的过程。XP主张持续而明确地重构代码。这是一种改进现有代码库设计的技术。其本质是应用一系列小的行为保留转换,以改善代码的结构。通过小步骤完成它们,可以降低引入错误的风险。

    7、结对编程:使用XP的编程人员进行配对,并使用每对配对的单个机器编写所有生产代码。这有助于代码在写入时不断进行审阅。结对编程证明可以生成高质量的代码,但生产力几乎没有下降。

    8、代码集体所有:所有代码都属于团队的每个成员,团队中没有一个成员拥有一段代码,任何人都可以随时对代码库进行更改。这鼓励每个人为项目的所有部分贡献新的想法。

    9、持续集成:软件系统一天建成并集成数次;至少所有变更都集成到主集成平台的主代码库中,至少每天一次。因此,每天都有很多产品构建。每个构建都使用相关的测试用例进行测试。

    10、40小时制:XP项目中的程序员通常坚持每周工作40小时,以保持生产力并避免加班。人们发现,在加班工作的紧急时期,产品的质量很差。

    11、现场客户:将使用正在构建的系统的一个或多个客户分配给开发团队。客户有助于指导开发,并有权优先考虑,还可以说明需求并回答开发人员可能遇到的任何问题。这确保了与客户进行有效的沟通,这样需要的文件就更少了。

    12、编码标准:XP项目中的每个人都使用相同的编码标准,从而可以轻松地成对工作并共享所有代码的所有权。开发成员不应该能够分辨出谁在XP项目中使用了哪些代码。应该定义并遵循商定的编码标准。

    转载请注明出处!

     

    展开全文
  • 在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。 -- Jack Reeves 简介 2001年,为了解决...敏捷开发过程的方法很多,主要有:SCRUM,Cryst
      在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。
    -- Jack Reeves
    简介
      2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

    极限编程

      设计和编程都是人的活动。忘记这一点,将会失去一切。
    -- Bjarne Stroustrup

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

    下面是极限编程的有效实践:
    1. 完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
    2. 计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
    3. 客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
    4. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
    5. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
    6. 测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
    7. 改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
    8. 持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
    9. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
    10. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
    11. 隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
    12. 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。
    敏捷开发
      人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。
    -- Tom DeMacro和Timothy Lister

    敏捷软件开发宣言:
    • 个体和交互     胜过 过程和工具
    • 可以工作的软件 胜过 面面俱到的文档
    • 客户合作       胜过 合同谈判
    • 响应变化       胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。
    • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    • 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    • 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
    • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    • 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
    • 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
    • 工作的软件是首要的进度度量标准。
    • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    • 不断地关注优秀的技能和好的设计会增强敏捷能力。
    • 简单是最根本的。
    • 最好的构架、需求和设计出于自组织团队。
    • 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
    当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。
    • 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
    • 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
    • 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
    • 粘滞性: 做正确的事情比做错误的事情要困难。
    • 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
    • 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
    • 晦涩性: 很难阅读、理解。没有很好地表现出意图。
    敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:
    • 单一职责原则(SRP)
      就一个类而言,应该仅有一个引起它变化的原因。
    • 开放-封闭原则(OCP)
      软件实体应该是可以扩展的,但是不可修改。
    • Liskov替换原则(LSP)
      子类型必须能够替换掉它们的基类型。
    • 依赖倒置原则(DIP)
      抽象不应该依赖于细节。细节应该依赖于抽象。
    • 接口隔离原则(ISP)
      不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
    • 重用发布等价原则(REP)
      重用的粒度就是发布的粒度。
    • 共同封闭原则(CCP)
      包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
    • 共同重用原则(CRP)
      一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
    • 无环依赖原则(ADP)
      在包的依赖关系图中不允许存在环。
    • 稳定依赖原则(SDP)
      朝着稳定的方向进行依赖。
    • 稳定抽象原则(SAP)
      包的抽象程度应该和其稳定程度一致。
      上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。

    下面举一个简单的设计问题方面的模式与原则应用的示例:

    问题:
      选择设计运行在简易台灯中的软件,台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着,也可以让灯打开或关闭。

    解决方案一:
      下面图1是一种最简单的解决方案,Switch对象可以轮询真实开关的状态,并且可以发送相应的turnOn和turnOff消息给Light。


    解决方案二:
      上面这个设计违反了两个设计原则:依赖倒置原则(DIP)和开放封闭原则(OCP),DIP原则告诉我们要优先依赖于抽象类,而Switch依赖了具体类Light,对OCP的违反是在任何需要Switch的地方都要带上Light,这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案,可以采用ABSTRACT SERVER模式,在Switch和Light之间引入一个接口,这样就使得Switch能够控制任何实现了这个接口的东西,这也就满足了DIP和OCP原则。如下面图2所示:



    解决方案三:
      上面图2所示解决方案,违返了单一职责原则(SRP),它把Switch和Light绑定在一起,而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决,适配器从Switchable 派生并委托给Light,问题就被优美的解决了,现在,Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示:



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

     
    ======================================================
    在将什么是极限编程之前,咱们先来讨论一下,当今信息技术中最迫切的两个问题是:
    How do we deliver functionality to business clients quickly?
    如何能快速地向商业用户交付功能?

    How do we keep up with near-continuous change?
    如何才能跟上近乎连续的变化?
       变化本身也在不断地变化中。不仅仅是变化的速度在不断地提高 ,已经成为电子商务支柱的Internet, 就已使大范围的行业产生剧变--更多的是打断的平衡而不仅仅是一次剧变。当整个商业模式正在发生变化,当"时间意味着市场"正成为公司的咒语,当适应性与互连性正在成为甚至是最呆板的组织的需要的时候,我们将有必要检查以下的每一个方面:
        1.商业是如何管理的,
       2.客户为什么而感到高兴,
       3.以及产品是如何开发的。

    终极编程(Extreme Programming )运动成为面向对象编程这个团体的一部分已经有数年了, 但是直到最近才引起了越来越多的注意,特别是最近Kent Beck的《终极编程 释义:拥抱变化》(Extreme Programming Explained: Embrace Change)一书的出版。

    有一种趋势,特别在那些严格的方法论者中,希望剔除那些与"能力 成熟度模型"(Capability Maturity Model CMM)或者是国际标准化组织的标准相比不那么笨重的方法,比如象hacking.注释: hacking推崇行动而不是思考从而导致了较低的质量。 剔除与某人关于这个世界的假设相冲突的实践,这倒不失为一种简单的方法。
    从另一个角度来看XP,它倒可能是一个难题的某个潜在的部分,这个一个我在过去18个月中一直都在写的内容。混乱 的时期产生新的问题,而后者又导致了新的实践--新的实践公然违抗 传统的知识,但却得以幸存下来是因为它们能更好地适应这个新的现实世界。至少有四种实践方式我觉得是属于这个范畴的:
    XP
    轻量级的开发(Lean development)
    轻量级的Crystal方法(Crystal Light methods
    自适应软件开发(Adaptive software development)

    我必须承认一件事情,就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。他们通常对于自己的要求都是很谨慎的。例如:小的(小于10人),公司局部(他们有直接的经验)两者对于XP的适应性都是很明显的;他们并没有试图让人们相信XP可以适用于一个200人的团队。


    xp基础---工程
    最为著名的XP项目是克莱斯勒综合补偿系统(Chrysler Comprehensive Compensation system称为C3工程)。
    最初,C3是一个基于OO(面向对象技术)的开发项目,尤其是它采用Smaltalk语言进行开发。作为著名的Smalltalk专家,Beck被邀请来讨论有关SmalTalk性能优化的问题,并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO(XP)方法的试验性项目。Beck并且带来了Jeffries用于帮助那些基本的东西,Jeffries在C3组一直干到1999年的春天。最开始的需求是要做一个对约10,000个雇员每月薪水发放进行管理的系统。这个系统由大约2,000个类以及30,000个方法构成,并且在计划方面提供有合理的容忍度 。当有人问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。他笑着告诉了我。多年来我为许多大型IT组织开发了不少RAD系统(快速原型开发),因此我知道为什么我们无法将成功的经验运用于其它项目中. 对于RAD, XP, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.

    xp基础---实践
    应记住的一件事情就是我们应倾向于在小型的, 局部的团队中运用XP。除了代码与测试用例外, 尽量减少有些的影响。XP的实践既有正面的表现,也有负面的。在某些方面看来,他们听起来就像一堆规则,要做这个,不要做那个。对此Beck解释道, 与规则相比, XP更像是指导方针,一个灵活的依赖于具体环境的开发方针。但是诸如“每周工作40小时”等看起来可能会感觉絮絮叨叨。Jeffries使得实践也会互相作用的,平衡,互相加强。以至于挑选使用的同丢弃的都是棘手的事情。

    计划的制定:XP中关于制定计划的实现方法中可以反映出大多数迭代式RAD项目的特点。短期的,每三周为一个循环,频繁地更新,按优先级划分任务与技术, 分配stories(一个story定义了一个特殊的功能需求并以一种简单的方式记录在卡片上),所有的这些就是构成了XP中的计划。

    小版本:“每个版本应该尽可能的小,而且包含最有商业价值的需求”,Beck如是说。这也反映了Tom Gilb在他的<软件工程管理原则>书中提到的关于渐进式发布的两点:“所有的大的项目都可以被分为局部的, 有用的小的步骤”以及“进化的步骤会传递到下一级。”小型版本的发布意味着具有在大型项目中经常缺少的频繁的反馈的实现.。 然而,一个开发小组当然需要考虑到“发布”同“可发布”的不同。无论是否是最终的版本发布还是一个简单的可发行版本的发布, 都需要付出安装,培训,转化等代价。

    隐喻:在XP中“隐喻”以及“story”的使用可能会让人有一点不舒服。但是,这些术语的使用可以帮助我们以一种更人性化的方式加以理解,尤其是对客户而言。从某种程度上来说,隐喻同体系结构是同意语――他们都着重于从全局描述一个项目。但是体系结构经常会陷于符号与连接的泥潭。而XP使用“隐喻”定义一个从开发者到商业客户都可联系的全面一致的主题。隐喻用于描述项目全面的面貌,而Story用于描述个别具体的特征。

    简单的设计:简单的设计包含两个部分。一,为已定义的功能进行设计,而不是为潜在地未来可能的功能进行设计。二,创建最佳的可以实现功能的设计。换句话说,不用管未来会是怎样,只创建一个目前为止可以实现的最好的设计。“如果你相信未来是不确定的,并且你相信你可以很方便的改变你的主意的话,那么对未来功能的考虑是危险的。”Beck写到。“只有在你真正需要的时候才去做“。 数据的质量是使用功能,不是捕捉与存储。此外,我说数据如果不是很系统的使用便会变坏。数据质量是系统使用的功能,不是可预料的设计。无论预期的对还是错,试着设计一个我们从来都不会用到的数据,最终结果很可能我们一次也不会用到它们。XP的简单设计方法反映了相同的观点。如在本文后来所描述的那样,这并不意味着不需要预测,而是说为预测的内容所做的设计一旦发生变化,其导致的代价是十分巨大的。


    重构:如果我不得不找出一个能够将XP和其他方法区别开来的东西那就是重构――不断的软件再设计以改进它对于变化的反应。RAD方法常常很少甚至根本不与设计相关;XP应当被看作持续设计。当变化既快而且频繁的时候,应投入更多的精力于重构之上。参见下面的“重构”和“数据重构”部分。


    测试:XP充满发人深思的有趣的难题。例如:什么是“先测试后编码”?在一些软件公司是通过代码的行数来对程序员的绩效加以考核,而测试的绩效则是通过发现的缺陷的数量来考核的。这两种方法都不能鼓励减少测试前产生的缺陷的数量。XP使用两种测试:单元测试和功能测试。单元测试要求在写代码之前就开发出相应功能的测试方法,并且测试应当是自动化的。代码一完成,它就被立即用有关测试集加以测试,从而能立即得到反馈。

    配对编程:代码检查(还是直接用Inspection为好?)(也称审查或走查)也是被广为接受(至少在理论上)和有效度量的少数软件工程实践之一。在最好情况下,Inspection这种协同交互的检查能够加速学习,同时发现缺陷。一个较少被知道的关于Inspection的统计数据是尽管它在发现缺陷方面非常有效,但通过团队对于好的开发实践持续的学习和协作,可以更好的在第一时间预防缺陷。 一家软件公司客户引用一个内部研究结果,表明在测试阶段发现一个缺陷需15小时,在Inspection阶段发现一个缺陷则需2-3小时,而在Inspection之前发现缺陷只需15分钟。后面的数据来自于产生于常规审查的持续的团队学习。配对编程将这个带入下一步――与其用Inspection来递增式学习,为什么不用配对编程来学习呢? “配对编程是两个人试图同时编程和理解如何更好编程的一种对话”,Beck写道。让两个人同时坐在一台终端前面(一个人敲代码或测试用例,一个人审查和思考)产生一种持续的、动态的交流。Williams在犹他大学进行的博士论文研究证明了配对编程不仅仅是一种美好的想法而且确有实效。


    代码共享:项目组中的每个人都可以在任何时候修改其他项目成员的代码,这就是XP中所定义的代码共享。。对许多程序员以及经理而言,,共有代码的想法会引起一些疑虑,诸如"我不想让那些笨蛋改我的代码","出现问题我应该怪谁?"等等。共享代码从另一个层面提供了对配对编程中协作的支持。

    经常集成:每日构造(build)在许多公司已经成为规范,许多公司将每日编链作为最小要求,XP实践者将每日集成作为最大要求,选择每两个小时一次的频繁编链。XP的反馈周期迅速:开发测试集、编码、集成(编链)和测试。 对于集成缺陷危险的认识已有多年了,但我们并不是总能拥有相应工具和时间将这些知识好好用起来。XP不仅提醒我们有可能有严重的集成错误,而且从实践与工具的角度提供了一种新的认识。


    每周只干40小时:XP有12条实践的基本原则,但是有时候,比如象每周只干40小时的原则,听起来更象规则。我同意XP中的观点。只是不认为有必要硬性规定工作小时数。相比起来,我更喜欢一句类似于“不要把部队烧光”的话。在一些情况下,工作40小时太劳累,而在另外一些组里,甚至需要一周60个工作时。 Jeffries提供了关于加班的更多思索:"我们说的是加班被定义为我们不想在办公室的时候呆在办公室。而且你不应当加班超过一周。如果你超过了,就有什么东西出了问题――你过于劳累,有可能比你按时下班干的还差。我同意你关于60工作时一周的感受。在我们年轻和满身干劲的时候,这也许没问题。值得注意的是拖沓的一周又一周。" 我不认为一周的工作时间会造成大的差别。决定区别的是自愿的贡献。人们愿意来工作吗?他们对每一天都充满干劲吗?人们必须来工作,但是他们通过投入项目来创造巨大成就,而投入仅仅产生于目标感。

    现场客户:这就对应到了最初软件开发时所提出的问题――用户参与。XP,同其他的快速开发一样,要求客户在现场持续地参与到项目组中。


    编码标准:XP实践相互支持。例如,如果你进行配对编程并让他人修改共有代码,那么编码标准看起来就是必须的。


    价值和规则
    在2000年一月一日周六时候,华尔街日报(周一到周五出版的)用一个58页的版面发布了一个千僖年纪念版。在篇首的有关工业及金融的介绍里标着Tom Petzinger.写的:“长久的需求与召唤:经济新的增长点――显得同以往不同”。底下的一行 Petzinger 写着:“创造性正代替'万金药’的资本在成为首要的因素”。 Petzinger并没有谈论少数天才的创造性,而是谈了以下群体的创造性――从组到部门。一旦我们撇下天才们的个体创造,创造性就是环境的功能,而人们运用并互相协助而达到我们的结果的能力。如果你的公司认为软件开发只是一个统计上的重复试验,刻板的,技术性的过程,那么XP对于您也许并不合适。虽然XP中也有技术实践里的严格,但是XP本身是追求"创造"与"沟通"。

    环境是靠价值同规则共同驱动的系统。XP(或者其他类似的)可能、也可能不适合您的单位,可是,应该澄清的是成功并不是只靠每周40小时的疯狂工作或者配对编程,也不是依靠XP之中应用在您单位中的价值或者是规则。 Beck指出了四个价值,五个基本规则,以及十个辅助规则--不过我要提到是这五个规则。

    沟通:是的,沟通,可是,这里似乎没有新的东西在里面?沟通主要是看人们自己的看法,XP构建的基本是人与人,通过最简洁的文档,最直接的面对面沟通获得对任务环境的理解。


    简洁:XP问每个开发组成员:“可能实现的最简洁的方法是什么?”。今天所保持的简洁,可以降低明天由于变更所带来的费用

    反馈:Beck说:"对于编程而言,乐观主义是一种冒险。","而反馈则是相应的解决良药。"无论是用反复的构建或者频繁的用户功能测试,XP都能不断地接收到反馈。虽然每次对软件开发策略进行研讨时,我们都会说及反馈--即使是非常有害的瀑布模型--不同的是XP的实践者认为反馈比起前馈(feedforward)来更为重要。无论是对测试失败的代码进行修改或者是对用户拒收的软件从新返工,开发环境的快速变化要求开发人员对反馈有更好的认识。

    勇气:无论您是使用CMM方法或者是XP的方法,方法使用的本身是要求勇气的。许多地方将勇气定义为做某件事情的权利,即使被迫去做其他的事情。开发人员经常借口压力而发出带有许多缺陷的产品,并对此加以坚持。然而,更进一步的应该包括其他的正确的不同的东西进来。通常,人们并不是缺少勇气,而是缺少一种让正确实践获得承认的理由,而且,也不坚信这点,勇气不像看起来那么重要。而如果你对之没有信心,那么是很难尽力工作的。 "勇气并不只是方法",Jeffries说道,它是一种最终的价值。如果你在一种基于"沟通","简洁","反馈"的模式下工作,你将获得勇气,越往前信赖就越不重要。

    优质的工作:好,如果你们中有赞成劣质工作的话,那么请举手离开这儿吧。不论你是一个Rational Unified Process,CMM,或是XP的赞成者,其本质的观点"你怎样定义质量"与"什么样的活动会赢得高质量",定义"无缺点"质量是这个问题的一个方向。Jerry Weinberg的定义是"质量是对多数人有益"
     
    ===============================
    http://www.javaeye.com/post/62538
    ================================
     
     

    在一起做一段时间不就熟悉了吗,这个反对理由不充分。再说了,都已经是一个公司的了,还在一个团队里,沟通还算是问题吗?

    我们在开发过程中采用了xp的方法,并且在开发过程中也有新人加进来,只要是不对xp的方法有抵触心理(不排除有这样的人),每天一起PP,很快就能融入到团队中。并且通过PP,整个团队也会互相熟悉起来,增进了解,这是一个渐进的过程。

    要有一个适合xp的工作环境,包括硬件环境和软件环境。硬件环境就是在一台机器前有足够的空间坐下两个人,如果不PP就无所谓了。重要的是软件环境,比如CVS,bugtrack,能够快速频繁运行的单元测试等等,这些最好能有人来把关,建议在项目中用maven,每天能生成很多报告,比如checkstyle的,可以看看谁的代码格式不符合规范,还有什么包依赖的检查啊,代码重复的检查啊,单元测试覆盖度啊等等。


    展开全文
  • 极限编程最佳实践的深入研究 目录极限编程概述... 1极限编程的力量源泉... 2极限编程的真谛... 4极限编程的假设... 4极限编程的真谛... 6极限编程的最佳实践... 11首先,是计划阶段... 11然后,是开发
  • (Source: User Stories) 用户故事与用例具有相同的用途,但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写,作为系统需要为他们执行的操作。它们与使用场景类似,...
  • 极限编程在WEB开发中的作用 当我写下这个题目的时候就纠结了,好吧,我还是解释下为什么C++论文会写WEB开发,当然我还没那个水平直接用C++来做WEB开发。只是当我想写极限编程这个题目的时候发现原来这是一个软件...
  • 敏捷开发简介

    2012-08-14 14:17:04
    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐,在全球一百强的企业中,敏捷也已大行其道,受到许多资深项目管理者和开发人员的推崇。欧美软件企业中,有近半企业已采用敏捷...
  • 敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • 敏捷软件开发揭秘

    2019-05-13 00:21:31
    本篇文章将对敏捷软件开发的方法论及其应用做基本介绍,将描述团队是如何通过协作来完成共同目标的。本篇文章不仅仅适合软件开发人员阅读,同时也适合于团队负责人、项目经理、产品经理、开发经理、测试人员、QA经理...
  • 极限编程概述

    2011-06-28 00:31:00
    极限编程(Extreme Programming,简称XP)是目前讨论最多、实践最多、争议也是最多的一种敏捷开发方法。XP是一套能够快速开发高质量软件所需的价值观、原则和活动的集合,使软件能以尽可能快的速度开发出来并向客户...
  •  李新[2]提出了一个支持敏捷过程的软件开发平台,该平台包括一系列敏捷开发工具,敏捷组件、敏捷表单、敏捷查询等,实现了系统设计标准化,能够支持在大型信息化项目中采用敏捷开发过程。徐照兴等[3]研究了敏捷发发...
  • 敏捷开发简史

    2019-06-26 19:36:56
    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐,在全球一百强的企业中,敏捷开发也已大行其道,受到许多资深项目管理者和开发人员的推崇。到2008年,欧美软件企业中,有近半...
  • 新方法学-敏捷开发

    2007-02-13 14:19:00
    胡健(转载自敏捷中国) 2003年09月15日 过去几年中兴起的敏捷型(agile〕(也被称之为“轻量型”,lightweight) 的软件开发方法,以矫正官僚繁琐过程、许可对过程进行自主调整为特征, 在软件业引起了极大的兴趣。...
1 2 3 4 5 ... 20
收藏数 775
精华内容 310
关键字:

敏捷开发极限编程论文