当前课程知识点：软件工程与软件自动化 > 第二章 敏捷开发 > 2.2 敏捷是什么 > 授课视频
嗨，大家好
今天继续讨论敏捷开发方法
上节课我们讨论了方法论
我们认为方法论来源于恐惧
今天继续从重型方法到轻型方法展开讨论
首先来看以瀑布模型为代表的重型方法
这种重型方法它强调的是计划
过程和团队管理
这种模型它的特点是从需求开始
到设计，到编码，到测试
就像瀑布一样，水是从上往下流动
一去不复返
在这些重型方法当中
有一个很明显的特点
就是人员的分工非常明确
一般地来说分工明确是一个优点
需求人员，设计人员，编码人员
他们之间有一个防火墙
有了这个防火墙相当于一个质量门
设计的成败，设计的优劣会影响到编码
但是他们是有责任划分的
这是分工明确的好处
在敏捷方法比较成熟的今天
有的时候，可以说分工明确它也是一个缺点
后面在讲一些典型的敏捷方法的时候
就能够看到这一点
因为在那些方法当中
全体的开发人员他们之间是
主动，自发，主动认领任务
而不是命令式的管理
大家看这张图
从典型的瀑布到敏捷方法
典型的一个流程就是
这种瀑布式的开发方法
就是一个流水式的过程
反过来，敏捷方法主要特征
就是一个又一个的迭代
为了更容易看清楚这种迭代关系
我们看这张图
这张图它把传统的需求分析
需求定义
设计开发以及测试等等
这些主要的开发阶段
用一种平铺的方式把它围绕在一起
形成一个车轮，这个车轮的轴就是变更管理
这个轮子在变更管理的推动下
也就是说在用户需求的推动下
一轮一轮地向前滚动
下面来看一看典型的敏捷宣言
所谓的敏捷宣言也就是这种
敏捷方法发起的对传统的重型方法的宣战
它有四句名言
第一句是说，个体与交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
这里强调一下面面俱到的文档
文档在一些重型方法当中
要求的非常严格
比如有的企业，对开发人员来说
写了一个SQL语句
从数据库获取数据
需要在文档当中说明
为什么用这条语句
它的安全性如何
它的功能、性能的局限性和特点在哪里
恨不得一句代码写十句文档
当然这里面有夸张的成分
下面我们看
客户的合作胜过合同谈判
开始在讨论需求分析的时候
强调要把用户的需求在合同当中
作为一个附件存在
要写清楚做什么不做什么
这样可以在某种程度上
来约束客户需求变更的随意性
第四条，响应变化胜过遵循计划
重型方法强调的是一种预测性的
就是它对将来活动的预测
基于这种预测，它制定了详尽的计划
但是如果需求有了变更
这些计划就会被迫改变
所以敏捷开发方法它强调
要拥抱变化，欢迎变化
我们来具体看一看
典型的敏捷方法是如何进行宣言落地的
首先我们来看
不同的敏捷方法采用的实践是不相同的
比如大部分的敏捷开发方法都采用了
这种快速迭代的方式来响应变化
正是通过小步快跑的方式
在提交的这些版本当中
就可以夹杂着客户需求的变更
同时在这种快速迭代的过程当中
客户的谈判和客户之间的协作
变得更加亲密无间
至于可工作的软件
往往是采用持续交付的方式来完成的
也就是通过2到4周的一个小的交付
可以交付给客户可以跑的软件
可能早期的版本
它的功能是受限的，是最小的一个子集
但是正是基于这种不停滚动的
持续的交付这种可运行的软件
让用户的业务目标得以实现
对于个体和互动这方面，典型的就是站会
这个站会可能是来源于scrum这种敏捷方法
站会，站着开会，避免坐在一起
长时间陷入文山会海的烦恼当中
看板像一个小黑板，后面还会提到
敏捷方法的特征主要包括这样几项
第一项，敏捷的目标，它的目标是灵活和有效
相对于重型方法
它的目标侧重于团队，任务要灵活
并且要言之有理，行之有效
它的整个开发过程与瀑布的不同
它是一种快速的增量的迭代
这里有三个部分，第一，速度要快，2到4周
增量的，就是这个版本比上一个版本要有所推进
迭代相当于是一个螺旋形的提升
对于敏捷方法来说
它的管理风格是一种促进式的
更多的表现为一种自组织和自管理的方式
而不是那种所谓的压制式的，命令式的管理方式
它对变化的响应，表现为一种强烈的自适应性
敏捷方法对变化的响应不同于重型方法的预测
重型方法预测到了将来有可能的变化
重型方法它不是不知道有变化，它知道有变化
但是它对变化的应对方式是通过
制定更加详尽的计划来完成的
而敏捷方法强调的是
不需要制定特别详细的计划
通过团队的建设
通过过程的管理来达到一种自适应的结果
我们看这个所谓的灵活和有效
所谓的灵活和有效，主要的目标是为了更好的响应变化
变化的目的就是要加快开发进度，提高产品质量
不同的开发团队可以采用不同的
创新的方法来达到开发的灵活和有效
举个例子
马云在2016年保险年会当中
举了一个特别有意思的例子
他说他们推出了一款风力指数保险
沿海的农民害怕台风
他们这种保险有什么特点呢
农民可以通过手机投保
怎么赔呢？只要当地的，官方的气象台
发布的天气预报，风力超过6级
无条件的马上赔付，不需要任何证明
也就是不需要来证明你妈是你妈这样一个问题
对于敏捷开发方法来说，我们强调
采用方法的有效性
这个有效，这里强调两点
第一点就是所谓的成功的有效
使用了这种方法，团队建设很不错
速度提高了，质量提高了，这是成功
说明我们的方法有效
同时，如果我这种方法能够尽早的
在一两次的迭代过程当中
尽早暴露出这个项目的致命缺陷
比如说有些问题之前没有考虑到
通过这种迭代，通过我的方法能够让它
尽早的暴露出来，说明这个项目注定要失败
那要及时的止损，就像股票市场一样
失败，尽早的失败也是一种有效
第二点，讨论快速增量迭代
所谓快速增量就是小步快跑
版本要小，版本太大
不可能在2到4周的时间内提交一个可运行的版本
所以分解工作要做的非常好
小周期一般是2-4周
太长了就说明步伐有些太大
第二点，我们希望让管理者，老板
或者说是自己能够随时看到一个效果
也就是说让开发工作可视化
还记得之前我们讨论方法论的时候
方法论来源于恐惧，我们看不见
所以未知，所以我们恐惧
如果展示了我们的状态
那状态就是可视的
在这种小步快跑过程当中，可以收集
来自于客户，管理团队和开发团队的
这种变化，这种意见
同时就可以有更加精准的修改
通过这样的一种小步快跑，收集反馈，然后修正反馈
小周期的提交可运行的版本
让开发成员感觉到
在不停的进步，不停的成功
可以很好的维持开发成员的积极性
在敏捷方法当中
团队的管理方式是非常重要的
尤其是以自组织为特征
有的时候我们认为开发一个产品
并不是终极目标
我们要培养队伍
培养团队，培养一支能战斗的团队
对团队的培养，强调一点
首先团队不是一群人，或者说不仅仅是一群人
如果一群人只是在一个办公室工作，他们不叫团队
一个团队之所以能够称为 团队
是因为他们有共同的目标
有共同的工作理念和企业文化
团队成员之间自动自发，配合默契
在工作当中有互补的作用
从这一点来看，敏捷开发方法
它的团队培养是建立在个人能力
和松散管理的基础之上
这里强调对个人能力来说，两点
第一点就是个人的业务能力
我是开发人员，我的开发水平怎么样
这是一个基本的能力，如果开发水平很差
是个新手，怎么可能在2周的时间内
完成一个快速的迭代
第二个能力是自我约束能力
自我约束能力在这种自组织团队当中尤其重要
比如说我们希望团队成员
能够根据自己喜欢的和自己能做的来主动认领任务
如果一个自我约束能力差的人
他什么都逃避，什么都不做
或者是偷奸耍滑
整个团队的建设就会失败
松散的管理
不是基于高压式的管理
不是命令式的，而是基于这种主动认领任务的松散的
每个人都是管理者
基于这样一个体制之上的
自适应性呢，我们强调说
首先，需求变更在敏捷方法时代更加重要
我们认识到客户的需求变更
他不是没有理由的
同时认识到需求变更
可以给客户创造更好的竞争优势
这是为他开发软件的本质目的所在
同时我们知道需求是不稳定的，是全天候的
客户随时随地都可以从他的脑子当中抓到一个idea
然后就给你打电话
告诉你他有新的想法
对开发团队来说
对需求稳定性的判断和预测就变得很难了
因为这种需求的根源来自于用户大脑当中
如何做呢？希望通过过程的自适应
通过自组织的团队
通过这些团队当中过程的控制
来解决这种不可预测问题
不用预测那么长的时间
不用预测未来要发生的事情
只需要关注眼前的，做好眼前的
练好内功，随时准备迎接这种需求的变更
同时要注意到，那种原地踏步式的
连续适应性的变化，是没有多大意义的
也就是说这种变化
要应对变化同时要大踏步的前进
这种自适应呢，同时也强调它必须是增量式的
好，这部分内容就说这么多
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
