《敏捷开发宣言.doc》由会员分享，可在线阅读，更多相关《敏捷开发宣言.doc（9页珍藏版）》请在金锄头文库上搜索。
1、敏捷开发宣言通过亲身实践并帮助他人实践，我们正在揭示更好的软件开发方法。在这项工作中我们认识到： 个人和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划也就是说，尽管右边的条目也有价值，但我们认为左边的条目更有价值。敏捷宣言背后的原则1. 我们的最高优先级是通过尽早地、持续地交付有价值的软件来满足客户。2. 欢迎变化的需求，即使在开发的后期。敏捷过程利用变化为客户创造竞争优势。3. 频繁交付能工作的软件，短则几周，长则几个月，时间间隔越短越好。4.在整个项目开发过程中，业务人员和开发人员必须每天都在一起工作5. 项目开发以积极的个体为基础。为他们提
2、供所需的环境和支持，并相信他们能完成工作。6. 向开发团队传递信息或者在开发团队内部传递信息，最高效、最有力的方法是面对面的交谈。7. 能工作的软件是度量进度的首要标准。8. 敏捷过程推动了可持续的软件开发。发起者、开发者和客户应该能长期维持一个恒定的速度。9. 对技术卓越和良好设计的持续关注能增强敏捷能力。10. 简单性（将未完成的工作最大化的艺术）是非常重要的。11. 最好的架构、需求和设计出自于自组织的团队。12. 每隔一定时间，团队应该反思一下如何变得更有效，然后相应地调整或校正其行为XP概念 重构（Refactoring） 在功能（接口）不变的情况下改变代码的结构 目的：提高代码质量
3、；使添加新特性更容易 技术债务（Technical Debt） 项目中不完美的设计和实现的总和 置之不理的话，技术债务会不断蔓延，直至彻底摧毁软件项目 XP采取积极的措施 时间限定（Timeboxing） 到时即结束 认清什么时候已拥有足够信息并非易事 为会议设置时间限定 最后责任时刻（The Last Responsible Moment） 延迟给了你时间，用以增加你做决定所需的信息通过延时决定直到至关紧要的时刻，增加了决定的准确性，降低了工作量，并降低了 故事（Story） 故事以客户为中心，以业务结果描述结果 他们趋向于对应产品的单个特性，并且通常代表一到两天的工作量 不是实现细节，也不
4、是完整的需求规格 迭代（Iteration） 迭代是设计-编码-验证-发布的整个周期 是一种时间限定，通常1到3周 迭代开始于故事列表，结束于可以工作的软件 速度（Velocity） 一个迭代中所完成的故事的估算总和 一般来说，团队应当能够在每次迭代中实现同样的速度 约束理论（Theory of Constraints） 在某种程度上，每个系统都有单一的约束，决定了系统的整体生产能力 本书假定程序员你所在团队的约束 专注（Mindfulness） 敏捷性需要每个人关注开发的流程和实践结对编程 什么是结对编程？ 两个程序员共用一台工作站进行工作 一个负责写代码（驾驶员Driver），一个负责思考
5、（领航员Navigator）或评审代码（观察者Observer）两人频繁交换角色结对编程的优势 减小程序缺陷，提高质量：与分开编程相比，驾驶员和领航员一起工作可以更快地、更高质量地完成工作。 释放驾驶员，使他们专注于编写严谨的、没有语法错误的代码，而不用担心整体架构 同时，领航员不必分心去思考编程细节，有机会去思考大的策略问题 在团队成员中分享知识：有利于好的编程知识和技巧很好地推广到整个团队 支持自律行为：加强好的编程习惯 减少注意力分散：当你和一个人一起工作时，办公室里的同事不太可能打断你们 保证工作效率：长时间打字使你的手腕疼痛时，你可以把键盘交给同伴，让他继续高效地工作怎样结对 所有的
6、工作都可以结对进行 自由结对，而不是指派 如果你需要新的思路，就去交换合作伙伴 避免一天只同一人结对 并排着，坐得舒服些（结对工位） 一边交谈，一边写代码。协作，而不是挑毛病经常交换驾驶员和领航员的角色（至少每半小时一次，也可以几分钟一次回顾的类型n 迭代回顾n 发布回顾n 项目回顾n 惊讶突然回顾回顾n 回顾的目的n 通过分享大家的想法，让团队变得更紧密n 得出使团队得以提高的具体方法n 回顾的理想效果n 整个团队变得更加紧密和团结n 每个小组对其他小组的问题给予更多的尊重n 对自己的成功和失败更加真诚和开放n 对变化更加适应站立会议n 每天，在一个预订的时间，整个团队站着围成一圈。轮流着，
7、每个人简要描述一下团队需要知道的新信息n 更正式的做法：回答3个问题n 我昨天做了什么n 我今天将要做什么n 有什么问题妨碍我们取得进展n 站立会议的目的是给每个人一个大致的概念，使他们了解团队走到哪里了n 它的主要优点是简洁性n 限制用时5-10分钟，根据团队大小确定站立的双脚也是为了提醒我们保持简洁迭代演示n 概念：开发者向利益攸关者演示每次迭代的成果n 意义n 是一次团队进展的具体演示n 这种演示使团队诚实地汇报进展n 演示是从客户请求反馈的机会n 如果进度出现问题，迭代演示使问题暴露出来怎样做迭代演示n 团队中任何人都可以做迭代演示，但最好是让产品经理来做n 把所有感兴趣的人请过来n
8、整个演示应该占10分钟左右n 简单描述一下本次迭代所安排的特性以及它们对项目的价值n 依次把各个故事过一遍，并演示完成的效果全部完成n 意义：保证已完成的软件是可以被发布的n 含义：代码可以投入使用（可以部署）n 针对故事n 一个故事完成之后不会是一堆没有集成、未经测试的代码，而是为部署做好了准备n 部分完成的故事会导致项目的未知开销，当发布时间到来，你将不得不面对完成未知工作量的挑战全部完成n 一个可能的故事完成标准n 测试完成n 编码完成n 设计完成n 集成完成n 成功构建n 成功安装n 成功移植n 评审完成、修复完成、用户接受如何达到“全部完成”n 利用测试驱动开发将测试、编码和设计环节
9、结合在一起n 应用持续集成并保持十分钟构建与项目进展同步n 让现场客户加入你的工作：确认需求，迭代演示n 当你整合多个模块时，运行事软件以确保所有模块可协同工作n 及时修复Bug版本控制n Version controln Revision controln Source controln SCM: Software Configuration Management n 版本控制系统：提供了一个中心仓库，可用于管理文件变更，并提供变更历史记录。基本概念n 仓库（Repository）n 所有文件及其变更历史的主要存储池n 工作副本（Working copy）n 也称沙箱（Sandbox），团队
10、成员在自己的开发机上工作的对象n 签出（Check out）n 从仓库签出到本地建立一个沙箱n 更新（Update）n 从仓库中获得最新的版本到沙箱n 提交（Commit）n 把沙箱中的内容保存到仓库中n 回复（Revert）n 回复沙箱的内容到上次更新时的状态n 前端（Head）n 仓库中的最新的版本n 分支（Branch）分支保持完全独立并发编辑n 自动合并更新n 如果两个人修改了同一行代码，系统会提醒手工合并时间旅行n 版本控制系统的最强大之处在于回到过去的能力n 可以将所有文件回复到以前的某一个时间点n 尽量将工具、库、文档及其他所有与项目相关的东西都存放在版本控制系统中n 不要把编译
11、时生成的代码、文件提交到仓库中去分支的使用n 尽量维护单一的代码库n 通过分支提供软件的不同定制版是危险的n 应将代码设计为支持不同的配置n 仅当作为短期存活的对象或被用来管理少量修改时候，分支才能发挥最大作n 在发布点创建分支比为准备发布而创建分支更有意义风险管理n 正常情况下，XP团队确实能达到稳定的速度n 意外总会发生n 团队成员生病或休假了n 硬盘坏了n 备份不能恢复n 上两个月完成的功能需要做重大调整n XP使用风险管理来应对意外一般的风险管理计划n 每个项目都会面对一组常见的风险n 推翻以前的工作n 出现新的需求n 工作中断n 这些风险会对你的时间估算带来倍增的效应，双倍或三倍地增
12、加你完成工作所需要的时间n 这些风险带来多大的倍增效应，取决于你的组织项目特定的风险n 采用XP实践并运用风险倍增系数可以帮你抑制那些常规风险n 有缺陷的发布计划n 正常的需求增长n 员工的更替n 除此之外，你还可能会面对一些特定于你的项目的风险n 要管理这类风险，应创建风险普查，即项目所面对的风险列表项目特定的风险n 有了风险列表后，分析风险n 估算可能性n 如果产生这种风险，它对项目的特定影响是什么？经济损失、工期延迟、项目取消等。n 你发现某些风险并不重要，因此不再考虑它们n 对于剩下的，确定你是否可以不采取动作而避免这种风险；预留更多的时间和资金来容纳它；或者采取减轻其影响的步骤来缓解
13、它风险敞口n 反应了你应该预留多少时间或资金来容纳风险n 计算：风险的数值概率X风险的影响怎样承担发布任务n 基于风险敞口和风险倍增系数，你可以预测出在发布日期之前你能完成多少个故事点怎样承担发布任务n 如果你正在使用一种严格的方法，离发布还有12次迭代，速度是每次迭代14点，风险敞口是一次迭代，则n 剩余点数=（12-1）*14=154点n 10%几率：154/1=154点n 50%几率：154/1.4=110点n 90%几率：154/1.8=86点成功比时间更重要n 刚才的讨论主要关注于管理风险以满足时间进度n 而真正的目标是以项目愿景中的成功标准为指导，交付成功n 在评估风险的时候，考虑
14、风险对项目成功的影响，而不仅仅是对时间表的影响估算n 估算往往成为程序员必须做的最困难的事情之一n 原因之一是程序员很难预测他们将花费多少时间n 一项需要8小时不间断专注的任务可能花费了两三天n 要把估算做好，在于预测项目所需耗费的努力，而不是日历时间如何估算？理想工程天数n 要基于理想工程天数来进行估算n 是指在你将全部精力贯注于某项任务且不会受到任何干扰的情况下，这项任务所需的天数n 理想工程天数也叫故事点n 仅有理想工程天数是不够的，理想工程天数如何与日历时间形成关联？速度n 速度是你在一次迭代中完成的故事点数n 通过速度，可以将估算转化为日历时间n 一个成熟的XP团队，速度将足够稳定，可以按很高的准确度来预测速度（见下图）做出准确估算的技巧n 基于理想工程天数进行估算，而不是日历日期n 使用速度来确定团队在一次迭代中能完成多少故事点n 使用迭代松弛来平息意外状况，按时交付每次迭代n 使用风险管理，根据风险对整体发布计划做调整怎样估算故事n 当你开始估算一个故事的时候，设想一下实现它所需要的工程任务n 向现场客户询问他们的期望，并关注那些会影响你估算的事情n 估算精确到半个点是可以的，但四分之一点应该没有必要n 如果你需要更深入地研究一种技术，就创建一个试验方案，先估算该方案怎样估算迭代任务n 在制定迭
