当前课程知识点：软件工程与软件自动化 > 第二章 敏捷开发 > 2.4 敏捷不是万能药 > 授课视频
嗨，大家好
下面我们继续讨论敏捷开发方法
前面了解了方法论来源于恐惧
讨论了两种典型的敏捷开发方法scrum和xp
下面我们要泼一泼冷水
我们要客观的，正确的
不要迷信的来认识各种各样的敏捷方法
首先来看一看对敏捷开发方法的几个误解
刚才我们也提到过
我们团队的人员素质差一些
我们上不起scrum
上不起这种敏捷方法
听说敏捷开发方法对人的要求比较高
要求没有管理，是我们自管理自组织
这是种误解
这种误解来源于，不论我们采用什么样的开发方法
人员素质的提升
团队的培养是所有的
开发人员共同努力的目标
并不是说用重型方法我的人员就可以
吃老本了，不前进了，不进步了
第二，敏捷没有文档也不做设计
这种误解大家应该很容易识别
敏捷不是没有文档
敏捷的文档强调的是一种高效的灵活的交流
设计它不像瀑布那样在集中的一个设计期来做
而是说在整个快速增量迭代的过程中来设计
所以说它的设计我们可以认为它是
分散在整个开发过程当中的
第三个，这个肯定会引起打嘴仗了
说某种好，其他的不好，这个我们就不讨论了
没有什么实际意义
敏捷就是xp，就是scrum
敏捷的方法成千上万
夸张一点说，每个人都可以说
我有自己的敏捷方法
只要你追求的是敏捷宣言所倡导的那四点
追求灵活，追求响应变化
我们就可以说自己提出了一种敏捷方法
下一个，每个项目都要遵循某一种敏捷的标准
这是一个典型的错误
我们反复强调，软件工程非常灵活
非常工程，我们要做到
无招胜有招，手中无剑，心中也无剑
就是说忘记标准，根据实际情况
实际的团队人员素质
客户的需求和公司文化等等
有诸多的因素会影响我们的选择和实施
某种敏捷方法进行软件开发
敏捷方法好，灵活高效
但是敏捷宣言宣称的四点能不能落地
这是每一个开发团队要重点考虑的问题
实际工作当中，比如说
我们希望按照scrum或xp的那种方法要求
快速的2-4周的一个迭代
但是发现根本没有办法产生一个增量的可运行版本
为什么呢？需求很混乱
搞不清楚到底客户要做什么
更要命的是代码质量差，bug丛生，管理混乱
这样一个团队如何能够按照预定的
交付日期提供高质量的软件产品呢
也就是说，我们可能采用了某种敏捷开发方法
但是我们却做不到方法当中所要求的那样
所以说，培养团队培养协作能力这是关键
看了很多书
学了很多方法，学了很多规则
我们可以根据团队实践
我们可以根据团队实践
团队当中的人员水平素质等等
来寻找适合我们的软件技术工程实践
比如说，测试驱动不错，我们试一试
觉得还可以，引入测试框架
并没有对现有的软件开发方法
产生一个巨大的冲击，造成人心惶惶
那我们就可以采用
领域驱动可以关注特定领域的知识
结对编程不适合我们，就不要引入
持续集成，大量的持续集成软件
配置复杂，运行困难
那就先不要搞全套的，全自动的
搞个半自动的，局部的测试自动化就可以了
然后逐步扩展到持续集成
前面如果做的好了
持续交付的能力就会增加
所以说这是一个逐步提高的东西
最后重构，现在我们各种的IDE当中
重构工具非常多
这种重构引入我们团队可以很大的
提高开发效率，提高开发质量
这个是重点考虑的
根据大家水平，如果说团队的开发质量很高
重构已经成为每个程序员必备的一种技能
那我们要寻求其他的技术工程实践
来进一步提升开发质量
下面看一看，在实际的工作当中
比如说，有的人说客户需求变更
变吧变吧，没关系
为什么啊？因为我们这是快速试错啊
因为我们这是迅速响应用户需求啊
就像小孩子一样，你把他惯得满地打滚
没有任何底线，没有任何的方法
第二，代码质量低劣，程序员编程水平差
代码当中bug丛生
那也不停的2周标准时间
两周出一个版本
这个版本运行不了，我不管你能不能运行
我出版本，有意义么
没有意义。但他们说这就叫快速迭代
只追求2周一个版本
不管这个版本能不能运行，是没有意义的
不写正规的设计文档，因为敏捷方法当中说了
写文档增加了沟通成本，浪费了时间
不写文档，不要作为一个借口
下一个，领导站在身后指挥程序员写代码
你说这是结对编程，这是开玩笑
产品质量不靠设计靠测试
编程的时候想，没事，大家赶紧编，随便编
反正有测试工程师做亡羊补牢式的出厂前的
最后的验证
这不是驱动测试开发
这是对TDD的一个误解，一个严重的误解
开发时间短，压缩时间，尽快交付
你说我们叫敏捷
这敏捷呢并不是说不论项目大小
都尽可能的喊口号，没日没夜的加班
尽早的交付。这不叫敏捷
在敏捷当中，其实它比较薄弱的地方还是需求分析
因为有的时候，为了过度的追求灵活，追求有效
可能会导致很多问题
需求分析是所有敏捷方法中薄弱的地方
极端的一种情况就是软件外包
现在软件外包也是非常流行的
大的软件公司承担了一个大型的软件开发项目
他们把其中的一些模块或者子系统分包出去
分包出去之后，程序员对需求的获取
是从分包方获取的
而分包方不是最终用户
他们这种把需求一条一条传下去
最终导致需求的严重被曲解
或者是说程序员需要确定一个需求的时候
发现迟迟得不到最终用户的确认
这时候问题就变得非常严重了
再优秀的再好的方法论，那就成为无米之炊了
这一点，尤其是接触到了软件外包
尤其是多次外包的情况下，结果可想而知
敏捷应该把整理需求与开发一样
当做一个逐步推进的过程
来降低需求错误的代价
专注于核心需求
通过快速增量迭代来
尽早的产出可用的软件来帮助用户获取他的业务目标
现在我们回到敏捷开发的四个宣言当中
第一，个人与互动胜于流程与工具
这是敏捷方法的核心
不同的团队，在不同项目的实施工程当中
要不停的思考
如何降低沟通成本
人员特性，人员数量，分组情况，组织结构等等
都会影响到沟通方式，沟通方式创新无极限
希望发明出创造出适合自己的沟通方式
尽可能的高效，尽可能的低成本
第二，可用的软件胜于面面俱到的文档
文档要还是不要？答案是肯定的，要
要多少？有什么用，怎么用
没用的文档就不要
需要的文档要和代码
和上游下游的分析设计文档对应起来
做好版本控制等等
这部分有很多很多具体的工作要做
每个团队都可以探索适合自己团队的文档管理方式
与客户合作胜于合同谈判
合作，怎么合作？
勾肩搭背去喝酒这不是一种良性的合作方式
我们要引导客户，我们是专业人士
客户虽然拿着钱，是我们的衣食父母
但是我们如何来引导他
让他理性的提出他的需求
甚至说我们可以超越用户，来达到他的业务目标
第四，响应变化胜于遵循计划
变，当然可以变，欢迎变
但是为什么要变？变得目的是什么
要解决什么问题
这些问题我们不停的思考，不停的创新
结合团队实践
从而能够得出独一无二的软件开发方法
敏捷是个好东西
对同学们的敏捷开发给出这样三点建议
第一点，不同的团队具有不同的最佳实践
在这门课当中，大家要分组成立一个团队
你和你的队员因为某种缘份分到了一起
你们要花大力气寻找适合你们的最佳实践
第二个建议，项目人员越多
就越不适合使用敏捷方法
我们课程的团队要求5-6人
第三个建议，对于小型团队推荐的实践有三点
第一就是TDD，测试驱动开发
第二就是要小步快跑有一个迭代
对任务分解到足够小
第三，培养团队，构建自组织自管理团队
对于敏捷方法，我们给出这样的结论
软件工程是非常实践
非常工程，非常灵活的一整套方法
没有圣经一样的方法论适合所有的团队
每个团队都需要寻找自己的方法论
方法论的顶级目标是什么？
为什么要采用这种方法？
为什么要构建团队？
顶级目标实际上就是为商业服务的
原来讨论过一个观点
技术离开了市场，变得一文不值
在某种程度上来说，这是对的
因为我们要为市场服务
为了实现客户的商业目标
创造高品质的产品来增强客户的盈利能力
帮客户挣钱，这是给客户开发软件的一个顶级目标
从这个角度来说，无论是客户还是老板
他根本不关心团队到底使用了什么样的方法
是敏捷的还是不敏捷的，他并不关心
他只关心不被你掐到脖子
他对整个过程可视
他的需求你能够响应，他有变化了，你能随时响应
容易应对市场的变更
或是来自于业务的变更
总之一句话，敏捷开发方法不是万能药
不要过分的迷信
希望大家都能够探索到适合自己团队的敏捷方法
本节就到这儿，谢谢大家
-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 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
