05 | 敏捷开发到底是想解决什么问题？
该思维导图由 AI 生成，仅供参考
什么是敏捷开发？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
敏捷开发与瀑布模型的差异在于对需求分析、架构设计、项目质量、发布部署和迭代模型的处理方式。敏捷开发强调用户故事、渐进式架构设计和持续集成，以快速响应变化和提高灵活性为目标。相比之下，瀑布模型更注重严谨的需求分析和完整的阶段划分。敏捷开发的Sprint迭代模型更注重团队协作和稳定的产品发布，而瀑布模型则更像一个小瀑布模型，需要经历完整的阶段。总的来说，敏捷开发更注重团队协作和灵活性，而瀑布模型更注重严谨的需求分析和阶段划分。 敏捷开发是一套价值观和原则，面向的是人，旨在解决瀑布模型中存在的问题。在选择敏捷开发时，需要考虑团队规模、成员协作、领导支持等条件。建议先在小项目进行试点，证明可行后再推广。敏捷开发涉及内容较多，可阅读相关书籍进行深入了解。 实施敏捷开发能带来快速响应变化、提高灵活性等好处。入手点包括团队协作、自动化测试等。已实施敏捷开发的读者可分享实践经验，讨论用法的优劣。敏捷开发为软件开发增加了选择，重点在于人而非方法。 总的来说，敏捷开发是一种非常好的软件开发模式，但在应用上需要满足一定条件才能用好。文章还将从大厂如何应用敏捷开发的角度继续讲述敏捷开发的应用。
《软件工程之美》，新⼈⾸单¥59
全部留言(59)
- 最新
- 精选
纯洁的憎恶流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作，对于软件工业也是如此。 然而软件工业具备轻资产、知识密集型、从业人员素质高等特点，充分发挥人的创造力和价值，是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”的敏捷思想应运而生。 通过用户故事，理解用户需求。在迭代中采用渐进的架构设计。定期重构解决技术债务。功能开发的同时编写自动测试代码。自动化持续构建。 由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段，敏捷思想的最终落地，需要素质极高的从业人员参与其中，且数量不宜过多，以此来弥补流程上的缺失。同时要团队与客户紧密协作，上级的充分信任，才能够有效发挥其灵活应变，又万变不离其宗的优势。这是大胆的返璞归真，好似回到了瀑布模型前的蛮荒时代，实则是更高级的打法，就像独孤九剑一般。所以，敏捷开发“道”的属性更浓。 敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点，但也有苛刻的条件要求。不过，即使无法推行完整的敏捷开发，依旧可以在传统模式下，有针对性的应用敏捷开发的实践方法。作者回复: 又是一篇高质量的分享👍 我没有什么好补充的，只是代表大家向你表示感谢🙏
2019-03-0680
白发青年如果是外包项目，作为项目的乙方，如果采用敏捷开发，最初的工作量就很难完整估计，不利于双方的合同签订。不知老师是否有好的建议，谢谢！作者回复: 这个问题通常有两种解决方案： 1. 你按照瀑布模型的方式去估算工作量，然后签订合同。开发的时候你需求分析和架构设计还是用瀑布模型的方式，但是编码和测试用敏捷开发。这是一种不错的折中方案； 2. 你把所有需求拆分成用户故事，对用户故事进行打分（了解下计划扑克之类的打分方案），然后可以算出来一个总分数。另外按照你以前敏捷开发的经验，可以知道每个Sprint大概能完成多少分，这样你就能大致推算出来工期。 供参考！
2019-03-0529
Y024
附一个补充材料，供参考： 天下武功，唯快不破—新时代敏捷项目管理之道 https://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ作者回复: 感谢推荐，我看了一下，内容质量很高👍 大家可以参考看看
2019-03-05226
北有池鱼看完以后才发现我们组现在所谓的敏捷开发实际上是迭代开发的伪装！作者回复: 其实迭代模型已经是很不错的模型了，如果适合你们组项目需要，那就是很好的，不用纠结。
2019-03-0517- alva_xu我们现在着手的一个项目，是一个软件框架建设项目，外包给供应商做的。在签合同时，基本需求已经梳理得差不多了。所以按理是可以采用瀑布式开发来进行的。但由于以下原因，所以我们结合了增量开发和Scrum项目管理的模式进行系统建设。 1，基本需求是可以分模块来实现的 2，我们这个项目所依赖的其他部门提供的基础平台也不是一次性可以交付我们使用的 3，我们的使用方(另外一个应用项目）对我们项目的时间要求很急，但可以接受我们分批次交付的模块。 基于以上原因，我们设立了几个大的增量阶段，每个增量阶段我们有分几个sprint来进行开发管理。到目前为止，进展还比较顺利。 但由于我们这个框架建设项目的外部干系人比较多，所以在协调上游平台和下游应用系统的时候，确实遇到了许多沟通方面的问题。由于其他项目没有进行看板管理，所以需要进行例会形式的沟通来确保关键节点的功能实现。 所以，我认为，开发模式和项目管理模式不可以拘泥于一种形式，关键还是要看是否真正达到了整体的敏捷和精益。对于文中老师提及的scrum管理和极限开发，确实是小团队内部协同作战的比较好的实践。但对于多团队协同作战，就要考虑综合运用各种方法了。 另外，对于文中提及的站会形式，从“道”的角度来说，当然是可以视实际需求来确定是否要开，但往往一种文化的培养，需要有仪式感，需要不断锻炼。所以对于我们来说，我们还是坚持开Scrum中要求的四个重要会议的。
作者回复: 你这对软件工程中各个模型的应用可以说是非常经典的案例了，充分结合了各种模型的优缺点和适用场景，值得大家学习借鉴👍 软件工程知识点其实不算复杂，难的恰恰是如何灵活运用这些知识！ 还有你说的“仪式感”也是个很好的点，这些会议看起来形式化，但确实能起到仪式感的效果。
2019-03-0512 
D“用户故事”这个词好抽象，没太听明白。 老师，请教您一个问题，在敏捷开发过程中如何保证业务的传承？当有新同事加进来，如何让他快速的熟悉整个业务。作者回复: 限于篇幅，用户故事确实没讲清楚，在文章中有推荐书籍可以作为参考，或者你也可以网上查询一些资料进一步了解，例如：http://www.woshipm.com/user-research/553736.html 这个是个好问题，也是个大问题！ 新人的传承，通常我的经验是： 1. 团队要有自己的知识库或WIKI，常用的知识要花时间整理上去，这样新人来了可以自己查 2. 先给他简单的任务，再慢慢稍微复杂一点，给予必要的指导，做中学是最快速有效的 3. 遇到一些典型的问题可以通过结对编程的方式带着一起做 仅供参考
2019-03-06210
不再回头敏捷开发，对整个项目的要求都一定的门槛。 团队成员：对需求分析的能力，需求到设计的能力，相对独立思考 自动化：持续集成的自动化部署，环境的搭建，达到持续交付的能力，自动化测试能力 测试验收：功能模块的验收，整体回归 其中立会、看板都是很好的方式方法，已经在执行中。 谢谢老师，请多指导！作者回复: 总结的很好👍 敏捷开发有很多很好的实践，完全可以借鉴到非敏捷开发的项目中去，先从容易的开始，慢慢增加更多，最终也就“敏捷”起来了。
2019-03-057
AICC这是一个自己每期跟进的专栏，第一次接触软件工程，几节内容下来，感觉对软件工程算是有了体感认知，也感觉到了专栏老师的用心，是目前学过的最走心的专栏了，留言的问题都会回复（其它专栏都是放出留言但少见回复，如果说描述性留言简单呈现能理解，但提问性留言还是只放出没回复，多少让人很郁闷，留言积极性也会下降，毕竟问题没搞明白），此外能从回复中看出来老师的鼓励和引导（这个可以看看老师的一些留言回复），同时也推荐老师的知乎专栏，宝玉的专栏，内容也很不错，像“记录下两个孩子在MineCraft里面还原公寓的经历”也能看出老师的鼓励和引导的教育方式，综上得出老师是一个leader，而不是一个管理者，哈哈哈作者回复: 谢谢支持，说明我努力没白费呀：）
2019-03-056
泡泡龙像这种情况下，有依赖交叉的用户故事应该怎么做，比如用户系统的数据库该由谁搭建。毕竟注册，登录，修改这些都可能基于一个数据表。表字段这些需要统一，不能一个程序员改一次字段名吧作者回复: 敏捷开发中有一个迭代0，也就是第一个迭代，就是做这些准备工作、基础架构搭建的。 敏捷团队小，有个好处就在于遇到你说的这种情况，在做之前，大家都在一起开个小会一商量就可以定下来了
2019-03-056
小老鼠1，老师讲的那个房子敢住吗？2、需求十分稳定的项目适合用敏捷吗？3、敏捷中又是单元测试又是自动化测试（功能、性能)，工作量是否加大，令不会影响产品发布。4，现在企业人员流动比较厉害，文档细到什么程度比较合适？作者回复: 1. 如果是按照建筑工程标准验收通过了，当然没问题； 2. 需求稳定的项目一样适用于敏捷开发。尤其是Scrum这样固定迭代周期的敏捷开放方式，可以倒逼你每次迭代先选择优先级高的需求。从已经确定的项目需求，选择最核心的需求，先进行迭代开发，这样你很快就可以看到一个可以运行的版本，然后每次迭代继续增加新的功能，持续发布。 3. 磨刀不误砍柴工，前期投入了功夫在自动化测试，后期会有质量上的回报，敏捷开发会优先砍需求，所以产品可以发布，最坏结果是初期发布时，需求是不完整的，一些优先级不高的需求初期并没有加进去。 4. 项目文档有两个主要目的：1) 帮助写的人理清楚思路; 2) 用来交流沟通。 所以文档的关键不是细，而是达到文档的写作目的。至于粒度，可以站在文档读者的角度，结合日常开发维护场景，去思考这个文档，对于一个需要查阅文档的人来说：文档能给他什么？上面的信息是否有价值？能否达到交流沟通的目的？ 举例来说对于一个需求文档，主要的用户场景是否覆盖？输入输出条件是否清晰？交互设计是否完整？异常情况如何处理？ 举例来说一个项目交接文档，是否有整体概要的架构图，让人能从整体了解这个项目；是否有各个模块的相关说明，能大致了解各个模块的作用；是否有开发的说明，可以进行开发调试；是否有服务器部署的说明，可以按照文档对服务器进行部署更新……
2019-08-2025
