敏捷
敏捷宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
敏捷开发原则
- 客户满意（有价值软件）
- 结果导向（可工作软件）
- 拥抱变化（需求变化）
- 保持节奏
- 短迭代交付
- 追求卓越
- 业务参与（业务人员+开发人员）
- 简单务实（以简洁为本）
- 以人为本
- 团队自组织
- 面对面沟通
- 持续改进
敏捷=理念+优秀实践+具体应用
- 聚焦客户价值
- 激发团队
- 适应变化
聚焦客户价值
- 消除浪费
- 交付刚刚好系统
- 随时构建质量，不容忍缺陷
- 及时消除技术债务，持续保持快速响应
激发团队
- 认清团队的基本事实
- 敏捷方式下管理者的转变
- 敏捷方式下团队成员的转变
- 认清：客户是逐步发现真正需求
适应变化
- 小批量是快速交付的关键
- 通过迭代计划不断调整以适应需求变化
- 持续保持良好的软件架构
- 利用多层次反馈不断调整以逼近目标
敏捷实践
迭代开发 + 团队 + 工作件 + 管理实践 + 技术实践
角色职责
- PO：产品负责人
- Scrum：教练
- Team：开发团队
敏捷工作件
- 产品Backlog
- 通过优先级排序的动态刷新的产品需求清单
- 用来制定发布计划和迭代计划
- 迭代Backlog
- 一轮迭代中的任务清单
- 从产品backlog中挑选出来要在本轮迭代中实现的
- 每项任务信息包括当前剩余工作量和责任人
- 完成标准
- 基于随时可向用户发布的目标判定的标准
- 迭代计划会议
- 迭代启动前，输入是产品Backlog，输出是团队Backlog
- 每日站立会议
- 我昨天为项目做了什么
- 我计划今天为项目做什么
- 我需要什么帮助可以更高效的工作
- 可视化管理
- 将项目状态通过白板，屏幕实时展示
- 迭代验收
- 每次迭代结束时，通过演示可工作的软件检查需求是否满足客户需求
- 迭代回顾会议
- 每轮迭代结束时的会议，来总结经验
- 全员参加
- PSP
- 潜在可交付产品增量
敏捷工程实践
- 用户故事
- 站在用户角度描述需求
- 用户故事便于团队站在用户角度分解细化需求并制定验收标准
- 作为一个XXX客户角色，我需要XXX功能，带来XXX好处
- 结对编程
- 一个编程，一个检查编程
- 经常切换
- 一个新的story开发时可以变换搭档
- 测试驱动开发（TDD）
- 以测试作为编程的中心
- 在编写任何代码之前，首先编写定义代码功能的测试用例
- 测试要完全可以自动化运行
- 提高代码的安全性和可测试性
- 持续集成（CI）
- 团队的成员经常集成他们的工作，每人每天至少集成一次
- 每次集成通过自动化构建完成
- 提供大量短期反馈，避免最终集成时爆发大量问题
- Anatomy系统解剖
- 从用户角度全面展示复杂产品系统的功能依赖表
- 整个系统的功能按自底向上逐步有序的开发和集成
精益
精益软件开发七项原则（代码简化）
- 消除浪费
- 缺陷：导致昂贵的返工，没有增加价值的浪费（未完成的工作）
- 预防缺陷：测试
- 发现缺陷：找到根源，避免再次出现
- 自动化测试
- 创建新的测试来监视这个缺陷
- 过度生成：消除额外的特征（未应用的特性）
- 运输：避免传递，减少知识的丢失（传递）
- 等待：减少延迟（延迟）
- 设置包含所有成员的集成式产品队伍：包括客户（代表）
- 库存：减少半成品工作（未落地的工作）
- 使用单件流
- 不让半成品堆积
- 移动：减少任务切换和中断（任务切换）
- 过渡：减少不必要流程（过度作业）
- 缺陷：导致昂贵的返工，没有增加价值的浪费（未完成的工作）
- 内建质量
- 不要推迟缺陷
- 使用测试驱动，提前解决缺陷
- 创建知识
- 不要忘记已经学到的经验教训
- 记录团队的经验
- 推迟决策
- 得到足够可用信息时才进行决策
- 但是不能阻碍项目其他方面的发展
- 基于集合的设计
- 快速交付
- 以较短的迭代，以小批量的方式开发功能，并快速交付给客户
- 对人尊重
- 积极投身其中,并思考着的人,提供了最可持续发展的竞争优势
- 不要浪费最宝贵的资源：团队成员的智慧
- 全局优化
- 在优化过程时应该总是试图包含尽可能多的价值流
移过等过库运缺
消内创推快对全
精益实践
MVP（最小可用产品）& MVF（最小可用特性）
- 使用最小的资源，实现一个体现核心价值或创新点的产品
- 用户只能通过实际使用中验证
- 核心是通过快速迭代来测试商业模式并获取用户反馈
产品功能特性探索与验证
- 实现产品特性快速验证和完善
- 通过反馈调整产品
看板管理展现价值流
- 通过拉动式管理,消除瓶颈与等待,提升交
建立输入节奏，实现研发价值聚焦
敏捷与精益的区别
敏捷：尽快交付可用的产品，与客户写作，及时获得反馈
精益：开发最小可用产品，基于看板梳理价值流，消除价值流中的浪费
敏捷的角度窄
精益的角度宽：关注整个业务环境
微服务
松耦合+可并行开发、部署、运行的小产品
关键实践
- 运作模式从“集团军作战”——>“班长的战争”
- 去中心化的服务化架构(云系统)和嵌入式系统的组件化架构
- 采用微服务架构,服务间全解耦,10000+服务,数万人的并行开发
DevOps理念
华为敏捷项目管理实践
从重型IPD转向“敏捷+精益+微服务+DevOps”轻量级敏捷开发模式
华为敏捷是端到端敏捷
- 不只是开发阶段敏捷
- 而是从市场,到开发、运维、运营的端到端敏捷
端到端敏捷实施依赖于全自动化的DevOps持续交付流水线
华为敏捷项目管理流程
- 准备阶段
- 组建全功能团队，实现快速自我决策
- 选择DevOps敏捷项目管理平台
- 计划阶段
- 发布计划&迭代计划来消除浪费
- 确立迭代周期，形成交付节奏
- 开发阶段
- 召开迭代计划会议，全员需求串讲
- 架构解耦，最小可运行产品
- 每日站会，通过看板梳理并消除堆积
- 持续开展自动化代码检查，提前构筑质量，避免后续修复
- 通过自动化流水线实现持续交付，显著提升交付效率和质量
- 以用户故事为主线的 需求-设计-代码-用例-缺陷 双向追溯系统，实现需求的可视化跟踪
- 反馈阶段
- 开展ShowCase会议，现场验收和反馈
- 通过燃尽图、统计报表跟踪项目进展
- 开展全员质量回溯会议
考题
- 需求列表的优先级
- PD（产品经理）建立并维护Backlog并进行优先级排序（1）
- 在每轮迭代前，回顾需求列表，并选出高优先级需求进入本轮迭代Backlog
- 每次迭代1-4周（1）
- 迭代回顾会议
- 是促进团队持续改进的最有效手段（1）
- 每轮迭代结束后举行的会议，team全员参加
- 精益的七大原则（简化代码）
- 消除浪费
- 内建质量
- 创建知识
- 推迟决策
- 快速交付
- 对人尊重
- 整体优化
- MVP
- 最小可用产品
- 属于精益
- 通过MVP快速获得客户反馈，并不断改进产品
- 是一个刚刚能够体现创新点或核心价值的产品
- 客户需求只有在实际使用中才能得到验证
- 核心是通过快速原型迭代来测试商业模式并获取用户反馈
- 版本交付（更替）不会减少测试（1）
- 浪费
- 部分完成的工作
- 没有落地的工作
- 未应用的特性
- 过度作业
- 传递
- 任务切换
- 一个team有各种各样人
- 减少任务切换的浪费
- 激励方法
- 站立会议
- 看板管理
- 结对编程
- 迭代验收
- 迭代回顾会议
- 用户故事
- 持续集成
拥抱变化：产品Backlog；迭代Backlog
团队实践：团队成员；Backlog
管理实践：站立会议，迭代回顾会议；迭代验收会议；迭代回顾会议；看板管理；PSP；可视化
技术实践：TDD，CI，结对编程，用户story；系统解剖
敏捷
拥抱变化
用户参加
消除浪费
1、为了管理好敏捷开发有哪些有效的实践手段
- 每日站立会议
- 迭代回顾会议
- 看板管理
- 产品backlog&迭代backlog
- 迭代验收会议
- 可视化管理
2、 迭代有哪些主要的过程和动作
3、敏捷和精益的不同点
- 敏捷：尽快交付可用的产品，与客户协作，及时获得反馈（反馈）
- 精益：开发最小可用产品，基于看板梳理价值流，消除价值流中的浪费（消除浪费）
- 敏捷的角度窄
- 精益的角度宽：关注整个业务环境
4、SOA和微服务的关系
5、要按照服务功能组合（）和（）团队，而不是像传统的方法进行分层
6、以下哪些是微服务的关键实践
7、敏捷理念提及的技术债务有哪些
- 日趋不稳定的架构
- 圈复杂度高的代码
- 低的测试自动化率
- 不及时清楚的静态检查警告
8、在敏捷工程实践中，以下哪个不是测试驱动开发的关键要点
- 代码要简洁，可读性好
- 测试用例的设计要保证完备，覆盖被测试单元的所有功能
- 每个测试用例尽量保持独立，减少依赖，提高用例的可维护性
- 当功能单元较大时，为维护难度，可分解为多个更小的功能单元，并逐一用TDD实现
9、敏捷开发中的迭代有哪些主要过程和动作
10、对于敏捷开发团队来说，沟通效率是非常重要的以下哪些是高效的
11、以下哪个是对DevOps不正确的描述
12、在软件开发实践中，以下哪个不属于常见的技术债务
13、软件行业中的库存问题