全国购物网站排名,如何替换网站ico图标,营销推广型网站价格,监控网站开发目录 前言
极限编程
四大价值观
沟通
简单
反馈
勇气
尊重#xff1a;
十二个最佳实践
计划游戏
小型发布
隐喻
简单设计
测试先行
重构
结对编程
集体代码所所有制
持续集成
每周工作40小时
现场客户
编码标准 前言
2001年2月#xff0c;在美国的犹他州…目录 前言
极限编程
四大价值观
沟通
简单
反馈
勇气
尊重
十二个最佳实践
计划游戏
小型发布
隐喻
简单设计
测试先行
重构
结对编程
集体代码所所有制
持续集成
每周工作40小时
现场客户
编码标准 前言
2001年2月在美国的犹他州17位“无政府主义者”共同发表了《敏捷软件开发宣言》在宣言中指出
尽早地、持续地向客户交付有价值的软件对软件开发人员来说是最重要的。拥抱变化即使在开发的后期。敏捷过程能够驾驭变化保持客户的竞争力。经常交付可工作的软件从几周到几个月时间范围越小越好在整个项目中业务人员和开发者紧密合作围绕士气高昂的团队进行开发为团队成员提供适宜的环境满足他们的需要并给予足够的信任在团队中最有效率的、也是效果最好的沟通方式是面对面地交流可以工作的软件是进度首要的度量方式可持续地开发投资人、开发团队和用户应该保持固定的节奏不追求优秀的技术和良好的设计有助于提高敏捷性要简单尽可能减少工作量。减少工作量的艺术是非常重要的最好的架构、需求和设计都来自于一个自我组织的团队团队要定期地总结如何能够更有效率然后相应的自我 调整 极限编程
XP方法可以说是敏捷联盟中最鲜艳的一面旗帜也是相对来说最成熟的一种。XP方法的雏形最初形成于1996-1999年。
XP是一种轻量、敏捷、高效、低风险、柔性、可预测、可行而且充满乐趣的软件开发方式。与其他方法论相比其最大的不同在于
在更短的周期内更早地提供具体、持续的反馈信息迭代地进行计划编制首先在最开始迅速生成一个总体计划然后在整个项目开发过程中不断地发展它。依赖于自动测试程序来监控开发进度并及早地捕获缺陷依赖于口头交流测试和源程序进行沟通倡导持续的演化式的设计依赖于开发团队内部的紧密协作尽可能达到程序员短期利益和项目长期利益的平衡
XP由价值观、原则、实践和行为四个部分组成他们彼此相互依赖关联并通过行为贯穿整个生命周期
四大价值观
XP的核心是其总结的沟通、简单、反馈、勇气四大价值观它们是XP的基础也是XP的灵魂。
沟通
通常程序员给人留下的印象就是内向、不善言辞项目中的许多问题就出在这些缺乏沟通的开发人员身上。由于某个程序员做出了一个设计决定但是却不能够及时沟通团队中的其他成员结果使得团队在协作与配合上出现很多麻烦。而在传统的开发方法中并不在意这种口头沟通不畅的问题而是希望借助于完善的流程和面面俱到的文档、报表、计划来替代但是这又引入了效率不高的新问题。
XP方法认为如果小组成员之间无法做到持续的无间断的交流那么协作就无从谈起。从这个角度来看通过文档、报表等人工 制品进行交流具有很大的局限性。因此XP组合了诸如结对编程这样的最佳实践鼓励大家进行口头交流通过交流解决问题提供效率。
简单
XP方法在工作中秉承“够用即好”的思路也就是尽量的简单化只要今天够用就行不考虑明天会出现的新问题。这一点看上去十分容易但是要真正做到保持简单的工作其实是很难的因为在传统的开发方法中都要求开发人员对未来做一些预先规划以便对今后可能发生的变化预留一些扩展空间。
沟通和简单之后还有一种相当微秒的互相支持的关系。一方面团队成员之间的沟通得越多就越容易明白那些工作需要做那些工作不需要做另一方面系统越简单需要沟通的内容也就越少沟通也将更加全面。
反馈
是什么原因使得客户、管理层这么不理解开发团队究其原因就是开发的过程中缺乏必要的反馈。在很多项目中当开发团队经历过需求分析之后在一个相当长的时间段中是没有任何反馈信息的。整个开发过程对于客户和管理层而言就像一个黑盒子进度完全看不到。而且在项目开发过程中这样的现象不仅出现在开发团队与客户、管理层之间还包括在开发团队内部。因此开发团队需要更加注重反馈。反馈对应任何软件项目的成功都是至关重要的而在XP方法论中则更进一步通过持续、明确的反馈来暴露软件状态的问题。
反馈与沟通有着良好的配合及时和良好的反馈有助于沟通。而简单的系统更有利于测试和反馈。
勇气
在应用XP方法时每时每刻都在应对变化由于沟通良好会有更多需求变更的机会由于时刻保持系统的简单新的变化会带来一些重新开发的需要由于反馈及时会有更多中间打断思路的新需求。总之这一切使得开发团队处于变化之中因此这时就需要有勇气来面对快速开发面对可能的重新开发。勇气可以来源与沟通因为它使得高风险高回报的试验称为可能勇气可以来源于简单因为面对简单的系统更容易鼓起勇气勇气可以来源与反馈因为可以及时获得每一步前进的状态自动测试会让人更勇于重构代码。
尊重
在XP的四大价值之下隐藏着一种更加深刻的东西就是尊重。因为这一切的准则都建立在团队成员之间相互关心相互理解的基础之上。
十二个最佳实践
在XP中集成了12个最佳实践大多数概念和编程一样老。主要的创新点在于提供一种良好的思路将这些最佳实践结合在一起并且确保尽可能彻底地执行使得他们能够在最大程度上相互支持。
计划游戏
计划游戏的主要思想就是先快速地制定一份概要计划然后随着项目细节的不断清晰再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。
小型发布
XP方法秉承的是“持续集成小步快走”的哲学思维也就是说每一次发布的版本应该尽可能地小当然前提条件是每个版本有足够的商业价值值得发布。由于小型发布可以使的集成更频繁客户获得的中间结果越频繁反馈也就越频繁客户就能够实时地了解项目的进展情况从而提出更多的意见以便在下一次迭代中计划进去以实现更高的客户满意度。
隐喻
相对而言隐喻比较令人费解。根据词典中的解释是“一种语言的表达手段它用来暗示字面意义不相似的事物之间的相似之处”。隐喻常用的四个方面寻求共识发明共享词汇、创新的武器、描述架构。
简单设计
强调简单的价值观引出了简单性的假设原则落实实处就是“简单设计”实践。这个实践看上哪去似乎很容易理解但是却又经常被误解许多批评者就指责XP忽略设计是不正确的。其实XP的简单设计实践并不是要忽略设计而是认为设计不应该在编码之前一次性完成因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上。
测试先行
对于有些团队而言有时候程序员会以“开发工作太紧张”为理由继而忽略测试工作。这样就导致了一个恶性循环越是没空编写测试程序代码的效率与质量越差花在找缺陷解决缺陷的时间也就越来越多实际产能大大 降低。由于产能降低因此时间更紧张压力就更大。
重构
重构是一种对代码进行改进而不影响功能实现的技术XP需要开发人员在“闻到代码的坏味道”时就有重构代码的勇气。重构的目的是降低变化引发的风险、使得代码优化更加容易。
结对编程
从20世纪60年代开始就有类似的 实践在进行长年以来的研究结果给出的结论是结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度但是慢慢的开发的速度会逐渐加快。究其原因主要是结对编程大大降低了沟通的成本提供了工作的质量。结对编程技术被誉为XP保证工作质量、强调人文主义的一个最典型的 实践应用得当还能够使开发团队协作更加顺畅、知识交流与共享更加频繁、团队稳定性也会更加牢固。
集体代码所所有制
由于XP方法鼓励团队进行结对编程而且认为结对编程的组合应该动态地搭配根据任务的不同、专业技能的不同进行更优组合。因此每一个人都会遇到不同的代码代码的所有制就不再适合于私有因为那样会给修改工作带来巨大的不便。所谓集体代码所有制就是团队中每个成员都拥有对代码进行改进的权利每个人都拥有全部代码也都需要对全部代码负责。同时XP强调代码是谁破坏的修改后出现问题就应该谁来进行修复处理。
集体代码所所有制是XP与其他敏捷方法的一个较大的不同也是从另一个侧面体现了XP中蕴含的很深厚的编码情节。
持续集成
在前面谈到小型发布、重构、结对编程、集体代码所所有制等最佳的实践多次提到持续集成可以说持续集成是这些最佳实践的基本支撑的条件。
每周工作40小时
这是最让开发人员开心管理者反对的一个最佳实践了加班再加班早已经成为开发人员的家常便饭也是管理者最常使用的一种策略。而XP方法认为加班最终会扼杀团队的积极性最终导致项目的失败这也充分体现了XP方法关注人的因素比关注过程的因素多一些。
现场客户
为了保证开发出来的结果与客户的预想接近XP方法认为最重要的是需要将客户请到开发现场。就像计划游戏中提到一样在XP项目中应该时刻保证客户负责业务决策开发团队负责技术决策。因此在项目中有客户在现场明确用户故事并作出相应的业务决策对于XP项目而言有着十分重要的意义。
编码标准
拥有编码标准可以避免团队在一些与开发进度无关的细枝末节的问题上发生争论而且会给重构结对编程带来很大的麻烦。不过XP方法的编码标准的目的不是创建一个事无巨细的规则列表而是要能够提供一个明确代码清晰便于交流的指导方针。
最后有句话112最适合表达XP的观点XP方法的最大价值在于在项目中融会贯通地运用这12个最佳实践而非单独的使用。当然可以使用其中的一些实践但是这并不意味着就应用了XP方法。XP方法真正能够发挥其效能就必须完整地运用12个实践。
