Xp是一种软件开发风格style，关注于如何应用好程序技巧，清晰的交流，以及团队工作。
Xp
包括：
l 基于交流，反馈，简单性，鼓励和尊重等的价值的软件开发哲学。
l 在软件开发中证明有效的实践。这些实践相互补充，以加强它们的作用。选择它们的原因是为了表达上述列出的几种价值。
l 一组互补的原则和intellctual的技术，并用来将上述的价值传递到实践中，useful when there isn't a practice handy for your particular problem.
l 一个社区community，它们共享这些价值和很多同样的实践。
Xp使工作的人可以一起开发出很棒的软件，
与其他的开发方法相比，不同的是：
较短的开发周期：因为较早的，具体的，持续的反馈。
增量式的计划制定：将产生一个全局的计划，这个计划将在整个工程的生命周期中进化。
灵活地安排功能实现的时间表的能力：可以适应业务变化的需要。
对自动测试的依赖：由程序员，用户，测试者编写，并用来监视进程的发展情况，允许系统
的进化，尽早捕获缺陷。
对进化式设计的依赖：
对参与项目的人员的紧密的合作的依赖
对项目人员的短期直觉，项目的长期兴趣的依赖。（Its reliance on practices that
work with both the short-term instincts of the team members and
the long-term interests of the project.）
xp
的定义：
l xp是轻量级的。Xp中你只需要做可以为用户创造价值的东西，不需要做多余的东西。但是为了成为一个优秀的团队对技术的学习需求还是很大的。
l Xp是基于在软件开发中指定限制的方法学（methodology）。Xp并不指定项目档案管理，项目的财务调整，操作，市场，销售。Xp对这些部分都涉及，但是没有直接指定其实践。
l Xp适用于任何规模的团队。Xp的价值和原则对任何规模的项目都适用。
l Xp可以适应需求不明确和需求快速变化的情况。Xp对现代商业世界快速变动的适用也相当好。Xp对需求比较稳定的情况也适用良好。
我试图用xp在软件开发中协调人力和生产率，并且贡献这种协调。我已经注意到对待员工越人性化，生产率就越高。成功的关键不在于禁欲（self-mordification），而在对于我们是人与人的业务中的个体（people in a person-to-person business）这个事实的接受程度。
技术也是很重要的一方面。我们是技术人员，我们能使工作更好或更糟。对技术完美性的追求是社会style发展的关键。技术产生了信任的关系。如果你能精确估计工作，第一时间提交质量合格的产品，快速对意见反馈，那么你就是一个值得信赖的合作伙伴。Xp要求参与者对团队的技术需求有较好的理解。
Xp意味着放弃一些旧的习惯，虽然旧的习惯曾经有用过，但不一定是现在团队软件开发的最佳选择。良好安全的交互，良好的技术技巧都是成功的xp项目所必须的。
有这样一个概念：脆弱性就是安全性。以前有这种做法，基于安全的考虑会holding something back，但这种做法实际上没有用。
Holding back that last 20% of effort doesn't protect me. When my project fails, the fact that I didn't give my all doesn't actually make me feel better. It doesn't protect me from a sense of failure that I couldn't make the project work. If I do my very best writing a program and people don't like it, I can still feel justly good about myself. This attitude allows me to feel safe no matter the circumstance. If how I feel is based on an accurate read on whether I did my best, I can feel good about myself by doing my best.
当自我价值不与一个项目联系在一起时，我们很容易在任何环境下做出最好的工作。在
xp
中你不用准备失败。在相互关系上保持距离，因为不努力工作或过分工作而造成的失败，推迟反馈，这些事情都不会在
xp
在出现。
不论你有没有时间，钱，技巧，最好的方式是
act as if there is going to be enough. This "mentality of sufficiency" is movingly documented by anthropologist Colin Turnbull in The Mountain People and The Forest People.
他比较了两种社会：一种是资源贫乏，充满欺骗，虚假的部落，一种是资源富足，能相互合作，友爱的部落。我常常问开发者一个难题：“如果你有足够的时间你会怎么做？”就算有限制你还是可以将工作做的很好。被限制条件困扰的话会让你与你的目标越来越远。
如果你有
6
周时间完成一个项目，你唯一可以控制的事情就是你的行为。你会让
6
周的工作价值值得还是不值得？你不能控制其他人的期望。你可以告诉他们你对这个项目所知道的，这样他们的期望可以跟事实相匹配。
当我学会了这一点之后，我对于最后期限的恐惧消失了。管理其他人的期望不是我的工作，那是他们自己的工作，我所要做的是做好我的事情并且清晰地与其他人交流。
Xp
是软件开发原则，它将所有的危机在开发的各个阶段都指明了。
Xp
是高效的，产生高品质的软件，并且使用
xp
有很多的乐趣。下面是
xp
如何指出危机：
1)
时间表的时间段在
xp
中很短，最多几个月。比如
xp
以一周为单位迭代来完成良好粒度的反馈。在迭代中，
xp
计划的任务是短任务，所以可以在一个循环中解决问题。
Xp
将完成优先级高的。
2)
如果项目被取消，XP让团队中面向业务的部分选择可以展现最多业务的最小release
版本。所以，在最终发布软件之前出错的几率小，并且软件的价值是最大的。
3) 系统如果因为xp中的某方法变得糟糕，系统会维护一整套复杂的自动测试。这些测试在任何变化产生时，用来保证质量。Xp始终让系统处于可以发布的状态。问题不允许积累。
4) Xp通过程序员写的基于功能测试和用户写的基于软件特征的测试来测试软件的缺陷率
defect rate。
5) 如果业务被错误理解，xp会让面向业务的那部分人员作为团队的第一类成员。项目的说明文档不断在开发中被细化。所以用户和团队的学习会反应在软件中。
6) 因为业务的不断变化，xp缩短了版本发布的周期，所以在软件的单个发布中变化很少。在一个开发一个版本的过程中，用户被允许用新的功能替换还没有完成的已有的功能。开发团队甚至都不会察觉到已经在新的功能上工作。
7) 坚持只有最高优先级的工作被address。
8) 由于工作人员的流动，xp要求程序员有估计和完成他们自己工作的责任。Xp同时鼓励团队中的交流。Xp对人员流动有一个相当好的模型，新成员逐渐接受越来越多的责任，并且得到其他人的帮助。
l Xp假设每一个人都视自己为团队的一份子，理想情况下每一个人都有明确的目标和执行计划。
l Xp假设每个人都希望一起工作。
l Xp假设实现变化的代价可以做到较小，因为使用xp。
l Xp假设你希望成长，希望技巧进步，希望发展你与他人的关系。
l Xp假设你愿意为上述目标做出改变。
最后总结一下什么是xp？
Xp是用新的技术替代旧的，没有效率的技术和习惯。
Xp对你所做的努力持赞赏的态度。
Xp努力做到明天更好。
Xp根据你对团队的共同目标做的贡献来评估你。
Xp让你作为人的需求跟软件开发相契合。
2．1 价值，原则，实践
价值是我们喜欢或不喜欢一个事务的根本原因，价值是我们用来判断我们所看，所想，所做
的最大范围的准则。
实践为价值提供了证据，以价值的名义我们可以做任何事情。“我觉得交流是一种价值，所
以我写了一份1000页的文档。”这种做法也许是对的，也许是错的。如果每天一次的
15分钟的交谈比写文档能更有效地交流，那么文档就没有表现出价值。以我所能展示的方式进行最有效的交流，那么交流是有价值的。
实践是显而易见的事情。每个人都知道我是否参加了每天早上的例会。我不能很确定是否真
正体会到交流的价值，但是我是否通过实践来加强交流却是能够看见的。
价值是实践的目标，实践是价值的责任。
价值是普遍的，理想上我工作中的价值与我生活中的其他价值是一样的。
实践与环境有关。如果我想知道关于我的程序是否正确的feedback，我可以通过持续的编
译和测试来判断；如果我想知道我是否应该换一个手巾的feedback，持续的编译和测
试是没有用的。可见，feedback在两种情况下都是存在的，但是实践时却是不一样的。
如何将相对不变的价值跟在不
同环境下变化的实践联系起来？通过原则
principle
。
原则是生活特定领域的指导方针
guidelines
。
2．1．1 价值
communication:影响团队开发的最重要的因素。
Simplicity：是xp价值中最理智的intellectual。
Feedback：无论软件开发的细节，系统需求，系统体系结构都不存在可以保持长久价值的
预先定义的方向。改变不可避免，改变产生对反馈的需要。是否存在一开始就正确的决
策？不行，因为：
我们不能知道怎样做才是对的。对于一个问题可以有多种方案，但是哪个是对的？
今天看来是对的，明天可能就是错的。
今天试图将所有的问题都解决，而明天可能因为环境的改变使今天做的事情都无效了。
Feedback的多种形式：
u 一个主意的多个可选方案。
u 代码的结构。
u 测试是否容易写。
u 测试是否能正确运行。
u 当想法实现时是怎样的效果。
团队尽量在可以处理的范围内产生尽可能多的feedback，团队试图将feedback的
周期控制在以分钟或小时为单位的时间内。
当重要的feedback被忽视，团队不得不停下来，直到对feedback做出反应。
Feedback是communication的关键性组成部分。
Feedback对simplicity也是有用的。比如，为了确定多个方案中哪个方案是最简
单的，就可以分别实现它们任何从feedback中来判断。另外，越简单的系统获
取feedback越容易。
Courage：
Respect：
Other：
2．1．2 XP的12个最佳实践原则
1 现场客户 ( On-site Customer )
XP： 要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试。
评述：现场用户可以从一定程度上解决项目团队与客户沟通不畅的问题，但是对于国内用户来讲，目前阶段还不能保证有一定技术层次的客户常驻开发现场。解决问题的方法有两种：一是可以采用在客户那里现场开发的方式；二是采用有效的沟通方式。
项目：首先，我们在项目合同签署前，向客户进行项目开发方法论的介绍，使得客户清楚项目开发的阶段、各个阶段要发布的成果以及需要客户提供的支持等；其次，由项目经理每周向客户汇报项目的进展情况，提供目前发布版本的位置，并提示客户系统相应的反馈与支持。
2 代码规范 ( Code Standards )
XP： 强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。
评述： XP对于代码规范的实践，具有双重含义：一是希望通过建立统一的代码规范，来加强开发人员之间的沟通，同时为代码走查提供了一定的标准；二是希望减少项目开发过程中的文档，XP认为代码是最好的文档。
对于目前国内的大多数项目团队来说，建立有效的代码规范，加强团队内代码的统一性，是理所当然的；但是，认为代码可以代替文档却是不可取的，因为代码的可读性与规范的文档相比合适由一定的差距。
同时，如果没有统一的代码规范，代码全体拥有就无从谈起。
对于目前国内的大多数项目团队来说，建立有效的代码规范，加强团队内代码的统一性，是理所当然的；但是，认为代码可以代替文档却是不可取的，因为代码的可读性与规范的文档相比合适由一定的差距。
同时，如果没有统一的代码规范，代码全体拥有就无从谈起。
项目： 在项目实施初期，就由项目的技术经理建立代码规范，并将其作为代码审查的标准。
3 每周40小时工作制 ( 40-hour Week )
XP： 要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。
评述： 该实践充分体现了XP的"以人为本"的原则。但是，如果要真正的实施下去，对于项目进度和工作量合理安排的要求就比较高。
项目： 由于项目的工期比较充裕，因此，很幸运的是我们并没有违反该实践。
4 计划博弈 ( Planning Game )
XP： 要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围。
评述： 项目的计划在建立起来以后，需要根据项目的进展来进行调整，一成不变的计划是不存在。因此，项目团队需要控制风险、预见变化，从而制定有效、可行的项目计划。
项目： 在系统实现前，我们首先按照需求的优先级做了迭代周期的划分，将高风险的需求优先实现；同时，项目团队每天早晨参加一个15分钟的项目会议，确定当天以及目前迭代周期中每个成员要完成的任务。
5 系统隐喻 ( System Metaphor )
XP： 通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。
评 述： XP在系统实现初期不需要进行详细的架构设计，而是在迭代周期中不断的细化架构。对于小型的系统或者架构设计的分析会推迟整个项目的计划的情况下，逐步细 化系统架构倒是可以的；但是，对于大型系统或者是希望采用新架构的系统，就需要在项目初期进行相信的系统架构设计，并在第一个迭代周期中进行验证，同时在 后续迭代周期中逐步进行细化。
项目： 开发团队在设计初期，决定参照STRUTS框架，结合项目的情况，构建了针对工作流程处理的项目框架。首先，团队决定在第一个迭代周期实现配件申请的工作流程，在实际项目开发中验证了基本的程序框架；而后，又在其它迭代周期中，对框架逐渐精化。
6 简单设计 ( Simple Design )
XP： 认为代码的设计应该尽可能的简单，只要满足当前功能的要求，不多也不少。
评述： 传统的软件开发过程，对于设计是自顶而下的，强调设计先行，在代码开始编写之前，要有一个完美的设计模型。它的前提是需求不变化，或者很少变化；而XP认为需求是会经常变化的，因此设计不能一蹴而就，而应该是一项持续进行的过程。
Kent Beck认为对于XP来说，简单设计应该满足以下几个原则：
Kent Beck认为对于XP来说，简单设计应该满足以下几个原则：
成功执行所有的测试；
不包含重复的代码；
向所有的开发人员清晰地描述编码以及其内在关系；
尽可能包含最少的类与方法。
对于国内大部分的软件开发组织来说，应该首先确定一个灵活的系统架构，而后在每个迭代周期的设计阶段可以采用XP的简单设计原则，将设计进行到底。
对于国内大部分的软件开发组织来说，应该首先确定一个灵活的系统架构，而后在每个迭代周期的设计阶段可以采用XP的简单设计原则，将设计进行到底。
项目： 在项目的系统架构经过验证后的迭代周期内，我们始终坚持简单设计的原则，并按照Kent Beck的四项原则来进行有效的验证。对于新的迭代周期中出现需要修改既有设计与代码的情况，首先对原有系统进行"代码重构"，而后再增加新的功能。
7 测试驱动 ( Test-driven )
XP： 强调"测试先行"。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。
评 述： RUP与XP对测试都是非常的重视，只是两者对于测试在整个项目开发周期内首先出现的位置处理不同。XP是一项测试驱动的软件开发过程，它认为测试先行使 得开发人员对自己的代码有足够的信心，同时也有勇气进行代码重构。测试应该实现一定的自动化，同时能够清晰的给出测试成功或者失败的结果。在这方面， xUnit测试框架做了很多的工作，因此很多实施XP的团队，都采用它们进行测试工作。
项目： 我们在项目初期就对JUNIT进行了一定的研究工作，在项目编码中，采用JBUILDER6提供的测试框架进行测试类的编写。但是，不是对所有的方法与用 例都编写，而只是针对关键方法类、重要业务逻辑处理类等进行。详细的关于JUNIT测试框架的使用，
请参见我的同事撰写的另一篇文章(http:
//www-900.ibm.com/developerWorks/cn/java/l-junit/index.shtml)
8 代码重构 ( Refactoring )
XP： 强调代码重构在其中的作用，认为开发人员应该经常进行重构，通常有两个关键点应该进行重构：对于一个功能实现和实现后。
评述： 代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。
在使用代码重构的时候要注意，不要过分的依赖重构，甚至轻视设计，否则，对于大中型的系统而言，将设计推迟或者干脆不作设计，会造成一场灾难。
在使用代码重构的时候要注意，不要过分的依赖重构，甚至轻视设计，否则，对于大中型的系统而言，将设计推迟或者干脆不作设计，会造成一场灾难。
项目： 我们在项目中将JREFACTORY工具部署到JBuilder中进行代码的重构，重构的时间是在各个迭代周期的前后。代码重构在项目中的作用是改善既有设计，而不是代替设计。
9 成对编程 ( Pair Programming )
XP： 认为在项目中采用成对编程比独自编程更加有效。成对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。
评 述： 其实，成对编程是一种非正式的同级评审 ( Peer Review )。它要求成对编程的两个开发人员在性格和技能上应该相互匹配，目前在国内还不是十分适合推广。成对编程只是加强开发人员沟通与评审的一种方式，而非唯一 的方式。具体的方式可以结合项目的情况进行。
项目： 我们在项目中并没有采用成对编程的实践，而是在项目实施的各个阶段，加强了走查以及同级评审的力度。需求获取、设计与分析都有多人参与，在成果提交后，交叉进行走查；而在编码阶段，开发人员之间也要在每个迭代周期后进行同时评审。
10 代码共享
XP： 认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。
评论： 代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG的修复。
在目前，国内的软件开发组织，可以在一定程度上实施该实践，但是同时需要注意一定要有严格的代码控制管理。
在目前，国内的软件开发组织，可以在一定程度上实施该实践，但是同时需要注意一定要有严格的代码控制管理。
项目： 我们在项目开发初期，首先向开发团队进行"代码全体拥有"的教育，同时要求开发人员不仅要了解系统的架构、自己的代码，同时也要了解其它开发人员的工作以及代码情况。这个实践与同级评审有一定的互补作用，从而保证人员的变动不会对项目的进度造成很大的影响。
在项目执行中，有一个开发人员由于参加培训，缺席项目执行一周，由于实行了"代码全体拥有"的实践，其它的开发人员成功地分担了该成员的测试与开发任务，从而保证项目的如期交付。
在项目执行中，有一个开发人员由于参加培训，缺席项目执行一周，由于实行了"代码全体拥有"的实践，其它的开发人员成功地分担了该成员的测试与开发任务，从而保证项目的如期交付。
11 持续集成 ( Continuous Integration )
XP： 提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。
评述： 持续集成也不是XP专有的最佳实践，著名的微软公司就有每日集成 ( Daily Build ) 的成功实践。但是，要注意的是，持续集成也需要良好的软件配置变更管理系统的有效支持。
项目： 使用VSS作为软件配置管理系统，坚持每天进行一次的系统集成，将已经完成的功能有效地结合起来，进行测试。
12 小型发布 ( Small Release )
XP： 强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
评论： 小型发布突出体现了敏捷方法的优点。RUP强调迭代式的开发，对于系统的发布并没有作出过多的规定。用户在提交需求后，只有在部署时才能看到真正的系统，这样就不利于迅速获得用户的反馈。
如果能够保证测试先行、代码重构、持续集成等最佳实践，实现小型发布也不是一件困难的事情，在有条件的组织可以考虑使用。
如果能够保证测试先行、代码重构、持续集成等最佳实践，实现小型发布也不是一件困难的事情，在有条件的组织可以考虑使用。
项 目： 项目在筹备阶段就配置了一台测试与发布服务器，在项目实施过程中，平均每两周（一个迭代周期结束后）进行一个小型发布；用户在发布后两个工作日内，向项目 小组提交"用户接收测试报告"，由项目经理评估测试报告，将有效的BUG提交至Rational Clear Case，并分配给相应的开发人员。项目小组应该在下一个迭代周期结束前修复所有用户提交的问题。
2.3 XP过程中的各个阶段
作为一个软件开发过程，XP中计划，设计，编码和测试各阶段包括的内容比较简洁，容易实施。
1 计划
User stories的编写
识别需求方面
开发计划的制定
经常构造版本
版本控制
Load Factor因子的确定
将项目分解为各个迭代期
每个迭代期开始时制定计划
人员集中
站着开每日晨会
当实施遇到困难时及时修正
2 测试
所有代码均需进行单元测试
发行之前所有代码必须通过单元测试
Bug发现后应马上测试
3 编码
始终获得用户的支持
代码的书写必须按照规范
所有代码均采用配对开发
一次只能有一对开发人员进行发行
代码经常集成
代码共享
将优化放在最后
不要加班
4 设计
简单化
采用编程规范
设计时使用CRC卡片
使用Spike Solution 方法
不要过早添加新功能
尽可能保持程序的简洁性
作为一个软件开发过程，XP中计划，设计，编码和测试各阶段包括的内容比较简洁，容易实施。
1 计划
User stories的编写
识别需求方面
开发计划的制定
经常构造版本
版本控制
Load Factor因子的确定
将项目分解为各个迭代期
每个迭代期开始时制定计划
人员集中
站着开每日晨会
当实施遇到困难时及时修正
2 测试
所有代码均需进行单元测试
发行之前所有代码必须通过单元测试
Bug发现后应马上测试
3 编码
始终获得用户的支持
代码的书写必须按照规范
所有代码均采用配对开发
一次只能有一对开发人员进行发行
代码经常集成
代码共享
将优化放在最后
不要加班
4 设计
简单化
采用编程规范
设计时使用CRC卡片
使用Spike Solution 方法
不要过早添加新功能
尽可能保持程序的简洁性
1 Xp的实现
1．1 xp的理想生命周期
1．1．1 调查exploration
这是一个准备阶段。
对技术人员而言，准备包括：
熟悉工程将使用的技术。如果一周的时间不能让技术人员对将要使用的技术熟悉起来，那么
技术确实会是一个风险risk。虽然不能说必须更换技术，但是必须重新考虑关于技术方面的问题。也许技术人员希望用过该技术的人能给予指导，但是要注意指导人员可能会将他在他的项目中的习惯带给你，然而这些习惯可能跟xp不契合。
应该对要使用的技术在性能上的表现做出估计。
对工程结构上可能的问题做一些实验，以确定一个较好的方案。
对调查期间从事的每相工作进行时间估算的练习，以提高对工作时间的估计能力，这样便于
计划的制定。
对用户而言：
练习写user stories。这项工作不是很容易能完成的。要让用户通过User stories
为技术人员指定出需要的，去掉不需要的。另外，user stories要让技术人员能够从中估算出工作量。
1．1．2计划planning
计划的目的是让技术人员和用户之间在时间上能达成一致，以完成user stories中最有
价值的部分。
第一次release的计划应该在2到6月间。更短的话无法解决业务中的重要问题。
1．1．3对第一版的迭代
迭代应该定在1到4周一次。每一次迭代会为每个user stories产生一个功能测试
cases。
第一次迭代不要关心结构，要选择哪些可以帮助你建立完整的系统的user stories，即
便user stories只是框架性质的。
对接着的迭代让用户的意见做为迭代的依据。
当你在迭代的时候发现与之前的计划有出入的时候，是需要做出改变的时刻了。
也许应该改变计划。
也许应该改变正在做的事情。
理想状态，每次迭代结束时用户可以完成功能测试并且测试但是成功的。
1．1．4产品化productionizing
有一些手段可以证明软件已经准备好发布为产品了。
调整系统的性能。项目的最后阶段是调整系统性能的最好阶段，因为：
你有了最多的认识。
你对产品有了最实事求是的估计。
有了最终要运行产品的硬件。
1．1．5维护maintenance
1．1．6死亡death
首先收集
user stories，并考虑一些问题spike的解决方案（
spike solutions）。
制定计划，从
iteration planning会议开始。
通常当一个项目无法进行下去的时候就会想起xp。这种情况下，最好的方式就是看一
看现在的开发方法将在何时出现问题，然后从那时开始使用xp。
比如，你在开发过程的25％时发现你的需求文档完全无用了，那么这是使用user
stories的时候了。
比如，如果改变需求迫使你不断重新指定计划，那么可以尝试更简单，更早的
release planning会议每隔一个迭代。尝试一下
iterative style of
development和
just in time style of planning of programming
tasks
比如，你最大的问题是众多的bug in production，那么试试自动
acceptance
比如，你最大的问题是integrate bugs，那么试试自动
unit tests。
比如，当一两个开发者成为了项目中的瓶颈，那么试试
collective code
User stories：
User stories跟用例的目的一样。
User stories用来
为
release planning meeting创建时间估算。
替代需求文档。
User stories由用户书写，记录系统需求。
类似usage scenarios，但是user stories不被限制到只描述用户接口。
User stories由3句话组成，用户以自己的方式来写，不存在特定的语法。
User stories会驱动
acceptance tests的创建。创建一到多个acceptance tests
来检查user stories是否被正确实现。
与传统的需求描述的区别主要在细节的程度：
user stories提供的细节程度只需要能够对story的实现所用时间进行低风险的估计。
当具体实现该story的时候才进行更细节的讨论。
开发人员估计user stories需要的时间，这个时间在理想情况下通常是1到3周。理想
情况是指在开发期间开发人员能够对此story集中注意力，没有人员变动，并且对如何实现很清楚。
超过3周的story，意味着你需要将一个story分解为多个。
低于1周的story，说明story的细节程度太低，需要合并多个为一个。
User stories的数量：
80（±20）个user stories是可以创建
release plan的数量。
与传统的需求描述的区别的另一个区别：
关注的目标不同：
user stories避免技术细节，数据库布局，算法等问题。
还有一个关键区别（Kent Beck, Cynthia Andres）：
早期的估计：
User stories的具体形式：
spike solutions测试方案：
tough技术和设计问题的解决方案。
是一个简单的program，探讨了可能的方案。
建立一个只针对该问题的系统，该系统中不涉及其他。
多数的spike不值得保存，可以抛弃。
建立spike solutions的目标是减少技术风险，增加对user stories估计的可靠性。
iterative development
iteration planning
release planning meeting
acceptance tests
从user stories转换而来，用户指定了一些特定的场景scenarios来测试开发者对
user stories的实现。不论acceptance tests怎样来确保功能上的正确性，一个story可以用一到多个acceptance tests来测试。
Acceptance tests是黑盒测试，每个acceptance test代表了某些希望从系统获得
的结果。用户对acceptance tests结果的正确性负责，并且确定失败了的测试哪些具有比其他失败的测试更高的优先级。
Acceptance tests也可以在产品发布前用来测试。
一个user story没有经过acceptance tests就不能认为已经结束。
QA（quanlity assurance）在xp中很重要。有的项目会有专门的人员来做qa，有的
项目将qa交给开发团队。在xp中希望开发团队对qa负有较多的责任。
Acceptance tests应该是自动的automated，以便经常运行。由开发人员决定什么时
候解决失败了的测试。
Acceptance tests的名字来自functional tests，acceptance tests这个名字
更能反应问题，它意味着测试表明用户需求被满足，因而系统是acceptable。
release planning
在release planning meeting上创建
release plan。
Release plan用来为每次迭代
iteration创建迭代计划。
Release planning用一系列原则，将技术人员的技术决策和用户的业务决策整合到一个
每个人都能接受的时间表中。
Release planning meeting的必要性：
让开发团队可以估计每个user story的理想情况下的实现时间。实现不包括与之相
关的其他工作，但是包括了测试。
用户可以决定user stories中最重要的，需要优先实现的story。
决定要在第一版中实现的stories。
计划可以按时间或范围来制定。
Project velocity用来指定
在某个给定的时间前可以实现的stories（时间），
一个或多个特定的stories需要的实现时间（范围scope）。
如果按时间来制定计划，通过project velocity来增加迭代的次数，以决定有多少
stories可以被实现。
如果按范围来制定计划，通过
project velocity来划分根据所有stories估计的总时
间，来决定在版本发布前可以有多少次的迭代。
每次迭代的具体计划的详情在迭代开始时才制定。
Release planning meeting被称为计划游戏planning game，其规则详见
portland pattern repository。
编写好user stories之后开一个release planning meeting来制定release plan。
Release plan详细指定哪些user stories将被在哪些版本中实现，以及每个版本的截至时间。这些将给用户指定一组user stories，这些user stories在迭代开始时的
iteration planning meeting中做进一步选择。
被选中的stories将转换为单个的编程工作，以在迭代中来实现。
Stories也可以转换为acceptance tests。这些acceptance tests在当
次迭代中被运行，在之后的迭代中也可以运行。
当工程速度
project velocity改变时，开一个release planning meeting以
制定新的release plan。
Release plan也被称为commitment schedule。
Make frequent small releases
开发团队需要经常性将可交互的版本发布给用户，这样你可以及时获取有价值的反馈。
Iteration development
iterative development为开发过程增加了灵活性，将开发划成多个1到3周的迭代。
将这个1到3周的标准贯穿整个项目，这是项目的脉门，这将使估计项目进度
measuring progress和计划制定变得较为简单和可靠。
不要提前制定你的编程计划，而是在每次迭代前的
iteration planning meeting中
才详细策划。Just-in-time的planning可以很好适应需求的变化。
不要实现在本次迭代中没有的任何东西。
认真指定迭代的截至时间，记录项目的进展情况。如果情况看起来无法完成计划，那么开一
个iteration planning meeting，重新estimate，去掉某些任务。
集中精力完成由用户选定的最重要的任务，而不是在没有完成的几项任务上花时间。
每项计划只给一周时间的话，不是很好。
每次制定计划的时候都当成是最后一次计划来对待，可以提高项目的质量。
Iteration Planning
Iteration planning会议在每次迭代的开始召开，产生编程任务（programming
tasks）的迭代计划。
用户根据价值选择本次迭代需要的user stories，并且需要fix的失败的acceptace
tests也要选择。这两项都是iteration planning需要制定计划的。User stories和acceptance tests被分解为多个编程任务。任务要写在index cards上，就像user stories。User stories是用户语言，而任务是开发者语言。重复的任务要去掉，这些task cards会成为迭代的详细计划（detailed plan）。
被分配去完成任务的开发者要估算任务的完成时间。
每项任务的时间在1到3天。不足1天的任务要合并，超过3天的要分解。
Project velocity用来判断迭代是否超过预期。
迭代太短的话，就加入新的story。
Iteration planning中以天做为单位，而release planning中以周为单位。
要记住
unit testing和
refactoring 的重要性。
避免在将某项功能加入时间表之前加入到项目中，今天只做今天需要的。
不要试图改变对任务和story的估算。
计划依赖于对一致的estimate的真实性，捏造的estimate会产生很多问题。
随时注意project velocity和snow planning。每3到5周重新估算所有stories，
重新调整release plan是很正常的。
Development
pair programming
Daily Stand Up Meeting
Load Factor
Unit Tests
Refactoring
Make frequent small releases
just in time style of planning
unit tests
collective code ownership
system metaphor
用system metaphor来保持类和方法命名的一致性。
命名是关系到对系统的理解和代码重用的重要问题。
命名最好选用那些不需要专门知识也能理解的名字。
project velocity
project velocity是对项目中的正在进行的工作多少的量度。Project velocity是
对项目中的时间频率的度量（event rate of a project）。
Project velocity的使用：判断一个项目的进程是否慢了，判断生产率等。
为了度量project velocity，要将对迭代过程中结束的user stories的估算加起来，
还要将对迭代中完成的任务的估算加起来。
（未完。）
将制定计划看作一个游戏，游戏有目标，
pieces：最基本的piece是user story。每个user story写在index card上。
Story有价值和cost，同时value和cost可能会依赖其他的story，并且value和cost是变化的。
Goal目标：尽量将stories最可能的价值找出来。
Players：业务人员和开发人员。
Moves：
Write story：业务人员可以在任何时间写，要将story的value反应出来。
Estimate story：开发人员给每个story分别指定1到3周的时间，这是估计的
需要完成该story的时间。将时间控制在1到3周，超过3周的分解story，不到1周的合并story。
Make commitment：业务人员和开发人员一起决定哪些stories可以构成下一个版
本，并且应该在什么时候加入到产品中。
有两种方式来驱动commitement：
story driven commitement：
业务人员依次将需要的stories引入下一版本，
开发人员根据引入的stories估计下一版本的发布时间及截至时间，
当引入的stories对业务人员而言可以满足下一次发布时，停止。
date driven commitement：
业务人员规定一个发布的截至时间。
开发人员计算可以在截至时间前完成的stories的数量。
业务人员根据开发人员对stories数量的估算给出相应数量的
stories。
Value and Risk First
：开发人员根据
commitment
将
stories
排序，这样：
一个可以充分工作并且骨架性质的系统可以在短时间内完成。
越有价值的
stories
排在越前面。
越有风险的
stories
排在越前面。
Overcommitment recovery
：开发人员最初预计可以完成
150
个
stories
，但是当他
们对工程进展的速度
project velocity
重新估计之后，发现只能完成
100
个。这
时由业务人员选择
100
个，而将余下的
50
个做为下一版本的内容。
Change value
：如果业务人员改变了
story
的
value
的话，开发人员也在
stories
的
排序上做出相应的调整。
Introduce new story
：业务人员写了新的
story
，开发人员估计这个
story
。业务人
员推迟那些与新
story
的
cost
一样的已有的
stories
，开发人员将重新进行
value
and risk first
。
Slipt story
：Business splits a Story into two or more. Business assigns
a value to each, and Development assigns a cost to each. Typically
this is done because resources do not permit the whole story to be done soon enough.
Spike：如果一个spike不仅只是临时的，业务人员可以为spike编写一个story。
Re-estimate：开发人员对经过以上处理之后还被保留的commitment进行estimate。
1616
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
