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