2.7.1 敏捷开发
敏捷介绍
- 敏捷的起源
- 敏捷软件开发宣言
- 敏捷开发十二原则
- 生命周期对比
- 敏捷开发的特点
- 敏捷的发展
- 敏捷的核心
敏捷的起源
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端产品)
- 另外一种是提出需求的人自己没有想清楚(很多创新型产品,互联网行业居多)