《敏捷开发介绍精编版》由会员分享，可在线阅读，更多相关《敏捷开发介绍精编版（81页珍藏版）》请在金锄头文库上搜索。
1、PSST质量与成本管理部 系统工程部 华为敏捷软件开发解读 2009年06月N 001 Page2 关于管理者和软件开发相关人员掌握敏捷知识的要求为落实敏捷软件开发在我司的顺利推行 使广大软件开发管理者和开发人员深刻领会敏捷核心理念 熟练掌握敏捷实践方法 从而达到增强应对需求变化的能力 提高产品质量 提升开发效率和缩短交付周期等方面的目标 为此 特提出如下要求 PM及以上管理者要深刻领会敏捷核心理念 理解我司敏捷推行策略 了解各种敏捷实践 软件开发相关人员 含PL 软件开发人员 软件测试人员 软件架构人员 系统分析人员 与软件相关的资料人员和研发质量人员 要深刻理解敏捷理念 掌握敏捷实践 了解
2、我司敏捷推行策略 通过敏捷相关知识的考试是软件开发相关人员任职资格的基本要求 考试试题分为管理者版本和员工版本 分别针对管理者和员工应知应会的知识进行考试 敏捷学习参考材料包括 华为敏捷开发解读 及相关附件 目录 敏捷概述正确理解敏捷我司敏捷开发实施策略我司敏捷案例 Page4 业界敏捷浪潮 ISO9000 09版 标准将在原来八大原则的基础上新增敏捷原则2000年美国军方软件开发标准 DOD5000 2 推荐迭代为软件开发优选模式世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一 Page5 软件作坊 软件过程控制 重型过程 2001 今敏捷正在流行 软件规模小 以作坊式开发
3、为主 硬件飞速发展 软件规模和复杂度激增 引发软件危机 引入成熟生产制造管理方法 以 过程为中心 分阶段来控制软件开发 瀑布模型 一定程度上缓解了软件危机 软件失败的经验促使过程被不断增加约束和限制 软件开发过程日益 重型化 开发效率降低 响应速度变慢 随着信息时代到来 需求变化更快 交付周期成为企业核心竞争力 轻量级的 更能适应变化的敏捷软件开发方法被普遍认可并迅速流行 软件危机 20世纪60年代 80年代 90年代 软件开发顺应时代变化 从重型过程转向轻量型敏捷 70年代 敏捷诞生的历史背景 Page6 敏捷宣言揭示更好的软件开发方法 敏捷宣言 2001年 是敏捷起源的基础 由上述4个简单
4、的价值观组成 敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式 启迪人们重新思考软件开发中的价值和如何更好的工作 敏捷宣言 Page7 软件更像一个活着的植物 软件开发是自底向上逐步有序的生长过程 类似于植物自然生长敏捷开发遵循软件客观规律 不断的进行迭代增量开发 最终交付符合客户价值的产品 传统开发 敏捷开发 敏捷更符合软件开发规律 Page8 敏捷对生产率 质量 满意度 成本有明显改进 82 的项目生产率有提高 78 的项目质量有提高 78 的项目客户满意度有提高 37 的项目成本有降低 以上数据来自DDJ2008由ScottAmbler发起的网上调查结果 目录 敏捷概
5、述正确理解敏捷统一敏捷认识敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例 Page10 对敏捷的常见误解 误解一 敏捷开发意味着可以不需要文档 设计和计划误解二 敏捷只是一些优秀实践 或者是优秀实践的结合误解三 敏捷只适用于小项目开发误解四 敏捷只会对研发产生改变误解五 管理者不需要亲自了解敏捷 只需要管理上支持就可以了误解六 引入敏捷只需要按照既定的步骤去做就可以了误解七 敏捷是CMM的替代品 是另一种流程误解八 敏捷只注重特性的快速交付 在敏捷下架构不重要了 Page11 统一认识 敏捷 理念 优秀实践 具体应用 理念 优秀实践 具体应用 理念 敏捷核心思想 敏捷包括3个层次优秀
6、实践 敏捷的经验积累 具体应用 能够结合自身灵活应用才是真正敏捷 Page12 理念 聚焦客户价值 Value 消除浪费 软件业 45 的软件特性客户没有使用 Source StandishGroup来自5万个软件开发项目的调查 Source 中国电信总工韦乐平在 华为公司工程与技术大会 上的讲话 Source 如何提升软件开发效率 08年统计 电信业 电信级 带来的浪费 价值 在 敏捷宣言 中的体现 产品商业成功为目标 聚焦客户价值 围绕价值流消除浪费 我司 研发版本废弃特性 07 1 08 6年某产品线所有产品中重要特性无应用的比例达22 需求变更和分析不足占63 Page13 理念 激发
7、团队 Team 潜能 加强协作 我司试点开发测试拉通 效率质量改善明显 团队是价值的真正创造者 应加强团队协作 激发团队潜能软件开发是一种团队活动 首先应做到提升沟通效率降低交流成本 Source 08年测试行业超过30个项目试点 Source 经济学家2003 DeMarco研究报告 团队 在 敏捷宣言 中的体现 研究表明面对面的沟通最有效业界调查 一个50人开发团队 每人平均30 时间用于编码 70 的时间用于与其他成员交流 研究表明1981年来自不同公司的优秀程序员生产率之比是7 1 而2007年最新的研究数据 则是40 1 人是软件开发的决定因素 Page14 理念 不断调整以适应 A
8、dapting 变化 麦当劳是简单可预测生产过程 人月神话 软件开发是人类最复杂工作之一 软件具有四个属性 复杂性 一致性 可变性和不可见性 软件开发是不可重复 探索性的 演进的 适应性过程 随软件规模增长 需求变化呈非线性增长 软件开发是复杂不可预测的经验控制过程 适应变化 在 敏捷宣言 中的体现 不断的根据经验调整 最终交付达到业务目标的产品 软件开发规律再审视 Page15 优秀实践 业界敏捷优秀实践概览 结对编程 测试驱动开发 客户参与验收 计划游戏 代码集体所有 每日站立会议 产品backlog 带优先级的需求清单 燃烧图 迭代计划会议 回顾会议 ScrumMaster Produc
9、tOwner Anatomy 系统解剖 OneTrack Systemakut 缺陷管理和决策 重构 完整团队 稳定开发节奏 Lagomising 需求决策 隐喻 电信业偏重大规模产品实践 Scrum偏重项目管理 XP偏重编程实践 电信业 Scrum XP 持续集成 迭代交付 Page16 开发团队一 具体应用 因地制宜选择适合的敏捷实践 团队在透彻理解敏捷理念的基础上 可以灵活选择最适合自己的实践 避免教条化 站立会议 排序的工作列表 持续集成 持续集成 重构 持续集成 结对编程 迭代开发 迭代开发 开发团队三 敏捷理念 开发团队二 敏捷理念 敏捷理念 Page17 敏捷转型是系统性工程 敏
10、捷转型7个方面优先级 Source CutterAgileTransformation JimHighsmith大师 敏捷转型是系统工程 覆盖7个方面 实践 绩效考核 组织 过程 文化 管控 技术和业务对齐敏捷在敏捷转型不同阶段 敏捷转型框架的7个方面引入的优先级不一样 初期以实践为主 Numbersrepresenttypicalrelativeimportanceateachstage 目录 敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例 Page19 深入理解敏捷理念 深入理解 适应变化 认请 客户是逐步发现真正需求 小批量是快速交付的关键通过迭
11、代计划不断调整以适应需求变化应持续保持良好的软件架构利用多层次反馈不断调整以逼近目标 深入理解 激发团队 认清团队的基本事实敏捷方式下管理者的转变敏捷方式下团队成员的转变 深入理解 聚焦客户价值 标识和消除软件开发中的浪费交付刚刚好的系统随时构建质量 不容忍缺陷及时消除技术债务 持续保持快速响应 Page20 聚焦客户价值 标识和消除软件开发中的浪费 Source 精益软件开发 Page21 当质量 进度 资源冲突时 能改变的只有项目范围 即选择 交付刚刚好的系统 产品交付前 客户往往期望多而全的功能 产品交付后 客户把稳定的质量放在首位 尤其在电信领域 客户对产品质量要求是Alwayswor
12、k 不是Sometimes 与其为了满足多而全的功能导致交付延迟 质量不稳定 不如按时交付刚刚好的系统 保证其高质量运行 交付刚刚好的系统 基于对客户需求的深入理解 并花时间了解细节 简化 simplify 需求 降低复杂性 而不是简单地拒绝需求 delete 做到 交付刚刚好的系统 同时需要管理者有足够的勇气和果断决策 聚焦客户价值 交付刚刚好的系统 在项目明显超负荷时 管理者简单地期望靠团队workharder来解决 最终导致 质量下降项目延期客户不满意团队疲劳埋下长期隐患 Page22 缺陷遗留带来高额成本 对单独质量保证活动 如后端测试 的依赖 容易形成缺陷可以遗留到下个阶段的心理 导
13、致缺陷发现成本升高 系统测试阶段缺陷定位和解决成本是开发阶段的10倍 例1 E公司开发阶段和测试阶段发现缺陷的比例为7 3 而我司大量缺陷集中在后端发现 带来高额成本 例2 我司顾问指出 华为测试和开发 相隔1000英里 聚焦客户价值 随时构建质量 不容忍缺陷 从项目一开始就随时构建质量 形成零缺陷文化 不要容忍缺陷 发现缺陷应立即停下来解决 以保证在坚实的质量基础上前行 开发和测试紧密协作 测试人员参与到设计和开发过程中 共同预防缺陷的产生 例如 持续集成暴露的问题需立即解决 Page23 聚焦客户价值 及时消除技术债务 持续保持快速响应 为什么会有技术债务 为满足短期商业目标 不影响其外部
14、表现的情况下 会在技术方面进行一定的让步 这种让步虽对当前版本的质量影响甚微 但会严重影响后续版本响应客户需求的能力 从而形成技术债务 对待技术债务的态度 技术债务是有成本的 如不及时偿还 会随时间积累利息变高 导致开发效率大幅下降 从而降低客户响应能力 因此对待技术债务的态度是加以管理并及时偿还 如及时重构 常见技术债务 日益腐烂的架构 圈复杂度高的代码 低的测试自动化率 不及时清除的静态检查告警等 Page24 激发团队 认清团队的基本事实 Source JeffCSMTrainingmaterial 信任是高绩效团队的基石 信任 承诺 冲突 创新 关于团队激励 当团队自管理时效率最高人们
15、对自己做出的承诺比别人要求的承诺更认真人们会尽力做到最好在强大的压力下努力工作 人们会自然而然地降低对质量的要求关于团队绩效 当团队成员不被打扰时 工作效率最高当团队解决自我问题时 提升最快广泛的 面对面的交流是团队工作最高效的方式关于团队构建 团队生产率大于相同数目的个体生产率之和当不同技能领域的人员组成团队并聚焦于工作时 产品更健壮 Page25 激发团队 敏捷方式下管理者的转变 管理者努力 控制 团队 制定详细的工作计划 并做出详细的工作安排指令性工作方式监控过程基于复杂规则的管理 管理者努力 激发 团队 通过目标来牵引团队自主工作帮助团队提供资源 排除障碍营造团队自我管理的工作氛围作为
16、教练辅导团队进步基于简单原则的管理 原则简单但必须被遵守 敏捷方式下对管理者最大的挑战是学会放松 控制 loosecontrol 传统方式 敏捷方式 Page26 激发团队 敏捷方式下团队成员的转变 团队成员是 听从安排的独立贡献者 被动等待主管下指令安排工作独立工作为主 协作少以文档和邮件为主要沟通方式只关注个体任务 做完 不关注团队目标能力相对单一 学习动力不足 敏捷方式的管理者 从被动到主动的心态转变是团队成员适应敏捷开发的关键 团队成员是 全方位的积极参与者 共同参与计划制定和任务安排团队协作贯穿工作始终面对面交流是主要沟通方式关注团队目标 共担责任能力要求更广 主动学习适应岗位要求 传统方式 敏捷方式 Page27 残酷现实客户是逐步发现他真正要的东西开发人员逐步发现如何开发产品满足客户需求在这个过程中随时可能发生变化 美好愿望客户知道自己要的是什么开发人员知道如何开发来满足客户需求在开发过程中需求不会发生变化 期望客户一开始就想清楚他们真正要的东西是不现实的 我们应当通过不断的向客户交付可用的产品 启发客户逐步的发现真正的需求 我们认识到 适应变化 认清 客户是逐步发现真正
