极限编程 - 附加特性



本章我们将学习极限编程的一些附加特性。

反馈循环

极限编程的魅力在于持续的反馈,它让每个人都保持专注,开发工作持续朝着正确的方向前进,避免延误。

在极限编程中,反馈是在不同层面上实现的,达到必要和足够的细节。这在迭代和发布过程中都是持续不断地进行的。

下表列出了反馈事件和反馈持续时间。

反馈事件 反馈持续时间
结对编程
单元测试 分钟
团队内部及与客户间的澄清 小时
进度 一天内
验收测试
迭代计划
发布计划

项目管理

在极限编程中,项目管理并未被特别强调,管理者的角色只执行最少且最必要的管理活动。

然而,这些活动包含了项目管理的要求。

  • 发布计划

    • 范围由用户故事卡片中的用户故事定义。

    • 估算为故事估算,可以以故事点表示。

    • 交付里程碑由发布计划捕获。

    • 发布被分成迭代。

  • 迭代计划

    • 故事在任务卡片中分解成任务。

    • 估算为任务估算。

    • 任务分配通过平衡团队的负载因子来完成。

    • 任务验收由团队承诺和责任制来保证。

  • 跟踪

    • 项目层面根据实际执行时间以故事点衡量速度。

    • 开发人员层面根据实际执行时间以任务估算衡量生产力。

    • 缺陷跟踪

极限编程 – 行业经验

从业界执行的极限编程项目中,有一些对团队有用的经验教训。

从XP实践中学习到的经验

在接下来的部分,您将了解这些经验教训。

  • 简单设计 − 简单设计高效、易于构建和维护。

  • 隐喻 − 使用隐喻的主要目的是在整个开发过程中使用特定领域的名称,这使得客户也能积极参与开发。

  • 集体所有制 − 每个人都为自己的优秀代码感到自豪。通过合作,每个人都为所有人的代码感到自豪。

  • 计划 − 如果团队在一个迭代中完成了许多用户故事,则缩小迭代规模。让团队达成共识来修改计划。

极限编程的扩展

最初,极限编程被认为在较小的团队中有效,团队规模最多为12-16名开发人员。

后来,人们观察到极限编程可以扩展到40-50人的团队。但是,建议通过构建递归团队来进行扩展。首先构建一个小型团队,然后逐步扩大团队规模,使用第一个团队来为递归团队播种。

文档

极限编程并不反对任何文档。它鼓励记录必要的内容,在必要时记录,并且只记录必要和足够的细节。这可能因项目而异,项目需要决定文档的范围。但是,极限编程实践不允许跳过文档。

应用XP的优势

极限编程在以下情况下被认为是有优势的:

  • 高度不确定的环境

  • 内部项目

  • 合资企业

应用XP的劣势

极限编程在以下情况下被认为是有劣势的:

  • 环境庞大而复杂。

  • 需求已被充分理解。

  • 客户距离遥远或无法联系。

对XP的误解

关于极限编程存在一些误解。下表对这些误解进行了澄清。

误解 澄清
没有书面文档 需要最少且足够的文档。但是,对于需要多少或什么类型的文档没有正式标准。
没有设计 需要最少的显式和预先设计,并在开发过程中不断演变。
极限编程只是结对编程而且很简单 结对编程只是极限编程实践之一。它需要高度的纪律性和一致性,这只有与其他极限编程实践结合才能实现。
极限编程是构建软件的唯一正确方法 极限编程只在特定类型的项目中有效。
广告