# 模块二 基础巩固 敏捷开发 ### 敏捷介绍 * 敏捷的起源 * 敏捷软件开发宣言 * 敏捷开发十二原则 * 生命周期对比 * 敏捷开发的特点 * 敏捷的发展 * 敏捷的核心 #### 敏捷的起源 2001年，17个老头子在一起一边滑雪，一边讨论工作，制定了《敏捷软件开发宣言》 从60年代中期开始到20世纪末，软件行业得到了非常迅猛的发展，软件系统的规模和复杂度也越来越高，行业普遍面临**不满足需求，永远无法交付**等一系列严重的问题，史称“软件危机” 从长期积累的经验看，早期阶段的时间投入会影响到后期的经济支出，就是**需求变化发生的越晚，对软件交付的影响越大**，这是瀑布模式存在产生的核心观点，所以瀑布模式主张非常完整的设计，**拒绝需求变化** 拒绝变化带来双向的负面效应，软件需求方**得不到自己满意的产品**，另一方面，由于过度强调计划，**忽视领导者和管理者在团队中起的作用** 针对以上两个负面效应，敏捷软件开发宣言中“**拥抱变化**”和“**尊重个体**”成为两个核心的观点 #### 敏捷软件开发宣言 敏捷软件开发宣言： * 个体和互动 高于 流程和工具 * 工作的软件 高于 详尽的文档 * 客户合作 高于 合同谈判 * 响应变化 高于 遵循计划 #### 敏捷开发十二原则 * 我们最重要的目标，是通过及早和持续不断地交付**有价值的软件**使客户满意。 * 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 * 经常地交付**可工作的软件**，相隔几星期或一两个月，倾向于采取较短的周期。 * 业务人员和开发人员必须**相互合作**，项目中的每一天都不例外。 * 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以**信任**，从而达成目标。 * 不论团队内外，传递信息效果最好效率也最高的方式是**面对面的交谈**。 * **可工作的软件**是进度的首要度量标准。 * 敏捷过程倡导**可持续开发**。责任人、开发人员和用户要能够共同维持其步调稳定延续。 * 坚持不懈地追求**技术卓越和良好设计**，敏捷能力由此增强。 * 以**简洁**为本，它是极力减少不必要工作量的艺术。 * 最好的架构、需求和设计出自**自组织团队**。 * 团队定期地**反思**如何能提高成效，并依此**调整**自身的行为表现。 #### 生命周期对比 | 生命周期 | 需求 | 活动 | 交付 | 流程 | | ---- | ---------- | --------- | ------ | ----------------------------------------------- | | 瀑布 | 固定的，需求明确 | 整个项目进行一次 | 一次交付 | 强调文档，用里程碑的方式，严格定义各阶段的输入和输出。不走回头路，如果出现返工，付出的代价巨大 | | 敏捷 | 动态的，贴近客户需求 | 重复，直到正确为止 | 频繁小的交付 | 核心是小版本迭代。短、频、快的沟通与反馈机制，减少客户价值创造过程中的损耗 | #### 敏捷开发的特点 * 小步快跑 * 有项目计划，但也要“**拥抱变化**” * 版本迭代周期内尽量不加任务 * 团队配置也要敏捷 * 敏捷也需要反思 #### 敏捷的发展 敏捷发展的3个阶段： * 在软件行业被定义 * 在商业活动中发扬光大 * 软件商业活动汇合 后面两个阶段的开启受到了以下两个概念的启发： * 精益创业 * 持续交付2.0 **精益创业** 2021年美国作家埃里克·莱斯出版了《精益创业》一书中的**精简式反馈，以小见大**等概念与敏捷软件开发迭代模型有很多相似之处 在 SCRUM 中要求每个迭代**都能交付给有用价值的功能（可以工作的软件）** 埃里克在束中提到的最小可行性产品 MVP 强调用**最快，最简明的方式建立一个可用的产品原型**，通过这个最简单的产品原型来测试产品是否符合市场预期，并通过不断的快速迭代来修正产品，最终适应市场需求 ![](https://3083743005-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8gwpNo3eyzHkX0O40HRA%2Fuploads%2FWRykOoO6fNy8UjVmm9w1%2F230.jpg?alt=media\&token=d4ce1056-63a2-4a5b-ae46-4730fe76a958) 定义 MVP 的关键在于，**需要抓住用户的核心完整需求，在之后的迭代中不断地将核心完整需求变的好用**。要求是那些必不可少的且最后是完整可用的 **软件开发终究是为商业活动服务的**，只有在商业活动也是敏捷的情况下，敏捷软件开发才能发挥最大的威力。可惜的是精益创业的思想产生比软件敏捷开发思维晚了整整11年 **持续交付2.0** 国内 DevOps 专家乔梁在2019年出版了《持续交付2.0：业务引领的DevOps精要》中提出双环模型强调“只有业务方能够以“精益”方式思考，持续交付才能更显威力”，由此软件开发活动与商业活动有了完整统一的方法论模型 ![](https://3083743005-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8gwpNo3eyzHkX0O40HRA%2Fuploads%2FlitY7Eddk6S5Vdz5ijkx%2F231.jpg?alt=media\&token=63ad614a-fd16-4821-82e0-84ec6071b10d) * 提问：用户需要什么 * 锚定：背后的真正需求 * 共创：业务，销售，开发人员一起思考解决方案 * 精炼，决策 * 构建 * 运行 * 监测：埋点 监测环节为精益创业中产品的验证提供数据支持，通过数据来反馈产品是否符合用户预期 #### 敏捷的核心 变化来自于哪里？ 从2001年的敏捷宣言核心观点来看“拥抱变化”，多数的变化可以认为是需求 需求的变化有两种： * 一种是需求没有变，是没有理解透（很多复杂的细分行业B端产品） * 另外一种是提出需求的人自己没有想清楚（很多创新型产品，互联网行业居多）