首页  思维导图  详情

敏捷软件开发

2022-07-03 12:41:43   3  举报





AI智能生成

敏捷软件开发，你需要了解这些

敏捷开发

项目管理

看板

用户故事

Scrum

作者其他创作

大纲/内容

第一部分 敏捷简介

什么是敏捷（What），敏捷软件开发是什么？

瀑布VS敏捷 

传统的瀑布开发模型

1、传统的瀑布开发模型 把软件开发过程明确的定义为需求、设计、实现、测试等阶段，每一阶段都需要上一阶段的交付物作为输入开展工作，非常重视文档和流程。

敏捷模型

时代变了，软件开发从重型过程转向轻量型敏捷

2、随着信息时代发展，软件需求越来越呈现出快速且多变化的特点，需求变化更快，交付周期成为企业核心竞争力，在这种背景下，轻量级的，更能适应变化的敏捷软件开发(Agile Development)方法被普遍认可。

3、敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。更强调人与人之间的交互、产品价值的交付以及快速响应客户的需求变化。

敏捷的起源

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地（Snowbird），十七位软件开发领域的软件顾问和思想的领导人聚到一起，他们聚集起来定义敏捷的软件开发过程（当然还有滑雪、休闲和聚餐）。  最终在 Agile Manifesto 大会上达成共识。最终的成果就是全体参会者签署的《敏捷软件开发宣言》（Manifesto for Agile Software Development）。

问题：下面这些人，你们认识谁？他干了什么 Dave Thomas：Ruby之父，ruby来自日本，但他写的《programming ruby》影响力非常大。 Jim Highsmith：自适应（Adaptive）软件开发方法的创始人，《敏捷宣言》的创始人，敏捷联盟的创始成员。曾获得2005年Steven奖。所著《Adaptive James James Grenning：Software Development: A Collaborative Approach to Managing Complex Systems》一书曾经获得“软件奥斯卡”之称的Jolt大奖。加入ThoughtWorks之前，他是The Cutter Consortium的敏捷项目管理负责人。 kent beck：软件开发方法学的泰山北斗，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是JUnit的作者，对当今世界的软件开发影响深远。 Martin Fowler：国际著名的面向对象分析设计、UML、模式等方面的专家，敏捷开发方法的创始人之一。《分析模式》、《UML精粹》和《重构》

做了敏捷之后

做了敏捷，我们会在墙上看到各种卡、图、表

子主题

做了敏捷，可能会改造办公环境，并会开各种各样的会

子主题

做了敏捷，我们还会要做……

子主题

因为敏捷软件开发强调价值交付、团队能力提升

更稳定的产品交付 有战斗力的、能力全面的开发团队

问题：

1、敏捷软件开发是什么？ 2、你期待敏捷软件开发给你带来什么好处？

敏捷是什么？有什么好处？

为什么需要做敏捷软件开发？（Why）

信息化时代的进步，核心竞争力的转变 敏捷更符合软件开发规律

信息化时代发展的步伐

20世纪60年代：软件规模小，以作坊式开发为主 70年代：硬件飞速发展，软件规模和复杂度激增，引发软件危机 80年代：引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机 90年代：软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢 2001~至今：随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。 时代在进步，需求产品在不断的升级变更，快节奏的当下，唯有改变软件理念才能更好的保持竞争力。

图解传统开发与敏捷开发

子主题

敏捷价值（How much）

敏捷是一套价值观(values)和原则(principles)

敏捷宣言——揭示更好的软件开发方法

敏捷价值观 / 敏捷宣言

敏捷宣言（敏捷价值观）

2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场，共同探索有关软件开发未来发展的共同理念。 这些人中， 有极限编程的倡导者肯特·贝克（Kent Beck） 有重构大师马丁·福勒（Martin Fowler） 有“维基之父”沃德·坎宁安（Ward Cunningham）， 还有实用编程、特性驱动开发、自适应软件开发等各个流派的代表。 经过两天的讨论，“敏捷”（Agile）这个词为全体与会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。敏捷宣言由价值观和原则组成

敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作

敏捷真正价值是什么?如果你在做一件创新的事情，只有敏捷能帮你把这件事情做好，为什么?因为你需求是无限的。传统软件开发流程跟传统工业流程是一样，初始条件，一连串线性流程，明确目标。实际上是已验证的需求，瀑布流，清晰、准确可预估，你们目标提出来模式是按这个模式来提的，这些时间这些人肯定能做到。

避免浪费，走向精益

子主题

聚焦客户价值，标识和消除软件开发中的浪费

子主题

如何敏捷（How so）

理念

理念一：价值（Value）

理念 1、聚焦客户价值（value），消除浪费 2、激发团队（Team）潜能，加强协作 3、不断调整以适应（Adapting）变化

价值团队调整

“价值”在“敏捷宣言”中的体现

敏捷宣言中的2和3

软件业：45%的软件特性客户没有使用

研发中最大的浪费

Source：《如何提升软件开发效率》统计

围绕价值流消除浪费：产品开发中消除不增值的活动、消除和减少不必要的等待（排队）

产品开发的目标是产品商业成功，聚焦客户价值、围绕价值流消除浪费

聚焦客户价值，标识和消除软件开发中的浪费

子主题

<table border="0" cellpadding="0" cellspacing="0" width="809" style="border-collapse: collapse;width:607pt;mso-yfti-tbllook:1056"> <colgroup><col width="171" style="mso-width-source:userset;width:128pt"></colgroup> <colgroup><col width="638" style="mso-width-source:userset;width:479pt"></colgroup> <tbody><tr height="36" style="mso-height-source:userset;height:27.0pt"> <td height="36" class="oa1" width="171" style="height:27.0pt;width:128pt"> margin-left:0in;margin-right:0in;text-indent:0in;text-align:center; direction:ltr;unicode-bidi:embed;vertical-align:baseline;mso-line-break-override: none;word-break:normal;punctuation-wrap:hanging">浪费类别 </td> <td class="oa1" width="638" style="width:479pt"> margin-left:0in;margin-right:0in;text-indent:0in;text-align:center; direction:ltr;unicode-bidi:embed;vertical-align:baseline;mso-line-break-override: none;word-break:normal;punctuation-wrap:hanging">浪费举例 </td> </tr> <tr height="36" style="mso-height-source:userset;height:27.0pt"> <td height="36" class="oa2" width="171" style="height:27.0pt;width:128pt"> 缺陷 </td> <td class="oa2" width="638" style="width:479pt"> 解决缺陷活动本身就是浪费，而且缺陷越遗留到后端浪费越大。 </td> </tr> <tr height="65" style="mso-height-source:userset;height:48.6pt"> <td height="65" class="oa3" width="171" style="height:48.6pt;width:128pt"> 未应用特性 </td> <td class="oa3" width="638" style="width:479pt"> 开发完成但没有被客户应用的特性（交换机2000多个功能客户只用了1%）。 </td> </tr> <tr height="65" style="mso-height-source:userset;height:48.6pt"> <td height="65" class="oa4" width="171" style="height:48.6pt;width:128pt"> 任务切换 </td> <td class="oa4" width="638" style="width:479pt"> 研究表明多任务工作会导致效率下降20%-40%（员工多头工作或杂事繁多）。 </td> </tr> <tr height="65" style="mso-height-source:userset;height:48.6pt"> <td height="65" class="oa3" width="171" style="height:48.6pt;width:128pt"> 部分完成的工作 </td> <td class="oa3" width="638" style="width:479pt"> 部分完成但没有最终落地的工作（没有转化成代码的设计文档；未及时合入的代码导致引发后续更多同步工作量）。 </td> </tr> <tr height="94" style="mso-height-source:userset;height:70.2pt"> <td height="94" class="oa4" width="171" style="height:70.2pt;width:128pt"> 移交 </td> <td class="oa4" width="638" style="width:479pt"> 知识信息的传递总是伴随信息丢失，隐形知识尤其困难，分工过细往往导致过多不必要的移交（如详细设计和实现分离，造成大量设计信息丢失）。 </td> </tr> <tr height="65" style="mso-height-source:userset;height:48.6pt"> <td height="65" class="oa3" width="171" style="height:48.6pt;width:128pt"> 延迟 </td> <td class="oa3" width="638" style="width:479pt"> 因任务或资源相互依赖而导致工作停滞（集成时被关键模块阻塞，等待测试环境就绪）。 </td> </tr></tbody></table>

理念二：团队(Team) 

“团队”在“敏捷宣言”中的体现

敏捷宣言中的1

研究表明面对面的沟通最有效  业界调查：一个50人开发团队，每人平均30%时间用于编码，70%的时间用于与其他成员交流。

人是软件开发的决定因素

研究表明：1981年来自不同公司的优秀程序员生产率之比是7:1，而2007年最新的研究数据，则是40:1。

团队是价值的真正创造者，应加强团队协作、激发团队潜能 软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本

理念三：适应变化（Adapting）  

“适应变化”在“敏捷宣言”中的体现

敏捷宣言中的4

随软件规模增长，需求变化呈非线性增长

子主题

软件开发规律再审视

《人月神话》：软件开发是人类最复杂工作之一，软件具有四个属性：复杂性、一致性、可变性和不可见性 软件开发是不可重复、探索性的、演进的，适应性过程

软件开发是复杂、不可预测的经验控制过程

子主题

不断的根据经验调整，最终交付达到业务目标的产品

优秀实践

优秀实践 站立会议，持续集成，重构，结对编程，迭代...... 电信业偏重大规模产品实践、Scrum偏重项目管理，XP偏重编程实践

子主题

敏捷实践的经验积累

具体应用

团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化

子主题

能够结合自身灵活应用才是真正的敏捷

敏捷开发的12条原则

最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 欢迎需求变化,甚至在开发后期。敏捷过程控制、利用变化 帮助客户取得竞争优势。 频繁交付可用的软件,间隔从两周到两个月,偏爱更短的时 间尺度。 在整个项目中业务人员和开发人员必须每天在一起工作。 以积极主动的员工为核心建立项目,给予他们所需的环境和支持,信任他们能够完成工作。 在开发团队内外传递信息最有效率和效果的方法是面对面的 交流。 可用的软件是进展的主要度量指标。 敏捷过程提倡可持续发展。发起人、开发者和用户应始终保 持稳定的步调。 简化——使必要的工作最小化的艺术——是关键。 持续关注技术上的精益求精和良好的设计以增强敏捷性。 最好的架构、需求和设计产生于自我组织的团队。 团队定期地对运作如何更加有效进行反思,并相应地调整、 校正自己的行为。

1、对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要 2、欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势 3、经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好 4、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作 5、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务 6、在开发小组中最有效率也最有效果的信息传达方式是面对面交谈 7、可以工作的软件是进度的主要度量标准 8、敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏 9、对卓越技术与良好设计的不断追求将有助于提高敏捷性 10、简单 尽可能减少工作量的艺术至关重要 11、最好的架构、需求和设计都源自自我组织的团队 12、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为

敏捷带来什么好处？

根据业界统计的数据，普遍认为敏捷可以带来如下好处：  缩短产品交付的周期  提高适应需求变化的能力  提高产品质量  提升产品交付能力  提升团队能力  降低产品风险  降低产品成本  ……

第二部分  Scrum框架和核心要素   

说到敏捷，接触最多的词可能是Scrum。

Scrum是什么

Scrum [skrʌm] n. 〈橄榄球〉并列争球在扭夺的一堆人（亦作： scrummage）

一种敏捷管理方法

敏捷管理的方法有许多种，Scrum是其中一种敏捷管理方法。

业界采用的敏捷方法的概览，可以看出，采用Scrum的团队占绝对的多数。

视频：7分钟认识Scrum

https://www.bilibili.com/video/av96741164/

Scrum框架与概览图

子主题

SCRUM—框架—术语表

子主题

Sprint是什么

Sprint 这里面指的是一次迭代，希望在一个周期内以最快的速度做事。  Scrum项目周期以一组“Sprints”组成 典型的Sprint周期为1~4周  固定周期能够创造出项目更优美的节奏感  产品的设计，开发，测试全部都在一个Sprint内完成

Sprint--短距离赛跑

SCRUM—核心概念

按优先级排列的产品需求清单（Product Backlog） 跨职能自组织的小团队 以“sprint”为周期的迭代开发 持续调整版本发布计划 持续调整流程 不硬性规定任何具体的工程实践

不是由一个大团队用很长的时间来开发一个大产品 而是由一个小团队用很短的时间来开发一个小功能

Scrum实施的2个承诺

子主题

业务承诺在迭代中不插手任务的优先级

团队承诺无论遇到多少障碍，承诺的东西必须交付

SCRUM—核心要素

角色

Scrum PO（Product Owner） Scrum Master Scrum 团队

SCRUM—职能—猪和鸡的故事

子主题

“ 猪”角色 －全身投入项目和Scrum过程 产品所有者PO  ScrumMaster 团队

“鸡”角色 －不是Scrum过程的一部分，但必须考虑 客户 市场 高层 …

SCRUM —角色—团队

经典团队拥有 5-9 人 团队内部能力覆盖全面，最好都是多面手:--编程，测试，用户界面设计, 等等 团队成员都全职工作--特殊职能可以例外 (例如, 数据库管理员) 团队自我组织和管理 团队关系在一个Sprint中应该是固定的，个人的职能可以在新Sprint开始时发生调整

SCRUM—角色—PO（Product Owner）

定义所有产品功能(Product Backlog) 决定产品发布的内容以及日期 对产品的投入产出负责 根据市场变化对需要开发的功能排优先顺序 合理的调整产品功能进入迭代开发的顺序 认同或者拒绝Sprint的交付

产品负责人（PO）与Scrum Master的区别

子主题

SCRUM—角色—SM（Scrum Master）

对项目的直接指导 领导团队完成Scrum的实践以及体现其价值 排除团队遇到的困难  确保团队的胜任其工作，并保持高效的生产率 使得团队紧密合作，使得团队个人具有多方面职能的工作能力 保护团队不受到外来无端影响

Scrum Master

保护团队的牧羊犬

倡导敏捷和Scrum价值 维护Scrum过程&规则 保护团队避免外部干扰

辅导团队的教练

观察、检视、辅导、调整 提升团队的责任意识 帮助团队做持续改进

会议和决策的引导者

引导Scrum各种会议 引导对话、团队决策

团队障碍的移除者

发现问题、解决问题 影响组织、推动变革

回顾

PO的工作产品？ Scrum Master的工作产品？ Scrum团队的工作产品？

—— 交付有价值的产品 —— 建立高效能自组织的团队 —— 每个迭代的工作

活动、仪式

Scrum的活动

子主题

SCRUM—活动、仪式—Sprint计划会

Sprint计划会大致内容

子主题

目的

确定迭代/工作周期的目标 确定迭代/工作周期的工作列表 通过沟通让团队充分理解工作

要点

参加人员：需求方代表+所有团队成员 时间：每个“迭代”开始 输入：提前准备好优先级最高的、可能在该“迭代”完成的工作 流程： 需求澄清、目标澄清 生成迭代故事卡（也可以事先准备好） 讨论和估算工作量 完成本迭代的DoD

常犯错误

团队未全员参加 工作粒度过大或过小 讨论时间过长 超出团队速率安排工作 提前确定工作的责任人 每个人并非独立估算 估算苛求精确

用户故事卡

故事名称

作为<用户角色>  我想要<功能简述> 以便于<价值简述>

要点

用户故事的重要组成元素 仅起提示符作用，提醒团队和干系人进行给交谈 ¼A4大小的硬卡纸 主要信息都是由需求方编写 可用于故事墙和发布计划

常犯错误

卡片上文字、细节太多 为卡片进行无意义的编号 以为不能修改 以为什么都能以用户故事来描述（用户界面、接口定义）

图解用户故事卡

子主题

制定 完成定义DoD（Definition of Done）

DoD的定义：

在迭代结束时，团队确定本迭代的工作是否成功完成的检查项列表，团队共同执行。  在迭代评审会前，每个用户故事的Owner严格按照DoD检查和确认本迭代的用户故事是否完成。

DoD的收益：

1 共同协商的完成定义，是团队的自我承诺，团队会更认真； 2 用于准确评估团队的工作计划、质量和展示工作进展； 3 清晰和明确的完成定义保证了每次迭代是高质量的。

图解DoD

子主题

发布Sprint启动报告

Scrum Master在Sprint计划会后，完成一篇Sprint启动报告。

子主题

Sprint启动报告内容包含

这个Sprint的目标   Sprint要实施的故事   开始时间-结束时间   团队成员

**开发团队，Sprint 1 Sprint目标： 时间： Sprint 工作： 计划：  每日站会：9:00-9:15  评审会：9月5日 团队：

发送给Scrum团队及其他辅助角色，让大家知道，一个新的Sprint开始了

问题：  准备今天这堂课的所有材料，需要多少人/天？ 思考：  如果大家对故事点的工作量大小有不同怎么办？

Sprint开发过程中的敏捷实践

子主题

图解Sprint计划会

SCRUM—活动、仪式—每日Sprint站会

目的

分享进展 识别风险 必要时调整工作计划

要点

参加人员:团队所有成员 时间：每天 输入：看板上的任务和状态 流程： <ul><li>大家对着围着看板站成一圈</li><li>第一个人拿到“令牌”发言</li><li>讲“三件事情”</li><li>更新看板状态</li><li>把令牌给旁边的人，重复1-4</li></ul>

常犯错误

不按时开始 迟到 过多讨论 抢话/争吵 超过15分钟 向某人做汇报 漠不关心

图解站会

子主题

每日站会

子主题

站会三句话：

昨天干了什么   今天准备干什么   遇到什么问题（有什么风险）

从这里可以看出来，敏捷团队不能太大

SCRUM— 活动、仪式—Sprint评审会 （演示会）

目的

分享团队向“客户”展示本次迭代交付的需求并获取反馈。

要点

<ol><li>参加人员: 团队成员+客户代表+PO</li><li>时间：每个迭代最后一天</li><li>流程：</li></ol><ul><li>Owner或测试讲解需求</li><li>按照用户场景进行演示，至少覆盖所有用例</li><li>现场头脑风暴用例测试</li><li>确认通过或记录问题</li><li>确认所有接受的story列表和需求列表</li></ul>

常犯错误

客户代表没有参加 过多讨论细节 没有准备好 经常忘记举行 没有明确结论 团队人员缺席

会前准备

子主题

在Sprint结束前一天，Scrum Master写出Sprint评审议程表。包含：  <ol><li>  时间、地点  </li><li>  Sprint目标</li><li>  议程</li></ol><ul><li>所有要展示的项目</li><li>展示需要的时间</li><li>谁来展示</li></ul>

发送给Scrum团队及其他辅助角色。让大家知道一个Sprint结束了，并且请开发者准备第二天的展示数据。

图解评审会

子主题

SCRUM—活动、仪式——Sprint回顾会

目的

通过全员讨论的方式，总结经验教训，持续改进敏捷流程。

要点

<ul><li>参加人员：团队成员</li><li>时间：迭代结束时</li><li>流程：</li></ul><ol><li>回顾上次举措的进展</li><li>头脑风暴，收集建议</li><li>归纳及整理</li><li>投票选择下个周期要处理的N条建议</li><li>讨论建议，并确定改进举措</li></ol>

常犯错误

没有有效的问题 重复且无法解决的问题 改进举措太多 改进举措无法有效落地 团队人员缺席 不专注，玩手机

回顾会的步骤

营造氛围

信息汇集与回放

洞察问题

确定改进举措和责任人

结束回顾

图解回顾会

子主题

回顾会的方法（1）

事件时间：不同颜色的即时贴代表不同的感受或事件类型 心情曲线：每人画一条曲线，展现自己在迭代中的情绪变化 三个“Do”——开始做、继续做、停止做

子主题

Sprint回顾会（2）

回顾开发过程中的优点、缺点。  通过贴标签和投票方式，让开发团队每人参与意见。  时间有限，每次会议，集中依次讨论大家最关注的问题。  形成会议代办事项，并约定跟踪责任人。

子主题

Sprint 总结报告

评审会、回顾会完成以后，Scrum Master进行总结。

内容包括：

<ul><li>概述</li><li>Sprint时间段</li><li> 目标</li><li> 估计速度+实际速度（列出前几个Sprint情况）</li><li> 团队回顾会内容</li></ul><ol><li>优良事宜</li><li>待改进事宜</li></ol>

和品会服务器Sprint3总结报告

Sprint总结 和品会敢死队团队在12月11日完成了第3个sprint。完成了该sprint的目标： 1. 完成了权限控制和UI技术的预研， 2.完成了商品数据库表的分析和数据库迁移的方案， 3.完成了PMD/SOAR/FindBugs的CI集成， 4.完成了机构，地域管理管理的开发。整体的完成情况良好，比预估的故事点减少3个，主要是由于对任务估计没有计算数据库表的设计工作，以及为统计培训分享的工作量造成的。 Sprint 周期  2015年12月14日—2015年12月18日 Sprint 目标 完成权限控制、UI技术预研, 完成商品数据库表分析,完成机构、地域管理功能开发,完成自动化代码检查工具集成。 预估速度  32 故事点 实际速度  29故事点   Sprint 实际速度  （右图1） 团队回顾会议  团队在12月21日召开了迭代回顾会议，团队成员列出了继续保持的优良事项，以及未来有待改善的事项。最后团队成员制定出改善的计划和责任人。   与此同时，在这次会上也做了下个迭代的计划和任务分工。下个迭代将计划完成37个故事点，包括机大掌柜机构管理完善、角色管理开发、账号管理开发、人员管理开发等。 优良事项 1.  任务按照计划完成 2.  积极分享 3. 任务调整和划分合理   改善事项 1. 提升培训效率——ALL 2. 降低培训频次(大概每个迭代2~3次)——ALL 3. 开发任务隐含DB的设计——WHM 4. 进一步优化和明确验收条件——PO 5. 输出编程规范（数据库/UI/JAVA/框架）——WHM/ZXL/DK/SJP 优秀成员 周小丽 回顾会照片（右图2）

子主题

产出

Product Backlog Sprint Backlog 看板+燃尽图

Product Backlog/Sprint Backlog

DoD的定义：

产品预期交付物（PBI）的累积清单，包括特性 、工程故障、技术积累、外场测试等任何值得创建的东西。 由产品负责人(PO)维护。 根据优先级按顺序保存。

DoD的收益：

透明化项目信息 通过需求的动态管理应对变化，避免浪费 易于优先交付对用户价值高的需求

系统截图

子主题

内容1：迭代记录

子主题

内容2：backlog

子主题

Backlog

产品预期交付物（PBI）的累积清单，包括特性 、工程故障、技术积累、外场测试等任何值得创建的东西 除了描述外，需要包括：重要性、预估时间 Product Backlog与Sprint Backlog

Product Backlog

子主题

任务看板（1）

子主题

一个完整的任务看板

子主题

燃尽图与爬升图

子主题

第三部分    敏捷技术实践

图解敏捷开发工程实践与敏捷开发管理实践

持续集成

定义

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作 通常每个成员每天至少集成一次，每次集成都通过自动化的过程（包括编译，部署，自动化测试)来验证，从而尽快地发现错误。

简单来说，持续集成是频繁、持续地在多个团队成员的工作中进行集成，并且给予反馈。 

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作， 通常每个成员每天至少集成一次，每次集成都通过自动化的过程（包括编译，部署，自动化测试)来验证，从而尽快地发现错误。

起源

“持续集成” 一词来源于极限编程，作为其12个实践之一出现。

“持续集成” （Continuous Integration, 简称CI）.

系统的一般组成

目前主要的CI软件是Jenkins

原则

1.不提交无法构建的代码（要有本地私有构建）。  2. 经常提交 （每天至少提交一次代码）。   3. 经常签出代码（每天至少签出一次代码） 。   4. 需要有专门的集成服务器来执行集成构建, 每天至少执行一次构建。   5. 每次构建都要100%通过（通过所有的测试和审查） 。   6. 每次构建都可以生成可发布的产品（要求有自动化的测试）。   7. 修复失败的构建是优先级最高的事情。 1.一个源码库，所有需要的代码都要入库 2.Build应该是触发后可自动完成 3. 测试也应该是出发后可自动完成 4.频繁提交，尽早发现冲突，更快了解变化，鼓励小布的进步，也能让大家看到进展 5.构建成功，提交过程才算结束，一旦失败，必须马上修复 6.快速构建，才能频繁提交 7.尽可能的复制生产环境 8.目的是为了更进一步的测试，或者仅仅是为了看构建的结果 9，持续集成中，很重要的是沟通，要保证每个人都知道最新的状态和最新的修改 10，脚本自动部署，将重复的劳动交给机器，一键式

子主题

价值

子主题

典型的持续集成一般步骤

典型的持续集成步骤

持续集成流程图

子主题

Jenkins+Ant(Maven/Gradle)+UnitTest+SVN(Git)  持续集成系统 FindBugs+PMD+Sonar 代码自动静态检查

自动化测试

课程说明

目的

理解自动化测试价值 掌握敏捷开发中自动化测试基本理论 了解持续集成的基本框架、原理

对象

新员工、 项目交付负责人、 敏捷转型项目的员工、 其他想要学习自动化测试&持续集成的员工

课时

2小时

课程目标

课程收益  理解自动化测试基本原理 掌握敏捷开发中持续集成的基本框架 了解目前项目持续集成的基本现状

主要内容 自动化测试的背景与基本原理 持续集成的来源、原理、框架 自动化测试和持续集成现状

自动化测试目的?

为了保证快速得到可工作的软件。

自动化测试的优势与劣势

优势

效率

缩短软件开发测试周期，使产品更快投放市场 测试效率高，充分利用资源 节省人力成本和测试成本

可靠

增强测试的稳定性和可靠性 提高软件测试的准确度和精确度，增加软件信任度

覆盖度

自动化测试能够进行很多手工不能做的事情，如性能测试等。

劣势

当然自动化测试也有它不能及之处，例如探索性测试等，

还有一种说法，自动化测试只能发现15%-20%的bug

自动化测试和手工测试的场景应用对比

适合自动化测试

明确的，特定的测试任务 压力测试，性能测试等 相对稳定，边界修改较少的测试 在多个平台环境上运行的大量相同用例，大量的组合测试或重复性测试 周期性长，项目时间眼里不太大 被测软件具有较好的可测试性 能确保多个测试运行的构建策略 拥有测试所需的软硬件资源 软件包的验证测试

适合手工测试

一次性的项目或周期很短的项目功能测试需求不确定或变化很快实用性测试或验收测试产品的工程设计还不成熟没有适当的测试过程，测试内容，测试方法时间压力太大缺乏相关的软硬件资源

软件测试的象限

单元测试验证系统的一小部分的功能，象限一的测试的主要目的是测试驱动开发（TDD）或者测试驱动设计。首先编写测试的过程帮助程序员更好的设计代码。通过这些测试，程序员可以自行的编写代码来实现用户故事的功能，而不用担心对系统引入意外的改变。这些测试可以验证他们的设计和架构决定是否恰当。单元测试和组件测试是自动化的，使用与应用相同的编程语言编码 象限二的测试也是支持开发团队的工作，但是是在一个更高的层次上。这些面向业务的测试也叫做面向客户的测试或者客户测试，他们确定外部质量和客户需要的功能。 象限三属于面向业务的测试，这些测试使用运行的软件来查看它是否没有达到期望或能否对抗竞争。当通过面向业务的测试来评价产品时，要尽力模仿真正用户使用应用的方式。这是只有人类可以从事的手动测试 第四象限中的测试类型对敏捷开发和对许多其他类型的软件开发一样重要。这些测试的目的是面向技术的，我们使用技术而不是业务来讨论它们。象限四的面向技术的测试的目的是评价产品的性能、健壮性和安全性等特性。  摘自《敏捷软件测试：测试人员与敏捷团队的实践指南》

子主题

自动化测试金字塔

自动化测试金字塔

观点一：测试越往下面测试的效率越高，测试质量保障程度越高 观点二：测试越往下面测试的成本越低 观点三：测试越往下面，职业发展前景越好为什么？越往金字塔底层，测试的技术含量要求更高， Exploratory 探索性测试 需要补充说明的是，手工测试并不是完全丢弃的，因为测试一定要站在用户的角度，站在业务层的角度。越往金字塔的上层，在测试时越能体会到用户感受，特别是项目型公司，我这里强调的只是从测试比重分布不同而已（

计划游戏-德尔菲法

软件开发始终是一种可能的和想要的之间不断讨价还价的对话

结合使用业务优先级和技术评估

3种最常用的的估算/估计方法

专家意见

Wideband Delphi

德尔菲法又叫专家意见法

类比

将正在估计的用户故事与一个或多个其他故事进行比较

裂解

将一个用户故事或功能分解为更小、更容易估计的部分 甚至将所有用户故事都分解为相似大小，就无需估算了

计划扑克

Wideband Delphi

德尔菲法又叫专家意见法

一种用来估算用户故事大小的方法  Step 1  每个成员拿一副牌，每张牌上有不同的点数   Step 2  产品负责人简单地讲解一个用户故事   Step 3  每个成员选择出他所估算的点数的牌   Step 4  所有人同时翻牌，此时可看到对方选择的点数  Step 5    最大的和最少的解释，并讨论为什么会有点数间的差距， Step 6  重新估算，直至数值相近为止

子主题

特性团队和组件团队

设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构

子主题

结对编程（Pair Programming）

子主题

两个程序员使用同一台计算机、同一个键盘、同一个鼠标。 <ul><li>一个驾驶员，一个观察员（领航员）。</li><li>一个写测试代码，另一个写开发代码。</li><li>结对要频繁更换。</li></ul>

考勤可视化

子主题

研发过程DoD框架

课程说明

目的

帮助学员掌握项目DoD的定义、制定原则、制定过程和相关的案例学习

对象

项目经理、PO/APO、质量人员、需求经理、SM等角色

课时

2小时

主要内容

DoD的定义、收益和关键点 研发交付过程 DoD的通用总览和案例

课程目标

课程目标  理解DoD的定义，掌握DoD的制定原则、过程和方法，了解DoD制定的相关案例。

DoD定义,什么是DoD

术语定义

Definition of Done完成定义

基于“随时可向用户发布”的目标，制定衡量团队工作是否已经完成的定义，由团队和PO之间协商并达成一致。

DoD收益

1 共同协商的完成定义，是团队的自我承诺，团队会更认真； 2 用于准确评估团队的工作计划、质量和展示工作进展； 3 清晰和明确的完成定义保证了每次迭代是高质量的。

DoD关键点

1 团队自协商

团队根据项目实际情况来定义完成定义，一旦确定，就严格遵守；  一个敏捷项目有多个团队时，各个团队都要就本项目的DoD达成共识；

2 交付对象的DoD

一般分为三个对象： story Done； feature/epic Done;  release Done;

3 过程的DoD

  主要为迭代过程的DoD；

4 不断改进

随着Scrum团队的成熟，我们预期“完成”的定义会扩大，包含更严厉标准来保证高质量。 每次新的迭代计划会议，可以回顾并改进和调整DoD。

研发交付过程

项目迭代交付流程图

完成定义通用总览

完成定义通用总览 – 迭代开发

子主题

完成定义通用总览 – 交付对象

子主题

LTE完成定义实例

XXX产品案例

子主题

用户故事&估算

课程说明

目的

掌握什么是用户故事、什么是好的用户故事 掌握什么是敏捷估算，估算的基本方法

对象

新员工、需求管理人员、对用户故事&估算感兴趣的人

课时

2小时

课程目标

课程收益

理解用户故事的基本概念、作用，以及如果识别好的用户故事 掌握用户故事估算的基本概念、方法

主要内容

用户故事定义、原则 敏捷故事的定义、单位、方法 用户故事的编写

用户故事

WBS（工作分解结构）

工作分解结构（Work Breakdown Structure）

创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。

子主题

工作分解结构 回顾一下传统议题上需求管理与需求拆分情况 需求添加传统需求分析的缺点； 使用激光笔做讲解，冲击传统的需求做法。

为什么需要用户故事

软件开发是充满挑战的探险。。历史事实和实战经验告诉我们。。这些挑战常常导致痛苦的结果：失败的项目 虽然失败的原因是方方面面的，但是软件需求被识别是一种最常见的痛苦根源。不是不知道要怎么做，而是不知道要做成什么。 <此处可以看漫画或提问> 为了解决此问题，行业指定了很多规则、文件模板和相应的编写语言规范，庞大而全面的具体需求，然后失败仍然不断。。 或许使用固化呆板的文档和精确的语言的想法是错误的方向？问题的出路是否不在于复杂，而在于简单？解决方法是否不在于尽力在前期定义出细节，而在于及时响应。是否不在于文档，而在于密切的交流

简单 及时响应 交流

子主题

什么是用户故事

描述对系统或软件的每个用户或购买者都有价值的功能

用户故事    VS    传统需求

软件需求是一个沟通问题       --那些想要软件的人必须和那些构建软件的人沟通

用户故事基于用户角度编写的。 传统需求，很多基于开发者角度编写。比如一个新建数据库的需求

用户故事卡介绍

用户故事卡（3C）

Card

故事一般被写在一张记事卡上 在卡片上还可以写上估算值、注意事项等等

Conversation

隐藏在故事背后的细节，是和PO的谈出来的

Confirmation

验收测试确保故事被正确地编码

用户故事卡

故事名称

作为<用户角色>  我想要<功能简述> 以便于<价值简述>

要点

常犯错误

卡片上文字、细节太多 为卡片进行无意义的编号 以为不能修改 以为什么都能以用户故事来描述（用户界面、接口定义）

图解用户故事卡

子主题

用户故事卡案例

子主题

如何写好用户故事

INVEST

Independent 独立的

避免引入依赖

高优先级的故事依赖低优先级的 故事间先后做的顺序依赖

相互依赖会导致一系列的问题（排优先级、做计划）

子主题

Negotiable 可讨论的

3C原则中的“Conversation”

故事不是合同

它们不需要包括所有的细节 细节在客户团队和开发团队的讨论中产生

故事只是用于提醒开发人员和客户进行关于需求的讨论

一两句短语，用来提醒开发人员和客户进行对话 一些注释，用户表明在对话中亟待解决的问题 如果讨论到测试，可以标记到卡片背面

Valuable 对用户或客户有价值的

注意用户和客户的区别 故事必须有价值（对用户或客户） 应当避免那些只对开发人员有价值的故事: 可以并且尽量让客户来编写故事 切蛋糕的方式写故事

Estimatable 可估计的

故事被用于计划

 故事难以估算的原因

史诗故事           —— 拆分 缺乏领域知识   —— 与客户讨论 缺乏技术能力   —— 穿刺 缺乏封闭性       —— 拆分故事

Small 小的

<ul><li>最近要开发的特性，故事粒度要小</li><li>未来开发的特性，保持史诗故事（Epic）</li><li>故事被渐进精化，随着它们离开发越来越近</li></ul>

一般有两种类型的大故事

复杂故事：本质很大无法变小的 复合故事：多个故事组合成一个

Testable 可测试的

<ul><li>测试证明一个故事满足客户的期望</li><li>验收条件体现故事范围识别并在验收中增加约束(必须遵守但无需直接实现的故事)</li><li>不可测试的故事发生在一些非功能性的需求上</li><li>自动化、自动化、自动化</li></ul>

要点小结

用户故事卡的3C原则 用户故事的INVEST原则

用户故事估算

敏捷估算的特点

估算的一致性比准确性更重要 一般无需重新估计

对风险的估算。任何估算，不仅仅是一个值，还包括这个值的概率。 对于风险较大的任务，例如联调任务，可以估算50%完成可能性和90%完成可能性两个值， 即一般情况下的完成时间以及最坏情况下的完成时间，再据此制定计划

估算单位

估算单位——相对估算

故事点 在团队内确定一个1个故事点大小或者其他低数值的用户故事（基准故事），作为估算其他故事的参考点 基准故事也可以不止一个，可能会根据不同类的故事，分别确定某类故事的基准故事

故事点估算

子主题

估算单位——绝对估算

理想人日 团队中一个中等能力的成员在完全不受干扰的情况下，做这个故事所需要的时间（人天）

估算是一项团队活动

通常每个成员都会参与所有故事的估算 <ul><li>在计划的时候，我们一般都还不知道（也不想知道）到底谁会来实现哪个故事的哪个部分</li><li>每个故事一般涉及不同技能专长的人员</li><li>团队成员都理解了每个故事</li><li>发现不同的人对同一个故事的估算结果的很大差异</li></ul>

团队成员必须要对故事内容有一定的理解才能进行估算。 要求每个人都做估算，我们就可以确保他们都理解了每个故事的内容。 这样就为大家在sprint中相互帮助夯实了基础，也有助于故事中的重要问题被尽早发现

估算方法

专家意见

Wideband Delphi

类比

将正在估计的用户故事与一个或多个其他故事进行比较

裂解

将一个用户故事或功能分解为更小、更容易估计的部分 甚至将所有用户故事都分解为相似大小，就无需估算了

要点小结

两种估算单位

相对估算、绝对估算

故事点的序列

估算方法

看板方法

课程说明

目的

理解为什么要进行看板实践 掌握看板方法的基本原理、实践 了解看板方法与敏捷看板的关系

对象

新员工、团队管理者、敏捷转型项目的员工、其他想要学习看板管理的员工

课时

2小时

课程目标

课程收益

理解为什么要进行看板实践 掌握看板方法的基本原理、实践 了解看板方法与敏捷看板的关系

主要内容

看板动机和背景 看板方法的关键实践 看板方法与Scrum看板关系

看板动机和背景

大家看到什么了？

子主题

过载现象

给开发者带来了深深的伤害，也伤害的商业组织。 期望有一种双赢的模式。例子：公园系统

变革阻力

作为变革推进者，没有权利改变组织结构。 改变组织结构总会遇到巨大的阻力。 期望寻找一种变革阻力最小化的方法。

看板入门介绍

看板是什么？

不仅是可视化的管理方法 是改进流程的方法和工具

真正的成功建立在反馈-改进的循环。

看板不是什么？

不是流程本身？ 不是结束，只是开始。

研发看板

子主题

小结

看板的背景 看板作用 看板的定义

看板实施：核心实践

价值流映射

子主题

用价值流分析有效帮助团队做出第一个看板： 1 我们有哪些类型的工作？ 2 谁处理这些工作？ 3 我们是否应该在这些工作类型间共享职责？ 4 存在技能壁垒的情况下怎么共享职责？

1 定义团队交付的起点和终点。 2 工作项类型。 3 可视化（电子和物理看板）。 4 设置输入和输出边界。 5 应对并行活动。

设置在制品限额

WIP：work in process。“开始了但尚未完成的工作”

子主题

发现短板，设置限制

明确规则

<ul><li>看板中每一步的完成定义</li><li>公开透明</li><li>基于跨团队共识</li><li>例如紧急通道  紧急通道的整体WIP《=2等</li><li>重点项目和任务的独立“泳道”</li></ul>

子主题

管理和度量工作流

主动监测、度量和报告。度量生产周期、生产率、队列长度等信息。

子主题

找到改进点，观察改进结果。

实现反馈机制

子主题

如果没有做回顾，那就从回顾开始吧，要确保回顾可以带来真正的变化。在需要的时候可以找个外部教练。

持续改进

看板或 Scrum 不是我们的目标，持续改进才是。 软件开发中最重要的事情就是快速反馈，这也是学习的关键点。 要用好反馈！质疑一切、尝试、失败、学习、继续尝试。 不要总想着一开始就能把事情做好，因为你做不到！ 选一个地方开始，不断改进就行了。

没有从失败中成长才是真正的失败。 

看板案例

子主题

SCRUM与看板

Scrum回顾

<ul><li>组织拆分为小规模、跨功能的自组织团队。</li><li>把工作拆分为小而具体的交付物。按照优先级排序，估算其相对大小。</li><li>把时间拆分为固定大小的短迭代，每个迭代结束对对基本可以交付的产品进行演示。</li><li>迭代结束和客户一起检查发布目标，据此优化发布计划，更新优先级。</li><li>每个迭代结束，进行持续改进。</li></ul>          我们不是一个庞大的团队，花大量的时间造出庞然大物，而是用小团队，在短时间内做出小块的东西，有规律的集成出全貌。

SCRUM vs. 看板  共同点

<ul><li>既精益又敏捷，拉动式计划实践</li><li>限制了WIP，以透明的方式驱动过程改进</li><li>关注与尽早交付，频繁交付可发布的软件</li><li>需要拆分工作</li><li>发布计划是根据经验数据不断优化</li><li>基于自组织团队</li></ul>

SCRUM vs. 看板  差异

子主题

过程其他工具比较

Scrum、XP、看板都是过程工具。比如刀、叉、筷子。

比较是为了更好的理解，而不是评判优劣。

工具都不是全面的，也都不是完美的。

过程工具总结

工具规范性是要遵守的规则越多，适应性是需要遵守的规则越少。

子主题

课程目标