敏捷开发的实践.pptxVIP

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