软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6714 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

05 | 敏捷开发到底是想解决什么问题?

宝玉 2019-03-05
你好,我是宝玉,我今天想跟你聊聊“敏捷开发”。
关于敏捷开发的实际应用,现在无外乎有以下几种常见的情形:
很多团队想敏捷开发,但不知道该怎么上手;
有的团队已经应用了一些敏捷开发的实践,然而效果不理想,不知道是敏捷开发的问题,还是自己实践方式不得当;
有的团队听说了敏捷开发,但是并不知道它是什么。
为什么会这样呢?今天我们就围绕敏捷开发来谈一谈,看看敏捷开发是什么,能帮助我们解决哪些问题,要不要实施敏捷开发,以及怎么能应用好敏捷开发。

什么是敏捷开发?

那什么是敏捷开发呢?有人认为:
敏捷开发就是 Scrum、极限编程;
敏捷开发就是每天站立会议、每两周一个 Sprint(字面意思是冲刺,可以理解为迭代);
敏捷开发就是把需求变成故事,把故事写在便签上贴到白板,然后根据状态移动到不同的列;
敏捷开发就是用看板软件来管理项目。
然而,这些是敏捷开发的真正含义吗?
要理解敏捷开发,我们先要了解其诞生背景。在 2001 年那会,瀑布模型还是主流,我们知道,瀑布模型是一种“重型”的开发模式,整个流程走完通常周期很长,少则数月,多则数年。长周期导致风险增加、难以响应变化。
于是由瀑布模型衍生出很多模型,试图去改善瀑布模型存在的问题,我已经在上一篇文章中给你介绍了一些。不过除了介绍的那些以外,在当时还有一些不怎么有名,而现在却如雷贯耳的轻量级开发方法,例如极限编程(Extreme Programming,XP)、Scrum 等。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(47)

  • 纯洁的憎恶
    流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作,对于软件工业也是如此。

    然而软件工业具备轻资产、知识密集型、从业人员素质高等特点,充分发挥人的创造力和价值,是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划”的敏捷思想应运而生。

    通过用户故事,理解用户需求。在迭代中采用渐进的架构设计。定期重构解决技术债务。功能开发的同时编写自动测试代码。自动化持续构建。

    由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段,敏捷思想的最终落地,需要素质极高的从业人员参与其中,且数量不宜过多,以此来弥补流程上的缺失。同时要团队与客户紧密协作,上级的充分信任,才能够有效发挥其灵活应变,又万变不离其宗的优势。这是大胆的返璞归真,好似回到了瀑布模型前的蛮荒时代,实则是更高级的打法,就像独孤九剑一般。所以,敏捷开发“道”的属性更浓。

    敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点,但也有苛刻的条件要求。不过,即使无法推行完整的敏捷开发,依旧可以在传统模式下,有针对性的应用敏捷开发的实践方法。

    作者回复: 又是一篇高质量的分享👍

    我没有什么好补充的,只是代表大家向你表示感谢🙏

    2019-03-06
    29
  • 极客不落🐒
    附一个补充材料,供参考:
    天下武功,唯快不破—新时代敏捷项目管理之道
    https://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ

    作者回复: 感谢推荐,我看了一下,内容质量很高👍
    大家可以参考看看

    2019-03-05
    13
  • 白发青年
    如果是外包项目,作为项目的乙方,如果采用敏捷开发,最初的工作量就很难完整估计,不利于双方的合同签订。不知老师是否有好的建议,谢谢!

    作者回复: 这个问题通常有两种解决方案:
    1. 你按照瀑布模型的方式去估算工作量,然后签订合同。开发的时候你需求分析和架构设计还是用瀑布模型的方式,但是编码和测试用敏捷开发。这是一种不错的折中方案;
    2. 你把所有需求拆分成用户故事,对用户故事进行打分(了解下计划扑克之类的打分方案),然后可以算出来一个总分数。另外按照你以前敏捷开发的经验,可以知道每个Sprint大概能完成多少分,这样你就能大致推算出来工期。

    供参考!

    2019-03-05
    12
  • 北有池鱼
    看完以后才发现我们组现在所谓的敏捷开发实际上是迭代开发的伪装!

    作者回复: 其实迭代模型已经是很不错的模型了,如果适合你们组项目需要,那就是很好的,不用纠结。

    2019-03-05
    9
  • alva_xu
    我们现在着手的一个项目,是一个软件框架建设项目,外包给供应商做的。在签合同时,基本需求已经梳理得差不多了。所以按理是可以采用瀑布式开发来进行的。但由于以下原因,所以我们结合了增量开发和Scrum项目管理的模式进行系统建设。
    1,基本需求是可以分模块来实现的
    2,我们这个项目所依赖的其他部门提供的基础平台也不是一次性可以交付我们使用的
    3,我们的使用方(另外一个应用项目)对我们项目的时间要求很急,但可以接受我们分批次交付的模块。
    基于以上原因,我们设立了几个大的增量阶段,每个增量阶段我们有分几个sprint来进行开发管理。到目前为止,进展还比较顺利。
    但由于我们这个框架建设项目的外部干系人比较多,所以在协调上游平台和下游应用系统的时候,确实遇到了许多沟通方面的问题。由于其他项目没有进行看板管理,所以需要进行例会形式的沟通来确保关键节点的功能实现。
    所以,我认为,开发模式和项目管理模式不可以拘泥于一种形式,关键还是要看是否真正达到了整体的敏捷和精益。对于文中老师提及的scrum管理和极限开发,确实是小团队内部协同作战的比较好的实践。但对于多团队协同作战,就要考虑综合运用各种方法了。
    另外,对于文中提及的站会形式,从“道”的角度来说,当然是可以视实际需求来确定是否要开,但往往一种文化的培养,需要有仪式感,需要不断锻炼。所以对于我们来说,我们还是坚持开Scrum中要求的四个重要会议的。

    作者回复: 你这对软件工程中各个模型的应用可以说是非常经典的案例了,充分结合了各种模型的优缺点和适用场景,值得大家学习借鉴👍

    软件工程知识点其实不算复杂,难的恰恰是如何灵活运用这些知识!

    还有你说的“仪式感”也是个很好的点,这些会议看起来形式化,但确实能起到仪式感的效果。

    2019-03-05
    7
  • 不再回头
    敏捷开发,对整个项目的要求都一定的门槛。
    团队成员:对需求分析的能力,需求到设计的能力,相对独立思考
    自动化:持续集成的自动化部署,环境的搭建,达到持续交付的能力,自动化测试能力
    测试验收:功能模块的验收,整体回归

    其中立会、看板都是很好的方式方法,已经在执行中。
    谢谢老师,请多指导!

    作者回复: 总结的很好👍

    敏捷开发有很多很好的实践,完全可以借鉴到非敏捷开发的项目中去,先从容易的开始,慢慢增加更多,最终也就“敏捷”起来了。

    2019-03-05
    5
  • 龙哥
    像这种情况下,有依赖交叉的用户故事应该怎么做,比如用户系统的数据库该由谁搭建。毕竟注册,登录,修改这些都可能基于一个数据表。表字段这些需要统一,不能一个程序员改一次字段名吧

    作者回复: 敏捷开发中有一个迭代0,也就是第一个迭代,就是做这些准备工作、基础架构搭建的。

    敏捷团队小,有个好处就在于遇到你说的这种情况,在做之前,大家都在一起开个小会一商量就可以定下来了

    2019-03-05
    5
  • D
    “用户故事”这个词好抽象,没太听明白。

    老师,请教您一个问题,在敏捷开发过程中如何保证业务的传承?当有新同事加进来,如何让他快速的熟悉整个业务。

    作者回复: 限于篇幅,用户故事确实没讲清楚,在文章中有推荐书籍可以作为参考,或者你也可以网上查询一些资料进一步了解,例如:http://www.woshipm.com/user-research/553736.html

    这个是个好问题,也是个大问题!

    新人的传承,通常我的经验是:
    1. 团队要有自己的知识库或WIKI,常用的知识要花时间整理上去,这样新人来了可以自己查
    2. 先给他简单的任务,再慢慢稍微复杂一点,给予必要的指导,做中学是最快速有效的
    3. 遇到一些典型的问题可以通过结对编程的方式带着一起做

    仅供参考

    2019-03-06
    1
    4
  • williamcai
    能够很快有实现的的功能,及时看到效果,给人成就感,小步慢走,一步一步重构优化,直至完成目标。坏处是走着走着,发现当前的架构不适合待开发的需求,这就需要重构,可能还要数据迁移,增加额外的工作量

    作者回复: 👍总结的很好。没有完美的方案,只有适合的方案。

    很多时候,及时看到阶段性成果,有成就感还是很重要的,经历过那种很长时间都看不到结果的项目,都不知道什么时候能看到头,每个人压力都很大的,相对来说要做点重构和数据迁移真不算什么了😄

    2019-03-05
    4
  • AICC
    这是一个自己每期跟进的专栏,第一次接触软件工程,几节内容下来,感觉对软件工程算是有了体感认知,也感觉到了专栏老师的用心,是目前学过的最走心的专栏了,留言的问题都会回复(其它专栏都是放出留言但少见回复,如果说描述性留言简单呈现能理解,但提问性留言还是只放出没回复,多少让人很郁闷,留言积极性也会下降,毕竟问题没搞明白),此外能从回复中看出来老师的鼓励和引导(这个可以看看老师的一些留言回复),同时也推荐老师的知乎专栏,宝玉的专栏,内容也很不错,像“记录下两个孩子在MineCraft里面还原公寓的经历”也能看出老师的鼓励和引导的教育方式,综上得出老师是一个leader,而不是一个管理者,哈哈哈

    作者回复: 谢谢支持,说明我努力没白费呀:)

    2019-03-05
    4
  • 阿神
    敏捷开发里开发也要写集成测试用例吗,那么测试人员主要做手工测试?

    作者回复: 对,开发不仅要写单元测试,还要写集成测试。但开发都是用模拟数据,假的API。而测试的自动化测试会用真实的数据,调用真实的API,而且也要做一部分手动测试。

    至于比例多少,还得看项目特点

    2019-03-06
    3
  • 王二宝

    每篇都有很大收获,不得不说这是让我受益最大的一个专栏。谢谢宝玉老师
    道是价值观,是一种思想,术是一种方法。
    段永平说:术是可以学习和模仿的,而道却是需要悟的。
    当你理解了道,术是可以万变的。
    我订阅了7,8个专栏,老师是第一个把道和术分开讨论的。打心底里佩服老师,谢谢

    作者回复: 谢谢支持!

    软件工程是一门相当有用的学科,我主要是领着你去学,学了你就会发现真的有价值👍

    另外我在学习攻略那一篇还提到一个观点就是教中学,就是你可以先“借道”,把别人总结得道先借过来,再结合一些术和器,去尝试总结或者讲给其他人,这过程中你也一样会有很多感悟和不一样的理解。

    2019-03-05
    3
  • holylin
    老师请教下,如果合同金额一开始就是根据商务阶段了解的情况评估的工作量而确定的,那么在合同执行过程中,如果按敏捷开发的思路,客户不断改需求我们不断地响应,然后工作量甚至已经超过了原先合同的金额,这个时候要如何处理?

    作者回复: 这是个好问题,我对这个问题上没有什么经验,但我可以试着帮你分析一下。

    你的合同是按照当时的需求签订的,如果后期客户变更需求或者增加新需求,那相当于需要重新签订变更这部分的补充合同。

    应用敏捷开发的时候,你也可以让产品经理或者项目经理充当客户的角色,这样他们会更偏重产品需求的解读,而不是重新提出新的需求:)

    还有一点,合同执行的时候,这时候你不需要太过于纠结是不是用敏捷还是迭代还是瀑布,而是哪一种开发模式,可以让你高质量高效率的完成,那就是最好的最适合你的开发模式。

    2019-03-05
    3
  • javaadu
    敏捷开发是一种价值观,可以给项目带来一些好处:及时(尽早)响应需求的变化;团队成员之间的关系和沟通比较紧密;团队成员的横向能力能得到发展;节奏比较快,客户可以不断看到改进。

    在上一家公司中,我们有专门的敏捷教练跟着每个项目团队进行落地,同时相关的基础设施比较完善:我们用JIRA去管理项目的过程、为了增加趣味性,有时候还会用实物看板、站会是根据需求调整,测试同学也提供了完整的测试用例和压测工具,不足之处是持续集成和自动化测试做得一般。

    如果现在加入一个新的团队,要实施敏捷开发,我准备从团队成员的培训和沟通上入手,一定要配专业的敏捷教练,让项目组的成员都理解敏捷的内在思路,我不会一上来就去推什么看板、站会。

    作者回复: 👍赞

    首先,可以看得出你已经开始有对敏捷开发和其中一些实践有了很多自己的思考,对不足的地方有反省,这都是非常好的现象,相信你慢慢可以有更多感悟。

    另外,我倒是建议你不要着急先不做什么,不如先都按照它的做,实施一段时间后,由团队来决定哪些该继续做,哪些可以不需要继续做,而不是你一个人(Scrum Master)来决定这些事情。

    因为Scrum Master本身不是一个控制型的角色,而是一种服务型的角色。

    2019-03-05
    1
    3
  • Felix
    目前在我们团队完全敏捷开发很难,罗马不是一天建成的,我同意老师所说的话,可以把一些好的敏捷实践先用起来

    作者回复: 👍
    是的,从瀑布到敏捷是个很大的转变,不要急于求成。

    2019-03-05
    3
  • 小老鼠
    1,老师讲的那个房子敢住吗?2、需求十分稳定的项目适合用敏捷吗?3、敏捷中又是单元测试又是自动化测试(功能、性能),工作量是否加大,令不会影响产品发布。4,现在企业人员流动比较厉害,文档细到什么程度比较合适?

    作者回复: 1. 如果是按照建筑工程标准验收通过了,当然没问题;

    2. 需求稳定的项目一样适用于敏捷开发。尤其是Scrum这样固定迭代周期的敏捷开放方式,可以倒逼你每次迭代先选择优先级高的需求。从已经确定的项目需求,选择最核心的需求,先进行迭代开发,这样你很快就可以看到一个可以运行的版本,然后每次迭代继续增加新的功能,持续发布。

    3. 磨刀不误砍柴工,前期投入了功夫在自动化测试,后期会有质量上的回报,敏捷开发会优先砍需求,所以产品可以发布,最坏结果是初期发布时,需求是不完整的,一些优先级不高的需求初期并没有加进去。

    4. 项目文档有两个主要目的:1) 帮助写的人理清楚思路; 2) 用来交流沟通。

    所以文档的关键不是细,而是达到文档的写作目的。至于粒度,可以站在文档读者的角度,结合日常开发维护场景,去思考这个文档,对于一个需要查阅文档的人来说:文档能给他什么?上面的信息是否有价值?能否达到交流沟通的目的?

    举例来说对于一个需求文档,主要的用户场景是否覆盖?输入输出条件是否清晰?交互设计是否完整?异常情况如何处理?

    举例来说一个项目交接文档,是否有整体概要的架构图,让人能从整体了解这个项目;是否有各个模块的相关说明,能大致了解各个模块的作用;是否有开发的说明,可以进行开发调试;是否有服务器部署的说明,可以按照文档对服务器进行部署更新……

    2019-08-20
    1
    2
  • 谢禾急文
    我没有经历过完整的敏捷开发,但是体验过站立会议。我感觉站立会议有以下好处:1. 明确当天目标;2. 了解团队成员的工作进展和困难:3.有困难可以及时得到同事的帮助。

    作者回复: 👍站立会议是蛮好的一个沟通交流的实践,可以尝试更多的敏捷实践,比如说缩短项目周期、迭代开发,搭建持续集成环境,用看板跟踪任务进展等等:)

    2019-05-28
    2
  • Kerry
    敏捷开发,举盖房子就不合适了,如果这样盖房子,估计没有业主同意这样做

    作者回复: 只是举个例子帮助理解,说明下迭代的过程 :)

    2019-03-21
    1
    2
  • 梁中华
    我看你在比较传统瀑布式和敏捷开发的时候,对于架构设计这块基本省略了,现在互联网开发,很多项目都面临大并发,大吞吐量的要求,如果省略了这个步骤,一般开发人员估摸着就开始开发了,这块的技术债会越来越多,甚至一上线就要重构。我感觉2001年的时候,大部分还都是桌面类的软件,互联网项目的并发量也还没这么大,或者在非功能性需求方面要求并不高,文中敏捷开发适用于大部分日常项目。但是上一定规模的项目,设计评审,特别是关键设计的评审这个步骤不能弱化,而是要强化。

    作者回复: 谢谢补充,架构设计这块文章中确实没细讲。

    也认同你的观点,架构设计是很重要的事。

    后面也会有章节继续介绍架构设计。

    2019-03-20
    2
  • 舒偌一
    老师,后面会具体讲怎么落地吗?文章后面那几本书上的内容要想落地,要求很高,有没有比较接地气的方案?适合小公司的。

    作者回复: 后面会有讲一些具体方法,不一定会面面俱到。但是你也可以留言把你具体想要什么问题的方案说一下,这样有些问题可以后面补充,有些问题可以直接回复,有些问题也许可以给你推荐书籍文章。

    2019-03-08
    2
收起评论
47
返回
顶部