敏捷开发XP

一、组建XP团队

在XP团队中，由以下组成

 

 

二、项目相关环境

1、利益相关者：与PM一样，对项目进行管理

2、执行发起人：最终客户（必须定期演示）

 

三、XP组成

四、思考

     1、结对编程

     结对编程中，一个人写，一个人思考。结对编程可以防止被打扰，可以提高精力

     2、精力充沛的工作

     按时下班，不把工作带回家，健康饮食，经常锻炼。

     3、信息化工作场所

     通过各种信息（图表等）贴在工作场所，以随时了解项目进度、当前情况，同时通过图表监控、测评项目。

     4、根源分析

     遇到问题不要想责备，问自己为什么会出现这个问题，寻求问题根源

     5、回顾

     在一次会议中引导一个人说过话，那么他继续说话的可能性就会加大

 

五、协作

1、信任

     团队内部需要和谐团结，与客户（关系人）的关系弄好。可以采用：客户与程序员换位思考、程序员与测试员换位思考、共同进餐、团队持续性（以团队为单位做项目）。坦然面对错误，及早与关系人坦白困难、错误，共同面对问题。定期交付，维护与关系人的关系。

2、坐到一起

     团队的所有成员需要在同一个场所办公。现场客户、程序员、测试员等。这样可以及时交流、高效沟通。但是也提供一个私密的小房间供打电话、聊天等。

3、真实客户参与

     有了真实用户的参与，就不会让自己陷入各种细节。扩大自己的视角。利用他们在实际中如何使用软件、他们的领域知识，可以让你交付一款真正有用的产品。

4、统一协作语言

     采用同一种语言，可以较少程序员与客户专家的沟通障碍。比如程序员采用客户领域的术语进行图表的绘制、命名。

5、站立会议

     在一个固定的时间召开。每次不要超过十分钟。时间不一定在早上，可以上午结束的时候。会议由每个人讲需要让整个团队知道的事情。可以以“我昨天做了什么、今天打算做什么、遇到了什么问题”的格式，也不一定得按照这个格式。

6、编码规范

     编码的规范可以包含：开发实践、工具和快捷键、文件和目录布局、构建和约定、错误处理和断言、实践和日志记录方式、设计约定等。规范的设计，以“1、指定可以接受的最小标准集合 2、关注一致性和共识，而不是完美”。

     在制定规范后，如果有人没有按照规范，可以和他谈：认为这个规范怎么样，为什么没有按照规范。

7、迭代演示

     迭代演示可以降低风险，增加活力，促进团队进步。XP的核心就是定期交付。在演示的过程中，可以解释为什么和原计划不同，有什么变化。若客户具体到某一细节，可以说在演示结束后由项目经理解释。在演示结束后问客户：1、到目前为止客户是否满意。2、是否可以继续。如果在演示中，客户提到需要添加新特性，则说：会后由产品经理负责特性的把关与添加。

8、汇报

     进行良好的汇报，可以增加客户对团队的信任，更相信团队的决策。

     进展汇报：愿景陈述、每周演示、发布和迭代计划、burn-up图。如果需要更详细，可以提供路线图   、状态电子邮件

     管理汇报：生产率、产能、缺陷、时间利用率

     不要汇报：源代码行数、故事数、开发速度、代码质量等

 

六、发布

1、全部完成

     全部完成是指可以发布使用。平时以全部完成来要求团队，可以避免大量难以预计的收尾工作。完成包含测试完成、编码完成、设计完成、集成完成、成功构建、安装、移植、评审完成、修复完成、用户接受。TDD可以促使设计、测试、编程同步完成。

2、没有bug

     a.编写更少的bug：采用TDD，可以减少一定bug。或者通过大量技术和组织方法尽量减少bug的生成。

     b.消除bug的温床：通过重构设计不良的代码可以减少bug

     c.修复bug：尽早修复bug，越到最后代码修复的成本就越大。

     d.测试过程：通过探索性测试，以不寻常的方式进行测试，可以检测预料之外的bug

     e.修正过程：对自己进行总结，查找为什么会出现bug，对自己的编码过程就行改正。

3、版本控制

     版本控制可以管理项目，可以进行回退等

4、十分钟构建

     自动化构建，可以避免很多问题。可以利用ant、make等进行构建。当项目在很小的时候进行自动化构建。尽量不要让构建的时间太长。

5、持续集成

     持续集成能够减少很多隐藏的发布时间。每隔几小时进行集成，保证构建、测试及其他发布的基础组件都能及时更新。这样可以降低发布难度。

6、代码集体所有制

     这样可以让整个团队为所有代码复制。每个人都可以改进别人的代码。这样可以在一个人离开时，团队还能继续推进。实在无法实施集体所有制，可以通过结对编程折中。

7、文档

     文档不用很多，但是因为有更好有效的交流方式，不是偷懒的借口。不需要特定去做什么文档，如果一些文档有商业价值，将其安排为一个user story进行操作。

 

七、计划

1、愿景

     揭示项目正在朝哪个方向前进，以及为什么朝这个方向前进。制定愿景时，可以从：项目应该完成什么、项目为什么有价值、项目的成功标准是什么。愿景指定后就推广出去，贴在工作场所，要求客户一同参与愿景指定。如果有了一份清晰、有说服力的远景，则很容易为故事安排优先级。同时团队成员了解项目的重要程度，有助于提高士气。

2、发布计划

     在接受项目时，尽量只做一个项目，不要几个一起做。同时尽早发布，经常发布，将最有价值的特性先发布出去，有助于提升商业价值。在发布的时候，不要全部把所有的发布出去，为自己留一些余地，不要一次性全部发布。计划需要不断调整，让客户清楚你的计划。可以以时间为标准进行计划。

3、计划博弈

     在计划生成后，对计划的具体安排需要讨论。在对计划进行实施时，良好的计划博弈，是让程序员觉得自己的专业知识对计划进行了贡献，客户觉得自己的领域知识做出了优先级划定。

4、风险管理

     随时对风险进行把控、预测、应对。及时当开发中断也能成功交付，这样以后公司会更加信任你。

5、迭代计划

     每次选择最后价值的特性加入其中进行迭代。一次迭代，由：演示演一轮迭代、回顾前一轮迭代、制定迭代计划、承担故事的交付、开发故事、准备发布。一般在一周完成。在发布了迭代任务后，对任务进行跟踪。

6、松弛

     在迭代中添加松弛制度，增加研究时间，不要太紧。

7、故事

     以用户为中心，用一个个卡片来整理故事。太大的故事进行拆分。故事由客户进行把关。同时也可以包含文档故事、非功能故事、bug故事、试验故事、估算、会议等。将故事分小，可以频繁交付完整特性。

8、估算

     做良好的估算，在每次迭代中都是一致和可预测的。估算时，对故事进行充分分析和挖掘。

 

八、开发

1、增量式需求

     客户可能开始不能确定全部的需求，不用担心。那就开始在已经确定的上面工作。但是客户的每次反馈都需要记录，客户签字，防止客户否认

2、客户测试

     对于每个特性，创建客户测试可以通过描述、演示、开发进行。描述是由客户详细、举例描述功能。让用户领导进行客户测试，引导他们参与

3、测试驱动开发

     在开发前先写测试，这样你在开发时，会自动对你的开发过程进行把控

4、重构

     在平时对代码进行重构，持续提高代码质量

5、简单设计

6、增量设计和架构

7、试验方案

8、性能优化

9、探索性测试

 

XP的价值：简单、勇气、沟通、反馈、尊重。

在实践中避免浪费，若项目一定会失败，则尽早失败。