XP如何解决开发过程中的风险呢？

— 进度延迟——XP提倡短发布周期。一个发布周期最多几个月，这样，任何延迟的范围都是有限的。在一个发布周期内，XP使用客户要求的功能的每周迭代来形成关于进度的详细反馈。在一个迭代内，XP计划许多小的任务以保证团队可以在该周期内解决问题。最后，XP还提倡优先实现高优先级的功能，这样可以保证在发布版本中错过的功能的价值比较低。

— 项目取消——XP中的最小发布必须是满足最大商业意义的，选择工作由团队中面向业务的成员来承担。这样，在部署之前出错的可能就会较少，同时也保证了软件的价值最大。

— 系统恶化——XP中创建并维护一整套自动测试，每次系统发生改变后都要运行（一天好几次）这些测试，以确保质量底线。XP总是保证系统处于可部署的状态，而不允许出现问题的积累。

— 缺陷率——XP中既包括了程序员书写的每个函数（function）的测试，也包括了客户书写的对每个程序特性（program-feature）的测试。

— 业务误解——XP提倡业务人员成为团队成员。项目规格说明（specification）在开发过程中不断改进，因此客户和团队的知识都能反映在软件中。

— 业务变更——XP缩短了发布周期，因此在一个单独的发布周期中几乎没什么变更。在发布期间，客户可以随意用新的功能替代还未完成的功能。开发团队甚至不会注意到他们是在开发一个新发现的功能还是几年前就定义的特性。

— 错误特性太多——XP坚持只解决最高优先级的任务。

— 人员流动——XP要求程序员估算自己工作所需时间并完成。同时XP也将这些工作的实际完成时间返回给程序员，帮助他们改善估算的精确性，从而使估算的结果得到尊重。在XP中，谁能做出估算，谁能改变估算都很清楚，因此程序员几乎不会因为被要求去完成明显不可能完成的任务而感到沮丧。XP同样鼓励团队中的相互沟通，来减少孤独感，因为这常常是工作不满的主要原因。最后，XP中有一个关于人员流动的清晰模型。鼓励新成员逐渐承担越来越多的责任，新成员之间互相帮助，同时老成员也为新成员提供帮助。

XP假设你把自己看成团队的一部分，一个具有清晰目标和执行计划的理想个体。XP假设你想与别人一起工作。XP假设可以经济地应付变化。XP假设你希望成长、改善自己的技能，改善人际关系。XP假设你愿意做出改变来达成这些目标。

现在我准备回答本章提出的问题：什么是XP？

— XP是放弃旧的、低效的技术和习惯而采用新的有效的技术和习惯。

— XP是因为你今天的竭尽全力而充分欣赏你自己。

— XP是努力在明天做得更好。

— XP是要你按照对团队共同目标做出的贡献来评价自己。

— XP是让你的一些人性需求在软件开发中得到满足。