精益-敏捷软件开发方法

消除浪费
推迟决策
创建知识
快速交付 品质为先 全局优化
精益宣言
快速—灵活—机动
开发过程是一条繁忙的生产流水线，凡是慢下来 的流水线都会导致浪费。 通过消除软件中的延误、错误、误解和等待资源 等障碍，来改进过程。
超 越 SCRUM
SCRUM框架
讨论
关于SCRUM的
认识？
对SCRUM的认识观点
敏捷项目开展首次工作时没有做计划。 SCRUM中没有文档。 SCRUM中没有架构。
看板的真正价值
要求团队创建一个定义明确的规则和 有限制的工作流程
几种敏捷方法的对比
要素 保持团队成员原封不动 使用时间盒 为整个团队排列需求的优先级 发布已完成工作的时间 要求 是 是 选定迭代的末尾 SCRUM -是 是 选定迭代的末尾 否 使用快速-灵活-机 动的原则去构建优 化的工作流 是 利用工作流程提升 代码质量 SCRUM# 看板 -否 否 任何时候均可，取 决于团队的判断 是 以适当的在制品限 制去管理 部分支持 利用工作流程提升 代码质量 ----是 使用快速-灵活-机 动的原则去构建优 化的工作流 是 利用工作流程提升 代码质量 精益思想
• 促进敏捷实践的持续改进
目 录
精益简介 超越SCRUM 精益-敏捷中的管理
精 益 简 介
精益思想的基本原则
多数错误源于系统本身，因此必须对开发的系 统加以改进
为了改进系统，必须尊重员工
过早开始会造成浪费。只在需要的时候完成需 要做的事情，这就是JIT（just in time）
精益软件开发--为软件提供的原则 尊重人
王凌宇
SCRUM#
注入了精益思想的SCRUM
--艾伦.沙洛维
SCRUM#的4个基本实践
实践 描述
所有需要的成员汇集在一起，在同一时间工作在同一需求上， 及时构建，使用集群 最大可能缩短完成该素材的总体时间。精益方法重视项目总体 周期时间而非个人生产力。 增强了客户、分析人员、测试人员之间的交流，有助于测试人 员与开发人员保持同步。如果开发人员不能在测试人员制定测 定义验收测试优先于编写代码 试方法之前编写代码，那么就需要开发人员在后期帮助测试人 员，防止测试过程落后于进度 迭代结束时，所有已经启动的故事点都要完成 避免启动新的需求开发。 激发了团队成员去思考关于他们正在做的问题，并且有助于他 询问好的、可靠的问题 们学会识别正在做的工作与期望完成的任务之间的差别
团队真正需要的是，能够以很短的时间组织起所需要的技能 去完成工作，可共享的知识越多越好。 更好的模型是PDCA模型。
对SCRUM的局限性讨论
自组织团队能够超越其他团队改进软件开发的流程。 每次迭代都需要向客户提供价值。 切勿超越目前的迭代计划。 可以使用SCRUM-OF-SCRUMS协调不同产品团队间
看板与常用的敏捷方法的不同
软件开发团队中排队的队列很少。 软件开发团队的重点是尽快完成功能开发，但没有时间盒 制约。
从形成概念到产出消费品，在整个价值流的过程中，看板让人一目了然， 理想的情况是，由客户启动价值流，产品经理与团队紧密合作，利用看板 在过程中对在制品的数量加以限制。
直接运用看板，无需加以任何估算。
看板软件工程
根植于精益思想的软件开发方法
看板模型的概念基础
团队工作在适当数量的功能上直至完成开发。 对功能的选择和开发的过程进行妥善管理。
团队重视开发尽可能少的且可增强客户价值的功能。 开发流水线上存在少量排队队列和小批量的任务，这样会使开发工作更 有效。 团队须获得快速反馈以保证他们在正确的工作轨道上。
团队应该由通才组成。
检查和修改是足够的。
Hale Waihona Puke Baidu
讨论参考
导致系统障碍的因素被消除。其他方法也可以实现。 管理层不是障碍而是资源，是项目改进过程中的合作伙伴。
产品负责人应该只是项目任务优先次序的责任人，而优质产品的开发是由 整个团队负责。精益用“产品牵头人”代替“产品负责人。”产品牵头人 和团队共同为产品的质量负责。
精益-敏捷 的应用
研发部 王凌宇
适应人群
• 软件研发项目的项目经理，需求分析师，
开发工程师，测试工程师等
• 软件研发项目的相关干系人
• 企业中层管理者
假设与约束
• 对敏捷有一定的了解，有一定的敏捷
SCRUM实践经验
• 对软件工程有一定了解
• 对项目管理有初步了解
课程期望
• 了解精益的相关知识 • 了解SCRUM#的相关定义 • 了解敏捷实践中管理层的作用
精益-敏捷的转型战略
是一个自上而下的领导过程和自下而上的实施过 程
多个SCRUM团队的协作场景
整个团队的进度 需要多个团队来实现需求 团队之间的技术依赖 多个团队使用通用组件 需要一个团队修改代码去协助另一团队的工作 团队间代码共享
一个团队拥有另一个团队所需的知识
产品协调小组
敏捷开发 Quick Start
项目立项
WHY
团队环境
WHERE WHO
项目团队
WHAT
Quick Start
HOW
WHEN
要做哪些事？
多久能做完？
怎么做？
对SCRUM的观念认识
SCRUM的成功在很大程度上是因为由项目成员来定义 如何做项目。 团队要远离管理层。 产品是由产品开发人员靠拍脑袋想出来的。
精益敏捷管理方法
对实现目标的方法和工作授权，但仍需团队成员对结果负责。 运用多种方法和工具将团队面临的挑战可视化。 在组织内部构建知识，通过交叉培训项目成员来节约项目时间。
找到问题的根本原因，以确保工具能够增加价值。
精益敏捷的可视化控件
产品愿景 产品需求列表/发布计划/精益组合管理 迭代列表—单一团队、多个团队 故事点的单迭代燃烧图 故事点的多迭代燃烧图
的工作关系。
可以在无须自动验收测试或单元测试前置的前提下使
用SCRUM。
讨论参考
SCRUM团队应该被自组织，而不应该自我导向。 迭代并不需要总是为客户利益服务。不要构建过度需求， 要保持全局观。 只关注当前的需要，不同开发速度的团队之间相互依存，需要做 出计划，以确保团队工作能够得到很好地协调。 如果团队具有不同的目标、动机或驱动指标，那么就不会起 作用。 杰夫.萨瑟兰在创建SCRUM时，包括这两项实践，为了使人容易 掌握，被删除了。
站在更高的角度—“全局优化” 来自不同团队中的成员组成 为了共同的目标
产品协调小组成员构成
固定成员
轮值成员
计划成员
精益敏捷的深刻见解
一次只关注一个项目 启动较少的项目 缩短批处理时间 探寻缺陷产生的根本原因 知道你在哪里：最小化可发布的功能
优先事项和工作进程 生产力及质量
跨职能团队
谢
谢！
研发部
需要在一个管理层支持的背景下工 否 作 团队成员在同一地点办公 支持产品管理组织 代码质量 没有说明 否 没有讨论
精益-敏捷中的管理
彼得.德鲁克
管理是把事情做对；而领导是做对的事情
W.爱德华兹.戴明
你必须管理系统，因为系统本身不能对自己进行 管理
精益-敏捷管理
重视价值流的管理和对人员的领导
职责：设定结果或团队预计要达成的目标。 协助工作人员改进过程并安排工作区，以方便团队完成工作。 管理者最重要的任务就是帮助团队避免浪费。
SCRUM与精益的观点比较
主题 迭代结构 SCRUM观点 使用时间盒迭代，发现和构建相关的小型迭代 精益观点
利用迭代结构类型 团队向产品负责，产品牵头人设置优先次序，并 产品方向 产品负责人全权负责 与团队一起去发现和构建需求 管理 倾向于将团队与管理层隔离开来 管理者引领和教导团队，管理层与团队协同合作 让团队工作，通过SCRUM-OF-SCRUMS协调团 创建适合所有工作的环境，如价值流。团队要学 如何组织 队工作 会如何在这些环境下工作。 如何学习 检查工作结果，接着去适应改善的环境 应用PDCA原理 重视客户和企业的价值，同时关注延误带来的成 需求的优先级 重视客户价值 本 在团队具备了解决问题的能力后，再将工作任务 开始的地方 让团队自己去解决自己的事务 交给团队处理，重要的是对我们所做的工作尽可 能地了解。