敏捷开发宣言精选.docVIP

敏捷开发宣言 通过亲身实践并帮助他人实践，我们正在揭示更好的软件开发方法。在这项工作中我们认识到： 个人和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 也就是说，尽管右边的条目也有价值，但我们认为左边的条目更有价值。 敏捷宣言背后的原则 我们的最高优先级是通过尽早地、持续地交付有价值的软件来满足客户。 欢迎变化的需求，即使在开发的后期。敏捷过程利用变化为客户创造竞争优势。 频繁交付能工作的软件，短则几周，长则几个月，时间间隔越短越好。 4.在整个项目开发过程中，业务人员和开发人员必须每天都在一起工作 项目开发以积极的个体为基础。为他们提供所需的环境和支持，并相信他们能完成工作。 向开发团队传递信息或者在开发团队内部传递信息，最高效、最有力的方法是面对面的交谈。 能工作的软件是度量进度的首要标准。 敏捷过程推动了可持续的软件开发。发起者、开发者和客户应该能长期维持一个恒定的速度。 对技术卓越和良好设计的持续关注能增强敏捷能力。 简单性（将未完成的工作最大化的艺术）是非常重要的。 最好的架构、需求和设计出自于自组织的团队。 每隔一定时间，团队应该反思一下如何变得更有效，然后相应地调整或校正其行为 XP概念 重构（Refactoring） 在功能（接口）不变的情况下改变代码的结构 目的：提高代码质量；使添加新特性更容易 技术债务（Technical Debt） 项目中不完美的设计和实现的总和 置之不理的话，技术债务会不断蔓延，直至彻底摧毁软件项目 XP采取积极的措施 时间限定（Timeboxing） 到时即结束 认清什么时候已拥有足够信息并非易事 为会议设置时间限定 最后责任时刻（The Last Responsible Moment） 延迟给了你时间，用以增加你做决定所需的信息 通过延时决定直到至关紧要的时刻，增加了决定的准确性，降低了工作量，并降低了 故事（Story） 故事以客户为中心，以业务结果描述结果 他们趋向于对应产品的单个特性，并且通常代表一到两天的工作量 不是实现细节，也不是完整的需求规格 迭代（Iteration） 迭代是设计-编码-验证-发布的整个周期 是一种时间限定，通常1到3周 迭代开始于故事列表，结束于可以工作的软件 速度（Velocity） 一个迭代中所完成的故事的估算总和 一般来说，团队应当能够在每次迭代中实现同样的速度 约束理论（Theory of Constraints） 在某种程度上，每个系统都有单一的约束，决定了系统的整体生产能力 本书假定程序员你所在团队的约束 专注（Mindfulness） 敏捷性需要每个人关注开发的流程和实践 结对编程 什么是结对编程？ 两个程序员共用一台工作站进行工作 一个负责写代码（驾驶员Driver），一个负责思考（领航员Navigator）或评审代码（观察者Observer） 两人频繁交换角色 结对编程的优势 减小程序缺陷，提高质量：与分开编程相比，驾驶员和领航员一起工作可以更快地、更高质量地完成工作。 释放驾驶员，使他们专注于编写严谨的、没有语法错误的代码，而不用担心整体架构 同时，领航员不必分心去思考编程细节，有机会去思考大的策略问题 在团队成员中分享知识：有利于好的编程知识和技巧很好地推广到整个团队 支持自律行为：加强好的编程习惯 减少注意力分散：当你和一个人一起工作时，办公室里的同事不太可能打断你们 保证工作效率：长时间打字使你的手腕疼痛时，你可以把键盘交给同伴，让他继续高效地工作 怎样结对 所有的工作都可以结对进行 自由结对，而不是指派 如果你需要新的思路，就去交换合作伙伴 避免一天只同一人结对 并排着，坐得舒服些（结对工位） 一边交谈，一边写代码。协作，而不是挑毛病 经常交换驾驶员和领航员的角色（至少每半小时一次，也可以几分钟一次 回顾的类型 迭代回顾 发布回顾 项目回顾 惊讶突然回顾 回顾 回顾的目的 通过分享大家的想法，让团队变得更紧密 得出使团队得以提高的具体方法 回顾的理想效果 整个团队变得更加紧密和团结 每个小组对其他小组的问题给予更多的尊重 对自己的成功和失败更加真诚和开放 对变化更加适应 站立会议 每天，在一个预订的时间，整个团队站着围成一圈。轮流着，每个人简要描述一下团队需要知道的新信息 更正式的做法：回答3个问题 我昨天做了什么 我今天将要做什么 有什么问题妨碍我们取得进展 站立会议的目的是给每个人一个大致的概念，使他们了解团队走到哪里了 它的主要优点是简洁性 限制用时5-10分钟，根据团队大小确定 站立的双脚也是为了提醒我们保持简洁 迭代演示 概念：开发者向利益攸关者演示每次迭代的成果 意义 是一次团队进展的具体演示 这种演示使团队诚实地汇报进展 演示是从客户请求反馈的机会