分享和培训Scrum敏捷研发流程。
2023-12-11 12:26:05 0 举报
AI智能生成
Scrum敏捷开发流程的分享和培训。
作者其他创作
大纲/内容
这是模板水印,可删除
这是模板水印,可删除
软件生命周期模型
瀑布
特点
从无到有的将软件的制作过程工程化、流程化、标准化
将软件研发划分为多个阶段,按顺序开展各个阶段的工作
每个阶段都有详细的准入/准出条件,指导各个阶段的开始和完成
可对研发成本作出相对准确的预估
缺点
前一个阶段完成前,后一个阶段在资源闲置
前期工作存在错误,会在后续工作中出现错误的放大效应
无法有效的应对变更风险,当出现变更时,研发成本可能会大幅上升
客户只能在研发工作全部完成后,才能看到系统功能,无法早期得到用户反馈
增量
特点
将瀑布模型中的完整需求拆分成多个增量/模块需求进行增量开发
每个增量具备独立的分析、设计、开发、测试,然后与已有部分进行集成
相比瀑布模型提高了项目成功率、降低项目延期率
相比瀑布模型,各个环节的资源的利用率显著提高,甚至可以多个增量/模块并行开发
相比瀑布模型,提高了一定的应对变更风险的能力
缺点
需要“系统架构师”角色,承担将完整需求合理的拆成多个增量需求的重要工作
人才要求高
犯错成本高
沉默成本高
相对瀑布模型,每次增量开发工作完成需进行集成回归测试,测试工作量增加
相对瀑布模型,应对变更的能力依然有限,尤其涉及架构方面的变更,成本甚至更大
相对瀑布模型,系统的交付时间依旧是需要研发工作全部完成之后,无法早期得到用户反馈
迭代
RUP
特点
将研发过程划分为多个阶段,每个阶段由一个或多个独立的瀑布模型组成
每个阶段内的一个小的瀑布研发过程成为一个“迭代”,包含需求、分析设计、编码、测试、部署等
每个阶段结束都会提供一个可演示用的“半成品”系统给客户体验试用,获取用户反馈
相对瀑布模型,客户定期参与阶段性研发成果的评估,应对变更风险的能力显著提高
相对瀑布模型,迭代模型的适用性更广,不只适合纯软件研发,也可用于软硬件结合的产品研发,如数码、汽车等
缺点
阶段内部依然是瀑布模型,前一个环节工作完成前,后一个环节的资源依然存在闲置
随着市场和用户对软件质量的要求越来越高,类瀑布模型的软件质量问题逐步凸显——测试介入晚、修复成本高、测试不充分
相对瀑布模型,研发过程管理复杂度更高,对管理者的管理能力要求高,可能需要独立的管理人员
敏捷
Scrum
软件开发中Scrum框架的起源
敏捷思维深受日本产业最佳实践的影响,尤其是丰田和本田推出的精益原则,以及竹内博之和野上裕次郎开发的知识管理策略。
受上述思想和全球软件项目研究的影响,Jeff Sutherland于1993年首次在Easel为软件开发行业定义了Scrum流程并开始实施。
受上述思想和全球软件项目研究的影响,Jeff Sutherland于1993年首次在Easel为软件开发行业定义了Scrum流程并开始实施。
- 1986年 – Takeuchi&Nonaka在哈佛商业评论中创造了Scrum产品开发
- 1993年 – Jeff Sutherland首次使用Scrum进行软件开发。
- 1995年 – Jeff Sutherland和Ken Schwaber对Scrum框架进行了标准化,并在OOPSLA 95上公布。
- 2001年 – 发布了敏捷宣言和原则,并建立了敏捷联盟。Scrum是一种敏捷方法。
- 2002年 – Ken Schwaber和Mike Beedle推出了第一本Scrum书籍Scrum Agile Software Development。
- 2002年 – Ken Schwaber和Mike Cohn共同创立了Scrum联盟。
补充:精益、敏捷、Scrum、XP关系
(不要误解成敏捷Agile是精益Lean的一个子集 或 Scrum是敏捷Agile的一个子集)
此图的四个层级是“适用范围”大小的区别:
此图的四个层级是“适用范围”大小的区别:
- 精益Lean方法涵盖的范围要广泛得多,“将工作限制在能力范围内”和“持续流程改进”等原则几乎适用于任何环境。
- 敏捷是更高层次——只是一堆价值观和原则,根本没有实践。
- Scrum介于两者之间——不限于软件开发,但要求使用时间盒事件(Sprint/迭代/冲刺)和产品待办事项列表。
- XP更具体,仅限于软件开发中的工程最佳实践领域。
特点
在一个时间周期内(时间盒),完成一批需求的研发工作,即迭代/冲刺/sprint
每个迭代的产出是一个完整的潜在可交付的系统产品
不同于传统模型的几个新概念
Sprint 冲刺,即“迭代”
ProductBacklog 产品待办列表,即“需求池”
SprintBacklog 冲刺待办列表,即“迭代需求”
Story 用户故事,即用户视角的“需求”
Epic 史诗,即“大型用户故事”,可以分解为许多小故事
Task 任务,即“任务”,任务更具技术性,往往由一个人完成
轻文档(不是没有文档!),just enough——“刚好够”
从组织方式上解决了瀑布模型存在的资源闲置问题,各个环节全角色及时沟通反馈
缺点
需要全员参与,团队里的每个人都需要理解敏捷研发
培训
流程管理规范
需要培养Scrum Master
TL/资深兼任
独立SM
需要专业的敏捷项目管理工具支持
缺少有效工具支持,效率低且容易混乱
推荐Jira,但需培养Jira后台管理员
回归测试将成为一项挑战,自动化测试是必要的
敏捷的精髓
试错
一个字:快!
快速发布
CI/CD
快速感知
热部署、灰度发布、监控、异常处理(自动回滚……)
快速修复
快速优化
有错就改
敏捷是一种态度,试错是一种信仰。
沟通
如何沟通?
及时沟通
<8H
发现问题
解决方案
计划
执行
检查
PDCA
Plan
Do
Check
Action
沟通级别
工具&流程
消息/邮件
电话/语音/视频
面谈
正式会议
好的沟通?
Talk is cheap. Show me the code.
流程管理
研发流程
节奏
例:Intel公司的Tick-Tock模式
周一到周五?
连续工作5天,效率越来越低,最后一天发布,风险放大
周末利用不上
休息、松弛有度
缓冲、突击、冲刺,而非“救火”
迭代周期为1周?
高度成熟的研发团队
迭代周期4→3→2→1
可靠且高效的发布控制
定期发布→每日发布→随时发布
快速试错
DevOps、CI/CD
手工→自动化→容器化→容器自动化
麻雀虽小
需求/设计/用例的评审
需求变更控制
缺陷跟踪
通过成功的敏捷开发实践逐步提高效率至1周一个迭代,而非“拍脑袋”决定1周一个迭代
非敏捷
流程缺失
过程混乱
质量不可控
“埋雷”
人员情绪
团队关系
无限“救火”
恶性循环
迭代周期2周+多个发布窗口
流程图
总图
甘特图
按阶段
按角色
注:
1、原则上,排期计划里的最后发布日前2天不给开发排新任务,专注debug和准备发布相关工作;
(即便bug较少也不可随意插入新需求,不允许任意打乱排期计划,开发可用于安排自研任务)
2、回归测试是敏捷开发的一个重要工作内容,发布日前面1~2天是回归测试的执行时间;
(敏捷的一大挑战就是如何在快速的迭代研发工作中确保质量可控,回归测试是重中之重!)
3、发布日当天仍处于测试中的需求,无法合并dev/master分支进行需求验收,取消上线;
(不满足发布条件的需求就不要强行进行发布,敏捷开发是要“快”,而不是“乱”和“错”)
4、提测比预期计划延期2天以上的需求,无论能否按期上线,均记为迭代任务失败的需求;
(2周10天一个迭代,提测延期2天,已超过20%,无论是否最终按期上线,任务本身已是失败)
1、原则上,排期计划里的最后发布日前2天不给开发排新任务,专注debug和准备发布相关工作;
(即便bug较少也不可随意插入新需求,不允许任意打乱排期计划,开发可用于安排自研任务)
2、回归测试是敏捷开发的一个重要工作内容,发布日前面1~2天是回归测试的执行时间;
(敏捷的一大挑战就是如何在快速的迭代研发工作中确保质量可控,回归测试是重中之重!)
3、发布日当天仍处于测试中的需求,无法合并dev/master分支进行需求验收,取消上线;
(不满足发布条件的需求就不要强行进行发布,敏捷开发是要“快”,而不是“乱”和“错”)
4、提测比预期计划延期2天以上的需求,无论能否按期上线,均记为迭代任务失败的需求;
(2周10天一个迭代,提测延期2天,已超过20%,无论是否最终按期上线,任务本身已是失败)
迭代周期
【开始】:【第0周】的【周三】
【结束】:【第2周】的【周二】
发布窗口
窗口期
周二 20点-24点
周四 20点-24点
发布窗口期内
(支持试错的业务)不限制发布次数、回滚次数
“零容忍”的24*7业务功能,限制回滚(避免数据异常)
非发布窗口期
发布需要邮件大领导审批
每次发布/回滚操作都需要审批
优势
有助于产品-开发-测试形成共同的发布目标
给予研发团队在发布阶段的自由度,可提高效率
节奏:松→紧→松→紧
启动阶段:松
准备阶段:紧
冲刺阶段:松
(不被打扰的)专注干活的过程是“松”
发布阶段:紧
两个周末
第一个周末:排期公示的缓冲
智者千虑必有一失,排期计划不能是“一锤子买卖”
第二个周末:发布之前的缓冲
进度符合预期,休息放松,为接下来的发布工作养精蓄锐
若进度不理想,可用于加班突击,或用于应对意外情况
【※】发布之前的“突击”,与发布之后的“救火”,有着本质的不同
回归测试
最终发布日+前1~2天
全业务线主流程+需求周边影响
窗口发布日
需求周边影响
非发布日
自动化回归测试
赋能:任何人都可便捷的执行自动化测试,而非只有测试能执行
人性
人都是懒惰的!
不要假设(或想当然的认为)员工能够积极主动,设计流程要避免主观臆想
利用人性,顺应人性
质量监控
评审
静态测试/文档测试
开发自测
前后端联调
冒烟测试
“提测&打回”机制
正式测试
验收测试
发布测试
需求&变更管理
会议管理
<2H
无效
无主题
无准备
无结论
评审管理
内审
“家丑不可外扬”
互相学习,共同进步
统一风格,提高内/外合作效率
管理者的权力与价值
外审
分支管理
缺陷管理
发布流程
窗口
利于团队形成统一目标
有助于增加团队凝聚力
产品
管理工具
宁缺毋滥
易用
操作简单
学习容易
高效
直观
可靠
权限
如工作流按钮可见性,不给成员误操作的机会
自定义
工作流
字段
界面
自动化
事件
……
Jira
实操演示
0 条评论
下一页