《敏捷开发的实践》PPT课件.ppt

敏捷开发AgileDevelopment 内容 敏捷在时代 敏捷在华为 敏捷与精益 敏捷的实践保障 何为敏捷 标题 关键问题 甚么是敏捷 为什么要敏捷 如何敏捷 只有理解敏捷的概念 才能确定是否真正需要它 才能对比目前所面临的问题确定如何去实施它 在敏捷实践以外 我们是否还需要别的方式或者流程来帮助我们进行进一步的改善 敏捷 团队 方法论 工具 敏捷宣言人和交互重于过程和工具 可以工作的软件重于求全责备的文档 客户合作重于合同谈判 随时应对变化重于循规蹈矩 核心价值观沟通 简单 反馈 勇气 尊重 区别1 周期 短周期开发 提供及早的 具体的 持续的反馈 增量 增量开发 迅速地提出总体计划 并在项目生命周期中不断演化 反应 灵活安排功能地实现 以对变化的业务需求作出反应 自动 使用由程序员和测试人员编写的自动化测试来监控开发进度 支持系统演化 并尽早发现缺陷 区别2 交流 通过口头沟通 测试和源代码来交流系统的结构和意图 设计 渐进式的设计过程贯穿整个系统生命周期 协作 依赖于能力普通但能积极参与的程序员之间的紧密协作 实践 各种实践兼顾项目成员的短期直觉和项目的长期利益 解决开发中的风险1 提倡短周期发布 这样任何延迟的范围都是有限的 一个发布周期内 计划许多小任务以保证团队可以在该周期内解决问题 提倡优先实现高优先级的功能 最小发布必须是满足最大商业意义的 选择团队中面向业务的成员来承担 自动化测试 每次代码改动后运行 确保质量底线 保证系统处于可部署状态 不允许出现问题的积累 进度延迟 项目取消 系统恶化 既包含每个函数的单元测试 也包含专门测试人员的功能测试 缺陷率 解决开发中的风险2 业务人员成为团队人员 项目规格说明在开发过程中不断改进 由于缩短了发布周期 因此极大减少变更带来的影响 拥抱变化 利用重构解决变更带来的技术问题 坚持只解决最高优先级的任务 业务误解 业务变更 错误特性太多 团队开发模式 鼓励新成员承担越来越多的责任 互相帮助 要求程序员自己估算自己的工作时间并完成 人员流动 基本实践 富含信息的空间 坐到一起 迭代 结对编程 完整团队 增量设计 持续集成 测试先行编程 扩展实践 团队连续性 真实客户参与 单一代码库 共享代码 增量部署 代码和测试 敏捷与精益 lean 甚么是精益 站在终端用户的角度观察生产线 视任何未生产的增值活动为浪费 并通过持续地消除浪费达到快速交付 高质量和低成本地结果 丰田精益制造理念的产生 市场小 客户需求多变 通过减少浪费节约成本 最大的浪费就是生产过剩的浪费 精益的思考1 看板 故事墙 全面了解任务 充满信息的空间 变PUSH为PULL 零件只是零件吗 可以先生产零件吗 会增加甚么费用呢 还知道些什么呢 团队负责 团队来负责最终产品质量 生产线上任一环都需对质量负责 都不做 价值观 配对 standmeeting 脆弱的流程 流程的持续改进需要它是脆弱的 事务是变化的 需求 团队 目标 不等于不高效 不顺畅 流程是可以被测量的 精益的思考2 软件中的浪费 很快就荒废了的臃肿的需求文档 从未用过的精心构思的架构 完成很久都没有在产品环境中集成 测试和执行的代码 直到无关轻重或是会引起误解时才被人阅读的文档 举例拥有更精细的需求获取过程是不会改进需求获取的 通过缩短需求细节的产生与其相应的软件部署之间的路径是可以改善需求获取的 这意味着需求获取不是产生一份静态文档的阶段 而是贯穿开发整个过程的 再谈精益 1 以人为中心强调每个人在生产中的积极参与性和主动性 强调员工之间的协调优化 用激励的手段来激发人的主动性和协作性 最大限度地发挥员工的个人能力和群体智慧 2 降低库存 消除浪费将生产中的一切库存视为 浪费 出发点是整个生产系统 认为库存掩盖了生产系统中的缺陷 3 严把质量关产品质量是创造出来的不是检验出来的 认为 一切生产线外的检查 把关 返修都不能增加附加价值 反倒是增加了成本 是一种无效与浪费 一次通过率 4 拉动管理强调以最终用户的需求为生产起点 组织生产线依靠看板 Kanban 传递需求的信息 用后道工序开始按反工艺流程向前道工序 环环相连 层层连接 把生产紧密地联系起来 生产与市场需求数量一致的产品 敏捷与传统的比较 是员工的问题尽量优化各部门的工作快速交付和高质量意味着多花钱流程应 强壮 一些 把所有的保险都打开 小 问题会被吸收针对个人进行考核激励并管理员工谁犯的这个错了解并做好你的工作为了更好的预测 做个全面的分析大而集中能提高效率 是流程的问题系统思考 优化整体快速交付和高质量互为手段目的流程应 脆弱 一些 任何小问题都可以迫使它终止针对流程进行考核清除员工面临的障碍 开发员工是甚么让错误发生了我的工作如何配合其它部分只有频繁的预测才是可依赖的方法小而灵活才是美 CMMI 1 流程强壮 保险众多 持续改进成本高 人力浪费严重 2 很多文档是浪费的 不能为下阶段的开发提供帮助 好比生产的库存零部件 3 没有办法保障的流程是无用的 如华为的电脑准入制度 4 流程本身没有问题 但倾向于让人产生惰性 僵化 形式主义 华为困境 1 需求分解困难 对外可见度低 定制需求多 2 偏重于流程 CMM5级 3 公司围绕着市场转 市场不以公司的标准为转变 4 CMM5 RUP 迭代 XP SCRUM 华为经验1 认同 自上而下驱动的公司 主管对敏捷的认同是至关重要的 进度不紧张 没有进度不紧张的项目 OK let s敏捷 质量和进度冲突 决策和压力都在主管身上 员工不需要承担市场压力 只负责产品质量 教练 教练很重要 参与项目 协调沟通 编程 华为经验2 持续 在原则上持续坚持 在形式上持续改进 Codereview代码复查很重要 通过PAIR实现 TDD单元测试很重要 很多员工先写代码再写测试 需要TDD 当版本升级 以前的单元测试会废掉 TDD不会 机器能让机器做的事情就不要让人来做 人只作创造性的工作 做事方式 1 小粒度 快速反馈 迭代 2 简单设计 即使在电信级项目中 复杂问题简单化 3 自动化 持续集成 测试自动化 4 随机应变 响应变化 自适应计划 做事理念 1 以人为本 自我驱动 持续改进 个人和组织 2 不能凡事都是主管在想 这不能达到很高的高度 3 敏捷是方法论所保障的理念和思想 时代敏捷启动前提 领导支持很重要 我们与华为都是之上而下驱动的公司 认识是反复的 过程是反复的 专业的咨询公司是成功的保障 通过敏捷培训 通过一周实践的敏捷项目 理解并应用敏捷 领导支持 教练 熟悉敏捷 需要建立完善的软件工程工作组 需要在试点项目中尽量建立完善的团队角色 人员调整 技能需求1 1持续集成 精通cruise功能和配置 熟悉和编写各种脚本语言 xml JavaScript等 熟悉和配置各种语言的编译脚本 ANT Makefile等 2单元测试 熟悉C语言 掌握常用的mock框架用法 熟悉和理解各种软件设计模式 熟悉和理解重构 掌握TDD编程实践 3功能测试 一定的软件开发经验 熟悉软件开发过程 可以和开发人员进行需求和功能的探讨 熟悉测试流程和理念 4自动化工具 熟练使用各种高级语言编程 熟悉各种脚本语言编程 熟悉网络编程 技能需求2 5软件配置管理 深入理解软件版本管理思想 精通subversion和clearcase等工具的使用 可以根据不同的软件开发指定不同的软件管理策略 6编码规范和代码检查 熟悉风格和命名 ANSI K R Linux GNU Java Win 熟悉和理解MisraC 2004规范 根据不同的软件产品 指定适用于我们的编码规范 熟悉各种代码检查工具的使用 以及和各种IDE的融合 7静态和动态检测 有一定的编程经验 熟悉嵌入式系统编程 熟悉各种知名静态和动态检测工具 8敏捷实践 精确理解和掌握敏捷思想和各种实践 熟悉CMMI 丰富开发经验 具备项目管理能力以及一定的领导能力 思维开拓 善于总结经验 发掘新的适用于我公司的实践 组织架构 工具组 软件工程组 敏捷实践 测试组 单元测试 功能测试 持续集成自动化工具 编码规范和代码检查静态和动态测试 软件质量部 技术中心 软件配置管理 ThankYou