敏捷开发的实践精选课件.pptVIP

区别 1 周期 短周期开发，提供及早的、具体的、持续的反馈。 增量 增量开发。迅速地提出总体计划，并在项目生命周期中不断演化。 反应 灵活安排功能地实现，以对变化的业务需求作出反应。 自动 使用由程序员和测试人员编写的自动化测试来监控开发进度，支持系统演化，并尽早发现缺陷。 坚持 区别 2 交流 通过口头沟通、测试和源代码来交流系统的结构和意图。 设计 渐进式的设计过程贯穿整个系统生命周期。 协作 依赖于能力普通但能积极参与的程序员之间的紧密协作。 实践 各种实践兼顾项目成员的短期直觉和项目的长期利益。 坚持 解决开发中的风险 1 提倡短周期发布，这样任何延迟的范围都是有限的。 一个发布周期内，计划许多小任务以保证团队可以在该周期内解决问题。 提倡优先实现高优先级的功能。 - 最小发布必须是满足最大商业意义的，选择团队中面向业务的成员来承担。 自动化测试，每次代码改动后运行，确保质量底线。 保证系统处于可部署状态，不允许出现问题的积累。 进度延迟 项目取消 系统恶化 - 既包含每个函数的单元测试，也包含专门测试人员的功能测试。 缺陷率 坚持 解决开发中的风险 2 业务人员成为团队人员，项目规格说明在开发过程中不断改进。 由于缩短了发布周期，因此极大减少变更带来的影响。 拥抱变化，利用重构解决变更带来的技术问题。 坚持只解决最高优先级的任务。 业务误解 业务变更 错误特性太多 团队开发模式，鼓励新成员承担越来越多的责任，互相帮助。 要求程序员自己估算自己的工作时间并完成。 人员流动 坚持 基本实践 基本 富含信息的空间 坐到一起 迭代 结对编程 完整团队 增量设计 持续集成 测试先行编程 坚持 扩展实践 扩展 团队连续性 真实客户参与 单一代码库 共享代码 增量部署 代码和测试 坚持 敏捷与精益(lean) 甚么是精益？ 站在终端用户的角度观察生产线，视任何未生产的增值活动为浪费，并通过持续地消除浪费达到快速交付，高质量和低成本地结果。 丰田精益制造理念的产生？ 市场小，客户需求多变。 通过减少浪费节约成本，“最大的浪费就是生产 过剩的浪费” 坚持 精益的思考 1 看板？故事墙？ 全面了解任务，充满信息的空间。 变PUSH为PULL。 零件只是零件吗？ 可以先生产零件吗？会增加甚么费用呢？ 还知道些什么呢？ 团队负责？ 团队来负责最终产品质量。生产线上任一环都需对质量负责。 都不做？价值观，配对，stand meeting。 脆弱的流程？ 流程的持续改进需要它是脆弱的。 事务是变化的，需求、团队、目标。 不等于不高效，不顺畅。 流程是可以被测量的。 坚持 精益的思考 2 软件中的浪费？ 很快就荒废了的臃肿的需求文档。 从未用过的精心构思的架构。 完成很久都没有在产品环境中集成，测试和执行的代码。 直到无关轻重或是会引起误解时才被人阅读的文档。 举例 拥有更精细的需求获取过程是不会改进需求获取的。 通过缩短需求细节的产生与其相应的软件部署之间的路径是可以改善需求获取的。 这意味着需求获取不是产生一份静态文档的阶段，而是贯穿开发整个过程的。 坚持 再谈精益 1. 以人为中心 强调每个人在生产中的积极参与性和主动性，强调员工之间的协调优化，用激励的手段来激发人的主动性和协作性，最大限度地发挥员工的个人能力和群体智慧。 2. 降低库存、消除浪费 将生产中的一切库存视为浪费，出发点是整个生产系统，认为库存掩盖了生产系统中的缺陷。 3.严把质量关 产品质量是创造出来的不是检验出来的，认为“一切生产线外的检查、把关、返修都不能增加附加价值，反倒是增加了成本，是一种无效与浪费”。一次通过率。 4.拉动管理 强调以最终用户的需求为生产起点。组织生产线依靠看板(Kanban)传递需求的信息。用后道工序开始按反工艺流程向前道工序，环环相连，层层连接，把生产紧密地联系起来，生产与市场需求数量一致的产品。 坚持 敏捷与传统的比较 传统思维 是员工的问题 尽量优化各部门的工作 快速交付和高质量意味着多花钱 流程应”强壮“一些，把所有的保险都打开，“小”问题会被吸收 针对个人进行考核 激励并管理员工 谁犯的这个错 了解并做好你的工作 为了更好的预测，做个全面的分析 大而集中能提高效率 精益思维 是流程的问题 系统思考，优化整体 快速交付和高质量互为手段目的 流程应”脆弱“一些，任何小问题都可以迫使它终止 针对流程进行考核 清除员工面临的障碍，开发员工 是甚么让错误发生了 我的工作如何配合其它部分 只有频繁的预测才是可依赖的方法 小而灵活才是美 坚持 CMMI？ 1 流程强壮，保险众多，持续改进成本高，人力浪费严重。 2 很多文档是浪费的，不能为下阶段的开发提供帮助。好比生产的库存零部件。 3 没有办法保障的流程是无用的。如华为