1、大学生四年级软件工程专业毕业设计参考
2、软件设计师、项目管理师等技术人员参考
3、参加软件资格水平考试《系统分析师》的相关人员
4、其他想提升软件开发技能的群体
一、案例描述
某公司要在现场开发一个网站应用系统，该系统的特点是：规模不大，工期短；用户需求不明确；没有多大的技术风险；系统中的一些模块可以外包给其它公司开发。在选择开发过程中，项目组内产生了分歧。
王工提出采用XP极限编程方法，理由是XP方法简洁，能减轻开发人员负担、快速适应市场、缩短投资回收期。李工认为采用XP在项目开发中存在一些问题，建议考虑原型开发方法。
双方就上述的问题展开了激烈的争论。项目组最后决定采用XP，但同时针对李工提出的XP中存在的问题采取了相应的措施。
【问题-1】
小规模发布是XP的基本元素之一。请用 200字以内文字分别阐明：
（1）原型系统和XP小规模发布的系统的主要差别？
（2）为什么该项目组没有采用原型开发方法？
【问题-2】
请用200以内的字，简要说明采用XP开发方法可能存在哪些问题？
【问题-3】
在项目组的后续讨论中，李工提出如果项目规模扩大，XP将不再适用。对此王工表示赞同，但同时提出可以将XP和传统软件开发过程相组合。请用200字以内文字简要的说明如何将XP方法和传统软件开发过程相结合。
【问题-4】
敏捷开发有许多的典型方法，包括极限编程（Extreme Programming）、Scrum、Crystal、 DSDM等，请问这些方法共同的基本原则是什么？
【问题-5】
敏捷开发的支持者往往夸大该方法的优点，但在实践中，敏捷方法的基本原则有时候确实难以实施，请用200字说明敏捷方法中哪些原则在实践中难以实施。
二、案例知识点
1、原型法和XP方法比较
当客户有一个合理的需求，但对细节没有任何线索时，原型法是一个常用的方法。原型法将从需求收集开始，开发者和客户一起定义软件的总体目标，标识出已知的需求，并规划出需要进一步定义的区域。然后就是“快速设计”快速设计集中于软件中那些对客户可见的部分的表示（输入方式和输出格式）。可以通过快速设计来创建原型，原型由用户评估进一步精化待开发软件的需求。逐步调整原型使其满足客户的需求，而同时也使开发者对将要做的事情有较好的理解，这个过程是迭代的。
理想情况下，原型可以作为标识软件需求的一种机制。如果建立了可运行的原型，开发者就可以在其基础上试图利用已有的程序片段或使用工具（如报表生成器、窗口管理器）来尽快生成可运行的程序。
原型开发在实施的时候，存在的问题主要有以下两个方面：
（1）客户似乎已经看到了软件的工作版本，却无法理解，原因在于为了使原型能够很快使用，开发者没有考虑软件的总体质量和长期的可维护性。
（2）开发者常常需要实施上的折中使原型尽快工作
因此，通常采用原型法都会在客户和开发者之间达成协议：构建原型仅是定义需求，之后就抛弃了（至少是部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。这种原型的方法也称为“抛弃原型开发”。当然，也可以采用逐渐演进的方式进行原型开发，即以逐渐增加功能的方式进行开发，以便于随时根据客户的反馈来修正系统。大多数渐进原型都是从一个用户界面原型开始逐步演化出整个系统的。
不过采用原型法可能出现的风险是：不切实际的进度和预算、项目可控性降低、缺乏最终用户和客户的反馈（这是因为，容易让客户的目标陷入界面，而忽略本质，反而造成问题）、产品性能不佳、不切实际的性能期望、设计不佳、可维护性差、目标偏移，而且还有一个重要的就是原型开发阶段效率一般都较低。
由于XP认为“客户确切的知道需求，而且当你实现其需求后，他仍然认同 “这种现象不存在”。因此，在XP方法论中最重要的一件事就是尽早、尽量频繁的发布。如果可能，第一次不应该超过2个月，此后每两个月发布一次。需要注意的是，XP中每次发布的内容不是演示版，而是实用版。也就是说，并不是仅仅将其演示给客户看，让其评论，最后放到一边，继续等待最后的开发结果，而是交付使用的子集，让客户每一天都在使用。
另外，为了保证开发出来的结果与客户的预想接近，ＸＰ方法论任务最重要的是需要将客户请到开发现场。在项目中有客户在现场明确用户需求，并作出相应的业务决策对于ＸＰ项目而言有着十分重要的意义。这是因为，仅靠简单的用户需求描述是不充分的，还需要大量的时间与客户沟通。
２、ＸＰ开发思想的缺点
ＸＰ的核心是其总结的沟通、简单、反馈、勇气四大价值观。它包括１２种最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作４０小时、现场客户，以及编码标准。
从ＸＰ方法论本身来说，首先第一类潜在问题是精神和观念上的，即是否能够得到开发人员、管理者，以及客户三方面的支持与理解。简单设计、测试先行、重构、集体代码所有制、编码标准、持续集成都从某种意义上违背了程序员的传统习惯；而小型发布、结对编程、每周工作４０小时，经常会让管理者不可理解，以至于认为ＸＰ是黑客文化，是为开发人员谋福利而来的；而现场客户实践则经常无法得到客户的理解和满足，另外许多客户在接受每一次小规模发布时，也会提出异议。
另外由于ＸＰ方法论属于轻量级，也就是文档量少，遵从“代码就是文档”的思想。因此虽然ＸＰ方法论中是有“当非要文档时才编写”的说法，但却容易使团队忽视文档。从而降低系统的可维护性、易用性，以及其它的一些问题。
３、ＸＰ方法与传统软件开发结合
ＸＰ方法论创始人Kent Beck在其《拥抱变化：解析极限编程》一书中明确指出了：ＸＰ是适合于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学，它与传统方法论最大的不同在于：
（１）拥有短周期的早期、具体和持续的反馈
（２）它递增地进行计划编制，也就是在项目一开始迅速提供一个总体计划，然后在项目整个周期内不断发展它
（３）它针对不断变化的业务需求灵活的对功能的实现进行计划的能力
（４）它依赖于程序员或客户编写的自动测试来监控开发进度
（５）它依赖于口头交流、测试和源代码来沟通系统的结构和意图
（６）它依赖于整个系统存在期间一直持续的进化式设计过程
（７）它依赖于技术水平一般的程序员之间的紧密协作
（８）它依赖于能够同时满足程序员的短期本能和项目的长期利益的实践
因此，XP与传统方法论存在很多结合点。
集中式方法是传统的软件工程方法的共同特点，它的优点在于：具有共同的、清晰确定的目标，而且是一个结构化的过程，领导团队贯穿各个开发阶段。而它们最大的缺点是：缺乏负责员工的参与，而且客户的反馈也不少，导致解决方案的接纳度降低。XP方法员工/客户联系十分紧密。可以保证较高的接纳度。不过把其运用到局部问题上往往不能产生与多个团队一起共享的改进，加上XP方法无结构，因此必须包含几个人复杂问题不能用它产生一个全面的概念。
（1）层次化结合。基于上述想法，可以提出 层次化管理，具体来说就是：
在上层建立一个面向目标的项目管理，它通过产生一个大致概念来把问题组织成一种高级结构；将目前局部化问题的每个部分通过定义一个自身的XP团队来用一种极限编程的方法予以解决。XP团队主要在独立的基础上发挥功能，同时他们通过跟踪全局目标和衡量局部改进的顶层管理团队以一种松散的方式联系起来。
（2）实践引入式结合。另一种结合方式是依然按照传统过程方法论进行过程管理，引入XP的实践，实现优势互补。其中比较典型的包括如下几点。
现场客户：这个实践是对传统过程方法论缺乏客户参与的最好补充。
简单设计：只为今天，不过多地考虑明天的需要，因为现在的假设可以是错误的，也许明天还有更好的实现方式，这是XP提仓的简单的原则，它也可以无缝的借用到传统的过程方法论进行管理的项目中。
小型发布：每次迭代都实现一次小型发布，提交一个能够让用户开始投入使用的小型版本，可以有效地加强反馈，缩短开发进程，提高软件质量。其中还可结合每日构件进行持续集成，予以保障和支持。
测试先行、重构：这是保证“小步快走”的关键实践，对于软件质量的提高有很多帮助。
三、参考答案
【问题-1】
（1）原型系统和XP小型发布系统的主要差别是功能。采用原型系统主要让用户确认需求，或者用来测试关键技术，但是它展示的功能不是实际的系统功能，不能用来评价实际的系统；XP小型发布的系统不包括足够的功能，但是每个功能和可发布的产品的定义是不一样的。在完整性上，它配备了一系列实用的功能集；在质量上，它可以健壮的运行。
（2）在该项目中，不需要开发原型系统
由于项目没有太大的技术风险，所以不需要用原型系统来测试关键技术；网站系统的开发和原型系统的开发在工作量上是相当大的，在时间要求短的情况下直接开发系统可以节省时间；对于用户经常发生变化的情况，可以采用XP开发方法的代码重构、持续集成和小型发布等技术。
【问题-2】
（1）开发团队、管理层以及客户的不理解，阻碍XP方法论的实施
（2）导致开发团队忽视文档，以XP为借口拒绝编写甚至是必须的文档
（3）XP是针对单一团队设计的，外包方的参与将会为有效的组织带来很大的困难
（4）缺乏客户的参与，导致用户故事编写、优先级确认等工作遇到困难
（5）项目规模扩大后，XP方法论将不适用
（6）对客户、开发人员和管理者素质要求较高
【问题-3】
（1）可以将XP和传统软件开发过程中的增量式开发过程相结合
（2）将大规模项目划分为若干个具有共同目标的小规模项目，用XP方法论组织小项目开发，用传统软件过程方法论监控全局
（3）在此基础上，建立面向目标的项目管理
【问题-4】
（1）客户参与
（2）增量式开发
（3）开发团队的技术应该得到承认和发扬。团队成员应该保持他们自己的风格，不落俗套。
（4）接受变更
（5）保持简单性
【问题-5】
（1）客户的参与程度依赖于客户的意愿和客户自身的代表性
（2）团队成员的性格可能不适合激烈的投入，可能无法做到与其他团队成员的良好沟通
（3）对系统中的变更 作出优先级排序可能是极端困难的
（4）维护系统的简洁性往往需要额外的工作，但迫于移交时间表的压力，可能没有时间执行系统简化过程
