项目实践二：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：威胁
网友评论