Scrum(4) | 敏捷流程回顾反思会
Retrospective Meeting,开展回顾反思会是Scrum中最难以实施的活动之一。反思会讨论三个问题:我们上个Sprint迭代有哪些事情做得好希望继续,哪些事情做得不好希望改进,有何改进计划。
1. 开展反思会
- 在每个迭代后召开简短的反思会。
- 总结哪些事情做的好,哪些事情做的不好。
- 制定改进计划。
1.1 如何开展反思会
反思会是Scrum中最难以实施的活动之一。
反思会上讨论三个问题:
- 做得好的希望继续
- 做得不好的希望改进
- 改进计划
经常出现一些问题多次被提到,但却始终没有解决。这是很不合理的实践,应该每次仅就1~3个关键问题做出可行的解决方案,在下一个迭代执行改进。“可行”的概念包括两个含义:
- 第一是方法简单,影响面小,见效快
- 第二个是目标不要激进,而要现实可行,积少成多。
- 领导回避制度
示例:
1. 明确项目(Sprint)目标、验收标准;
2. 将Code Review作为任务固化,排入Sprint计划,Codereview进行的形式和输出将由XXX和XXX确定;
3. 提高自测质量,开发人员先写一份关于自测的test case,由测试负责人Review和补充,在开发过程中开发人员可参考这份Case进行自测;
4. 下一个Sprint中,由开发工程师自己分解任务,并进行评估,最后进行团队Review;
5. 新模块在开发前一定要经过设计。
6. UI方面的改进只是增加三人小组协调而已,有些涉及企业特有的做法,我就不展开了。
1.2 传统项目和敏捷项目的差别
传统项目 | 敏捷项目 | |
---|---|---|
项目压力 | 相对较小 | 相对较大 |
项目周期 | 一段时间(半年、一年等) | 持续,一次次SPRINT(冲刺)累积 |
测试人员 | 工作单一 | 工作复杂,角色模糊 |
文档 | 文档复杂,详尽、但是往往文档与代码不符 | 文档少、精炼,指导工作 |
需求 | 比较固定,需求变化不被容忍 | 变化大,随时可以调整 |
仪式 | 会议过多,评审过于复杂,效率低 | 会议短,高校 |
2. 项目总结
2.1 项目功能描述
你测试的模块有哪些功能?
功能介绍顺序:
- 整个项目有多少个模块,分别是什么?
- 你测试和负责了哪些具体的模块?
- 挑选一个模块,介绍都有哪些功能点?
- 再挑选一两个具体的功能点讨论进一步的测试。
按模块功能介绍每个模块的测试要点
- 介绍模块的主要使用情况
- 介绍测试着重关注的点
- 基本的等价类边界值测试
- 模块的交互测试(上下左右介绍)
- 场景,删除新增删除、搜索已删除、保存退出重新登录
2.2 项目缺陷描述
遇到了什么样的bug?
- Bug的描述,请挑选一些不常见的Bug。
- 例如用例数据量大的时候才会产生,
- 例如特定的流程才会产生,
- 例如很多测试人员容易忽略的测试场景,
- 例如用户不是很常用的场景
- Bug如何重现
- Bug如何解决
- Bug有没有定位到开发的某些习惯
- Bug有没有辅助改进测试流程等
2.3 项目积累的经验
- 项目解决了什么样的技术难题
- 项目实现了什么样的业务困难需求
- 项目有无实现了敏捷的尝试?
- 项目有无积累了某种技术,脑图,Http协议,抓包工具,数据库技术,linux技术等?
- 项目有无尝试搭建测试环境?
- 项目有无出现与开发人员的沟通问题,并顺利解决?
- 项目有无出现拖延和延期,如何处理了此类问题?
2.4 具体项目描述
项目描述:项目的业务内容
项目职责:所负责的模块、工作等
项目环境:软硬件环境
项目时间:几个月?还是持续迭代测试?
项目模式:瀑布模式还是敏捷开发?
项目收获:
- 熟悉了某种产品业务?
- 增长了测试设计能力?
- 在评审会对项目组有贡献?
- 在工作中遇到了隐藏比较深的高级bug?
- 在项目组犯了低级错误?
- 积累了某些经验?
- 学会了某些测试工具?
- 使用了项目管理工具?
- 积累了某种技术?……
3. SWOT 分析
分析自身在求职和工作中的情况
-
S
: strength:优势- 完备的测试理论知识体系
- 学历,背景(本科+,计算机相关专业?)
- 自动化测试解决方案的经验(自动化测试框架)
- 编程语言 Python Java?
- 熟悉JMeter?接口测试和性能测试
-
W
: weakness:劣势 -
O
: opportunity:机会 -
T
: Threat:威胁