敏捷XP,不是Windows XP,它是Scrum的兄弟

2020年03月23日讲师:刘通浏览:583次

敏捷大师Kent Beck和Ward Cunningham在上个世纪90年代末期发明一种敏捷工程技术,即极限编程(XP)。极限编程的英文全称是eXtreme Programming,简称XP。之所以叫XP而不是EP的原因,是因为EP很容易和其他混淆,比如EP是大碟的意思,音乐界用的。另外express单词的缩写也是X,这是英文的习惯,因为ex的读音和x读音类似。在XP中创造性地提出用户故事(User Story)、测试驱动开发(TDD)、持续集成(CI)、结对编程(Pair Programming)和迭代(Iteration)等诸多概念,可以认为XP对Scrum框架进行了必要的技术细节补充。目前应用Scrum+XP的敏捷企业比较多,正是因为两个理论有互补性的特点。很多敏捷大师在2001年共同组建了敏捷联盟,并发布了敏捷宣言和基本原则。XP的价值观保持与敏捷宣言相一致的同时,也发明了符合自己特质的原则或价值观,比如沟通、简单、反馈、尊重和勇气等。其中尊重和勇气的原则与Scrum相同。沟通强调用户和程序员频繁合作,必要时采取隐喻,即比喻或打比方的方法找到双方都能够理解的切合点进行高效沟通。用户故事(User Story)及INVEST原则来自极限编程。在XP中反馈很重要,比如持续集成和结对编程都形成了很好的反馈环路,因为他们都可能造成每天发生多次反馈。持续集成关联自动化测试,敏捷大师Jim Highsmith曾提出:“经验表明,成熟和不成熟的敏捷团队之间最大的区别在于他们致力于无情的自动化测试的程度不同”。与此同时,XP的另一个实践结对编程也会每天时刻都可能反馈针对开发代码的测试或修订意见。更多的XP的最佳实践详见如下图例:以下是针对上图的典型XP实践内容的概览描述:整个团队(The whole team):T型技能,即一专多长,对应自组织团队。简单设计(Simple design):目的是让工程团队基于已知知识而不是基于对未知预测而设计,即基于当下,立足眼前。由于VUCA时代的到来,完美的计划未必会产生完美的产品。对未来的适应性的设计调整比一味的对未来加以预测的方式更有价值,从而简单设计也是一种风险减轻的方法。计划游戏:对需求进行细分的方法,评估工作优先级和工作投入量,以创建发布计划。关联发布计划(Release planning)和迭代计划(Iteration planning)的制定过程。共享代码所有权(Collective Code Ownership):代码为团队共同所有,开发人员可以加强或改进任何其所在团队中的其他人的代码。隐喻(Metaphor):通过打比方的形式,创建一个共享的技术愿景。比如把软件比作BUG,把障碍比作阻挡船航行的锚或山。大师Jim HighSmith把消除障碍比作移山(愚公移山),把提供资源比作引水(大禹治水)。有节奏的步骤(Sustainable Pace):关联有节奏的开发原则,对应敏捷原则。代码重构(Refactoring):在不改变外部接口调用和可行性功能的同时对内部代码逻辑进行不断的优化。代码重构关联XP的勇气的文化。持续集成(Continuous Integration):持续集成的目标是在开发期间尽早、经常地确保产品特性组合成一个整体,从而减少以后无法组合造成的高成本和测试负担。所以开发人员最好主干开发和每日提交新增代码到主干,即每天在程序主干上Check-in,一旦Check-in代码,自动化测试平台就可以即时的测试和提供测试结果的反馈。 总之,敏捷XP的实践是最为流行的Scrum敏捷方法论的有力补充,并在软件开发领域起到了“去伪留真”的作用,这种功效具体体现在我们耳熟能详的实践中,比如用户故事、持续集成、代码重构、结对编程、以小版本发布为代表的探针和试错等……
分享 0

您已经赞过了!