你的位置:首页 > ASP.net教程

[ASP.net教程]敏捷开发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的价值:简单、勇气、沟通、反馈、尊重。
在实践中避免浪费,若项目一定会失败,则尽早失败。