敏捷开发最佳实践

敏捷开发最佳实践 liujia 11年6月8日星期三 什么是敏捷开发 敏捷开发是一种以人 为核心、迭代、循序 渐进的开发方法 源于XP、始于雪鸟 11年6月8日星期三 敏捷宣言 个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合作谈判 响应变化高于遵循 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此 我们建立了如下价值观 也就是说，尽管右项有其价值， 我们更重视左项的价值 敏捷宣言 敏捷原则 Kent Beck 11年6月8日星期三 主要内容 敏捷九大实践 scrum简介 xp简介 11年6月8日星期三 敏捷九大实践 1、完整团队 6、单元测试 2、迭代开发 7、测试驱动开发 3、站立会议 8、持续集成 4、结对编程 9、代码集体所有 5、简单设计 11年6月8日星期三 完整团队 项目所有成员在同一个开放场所内工作 墙上挂置显示进度的图表 信息辐射器：传递重要信息 架构师必须写代码 频繁反馈 11年6月8日星期三 迭代开发 在小且重复的周期里，你完 成各种开发任务：分析、设 计、实现、测试和获得反 馈。 对付大项目，要小步前进， 这也是敏捷的核心 迭代周期不要太长也不要太 短，建议4周左右 不要随意变动迭代时间点 11年6月8日星期三 站立会议 不允许坐着，只能站着 不要发散，只回答三个问题 每人两分钟，总体小于30分钟 安排在工作日的早些时候，但不要作为第一件事 大团队需要每天碰头，小团队可以适当减少 11年6月8日星期三 结对编程 两个人在一台机器上， 一起工作，一个编码， 一个看 优势 效率高、质量好 多角度、快速解决问题 直接连续的code review 于别人工作会增加责任和纪律性 避免偷懒、溜号 11年6月8日星期三 简单设计 设计的复杂度应满足当前需求，多则画蛇添足 前提是自动化测试和重构 简单设计的优势： 基于当前需求，不考虑未知因素 节约成本，减少设计的累计开销 易于理解、易于改变 简单 设计 重构 自动化 测试 11年6月8日星期三 单元测试 让代码更加健壮 让你自信的后台 解决问题的探测器 可信的文档 指导 设计/重构 及时提供反馈 11年6月8日星期三 测试驱动开发 测试－》编码－》重构 循环 根据需求写测试，而不是代码 促进松耦合、面向接口设计 自动化执行、问题及时发现 推动进程、进度跟踪的完美 RED GREEN REFACTORY 11年6月8日星期三 提早集成、持续集成 编译＋自动化测试＋问题日志 频繁集成：每天5～10次，或更多 优势 提早集成，提前发现问题，保证质量 提升效率，缩短上市时间 增加项目可见度 11年6月8日星期三 休息一下： 看看thoughtWorks是如何测试的 100%自动化；90％以上覆盖率；持续集成 100%自动化；N/A；持续集成 90%以上自动化；N/A；持续集成 测试分析师对应用程序的质量有信心 满足需求，用户认可可用性 100％自动化，满足性能需求 业务人员和操作员确认满足需求 确信数据被正确移植 应用程序在生产环境中安装正确 11年6月8日星期三 集体代码所有权 概念：开发团队中的任何人都有权利和责任修改任何 一部分代码 优势： 提升开发者的知识水平和责任心 灵活，摆脱“创可贴”式的补丁开发方式 11年6月8日星期三 scrum简介1 PD PM 11年6月8日星期三 scrum简介2 SCRUM基本概念 Backlog - 可以预知的任务集，包括功能性的和非功能性的所有任务 Sprint - 一次迭代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的 Backlog Product Owner - 这个角色被称为产品经理。他负责定义产品并向开发团队提出需求，最终验收开发团队的工作成果 Scrum Master - 负责监督整个Scrum进程、修订计划的一个团队成员 Sprint planning meeting - 在启动每个Sprint前召开。一般为一天时间（8小时）。 Daily scrum meeting - 开发团队成员参加，一般为15分钟 Sprint review meeting - 在每个Sprint结束后，将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一 般该会议为４小时 Sprint retrospective meeting - 对刚结束的Sprint进行。会议的参与人员为团队开发的内部人员。一般该会议为 ３小时 11年6月8日星期三 scrum简介3 唯一 标识 简短 名称 重要性 初始 估算 如何演 示成果 注解 燃尽图 11年6月8日星期三 xp简介 11年6月8日星期三 最后几句话 实践会过时，敏捷不会过时 形势不重要，重要的思想 不要为了敏捷而敏捷，适合才能敏捷 理论结合实际，具体情况具体分析 11年6月8日星期三 the end & thanks 往下看－附录内容也精彩 11年6月8日星期三 附：推荐书籍 agile patterns books 软件开发沉思录 高效程序员的45个习惯 测试驱动开发 修改代码的艺术 重构 11年6月8日星期三 附：敏捷漫画 更多请看 11年6月8日星期三 附：当有以下异味时，可以 考虑引入敏捷 业务异味 流程异味 交付质量无法令客户接受 项目组成员对立 交付新功能需要太长时间 客户不管三七二十一，什么都要 有些功能客户没有使用 无法实现直接、经常性的客户参与 软件对于用户用处不大 进度缺乏可见性 构建软件太过昂贵 项目反复拖延 bug过多 没有经常集成 --摘自《agile patterns book》 11年6月8日星期三 附：应对异味 业务 异味 流程 异味 --摘自《agile patterns book》 11年6月8日星期三