6.5 敏捷相关

晨会

每人都要说，一般控制在1-3分钟，scrum master需要掌控节奏
内容

1. 我昨天做了哪些工作
2. 我今天准备做哪些工作
3. 我当中遇到了哪些困难（选填项，尽早申报，得到方案）
4. 我有没有任务上的延期（选填项，一旦发生，必须上报并得到帮助）？

敏捷白板图内容

当前阶段全部完成方可进入下一阶段

过程	内容
1.代设计/开发	需求设计
	需求讲解
	开发概要设计
	开发详细设计
	测试点尽早设计
	测试点尽早评审
2.设计完成
3.开发中	代码编写
	代码评审
	单元测试
	开发自测
4.待测试	测试点设计
	测试点评审
	测试用例设计
	测试用例评审
5.测试中	执行测试用例
	开发不断改缺陷
	测试缺陷验证
	影响性分析回归测试
	探索式测试
6.已测试	测试人员演示功能
7.已完成

敏捷项目知识

敏捷团队角色

1. PO：产品拥有者=项目经理（传统）
2. 需求设计人员（1位）
3. 开发组长（1位）
4. 开发（2~4位）
5. 测试组长（1位）
6. 测试（1~2位）
   scrum master 包括2，3，4，5，6。PO不可担任

一个敏捷项目团队，最多不可以超过10个人，因为，人多坏事；超过这个人数的，拆分即可

敏捷流程（十天）

每天都有晨会，但是第一天的晨会会很短，因为前一天都在开会，做的东西很少

第一天

1. 全体项目组成员进行需求讨论

2. PO公布本次迭代中，计划交付的新需求“故事”

3. PO公布本次迭代中，优化的内容

   功能逻辑优化（需求人员重新设计了更优秀合理的功能使用逻辑）
   遗漏缺陷的修复

4. Scrum Master组织大家认领任务（在国内，大多数还是组长派发的）

   分配任务之后，会和相关人员共同进行一个任务时间的评估，我们这边是分成了0.5，1，3，5这些天，如果某个任务需求的时间比较长，我们会将这个任务拆分成几个小模块。

第二天

1. 开发和测试同步工作（测试左移），开发工作部分略…

2. 设计测试点（在过程中如果有问题，及时与需求和开发沟通，测试要做好中间衔接的工作）

第三天

1. 继续设计测试点

2. 预约测试点评审会议（必须邀请需求人员，开发和测试共同参与）

第四天

1. 需求，开发和测试评审测试点

2. 修改测试点，完毕后再次通过邮件的形式告知全体与会人员 编写测试用例

第五天

1. 继续编写测试用例
2. 测试小组内对测试用例进行抽查评审
3. 准备测试环境（必要时）

第六天

1. 往往是开发的第一次提测日
2. 测试执行
   冒烟
   验证缺陷（切记！第一次提测不需要验证缺陷，因为第一个开发给你的版本根本没有缺陷）
   执行新用例

第七天

1. 测试执行

   冒烟

   验证开发目前已经修复的缺陷
   昨天执行结果是失败的用例需要重新运行，然后改变用例状态
   适当根据开发提供的影响性分析报告，做一些新功能回归
   执行剩余的新用例

第八天
。。。
第十天

上午
	预发布（灰度）测试环境进行测试（2小时）
		冒烟
		在测试环境中，发现的缺陷，已经修复了，但是测试可以挑选一些严重程度是高的缺陷，在预发测试环境里，自由测试一下（测试策略）
		根据测试点进行探索式测试/自由测试
下午
	运维人员配合测试，一起上生产；测试在生产环境上进行主流程测试，适当地对这次新的功能再测试一遍（无需执行用例）
		冒烟和主流程
			测试时间控制在20分钟内
			务必不可以动真实用户的数据
	组织一场1小时左右的，愉悦的总结会议（Retrospective Meeting）
		全体人员全部参加
		可以当做茶话会（一边吃零食一边开学）
		话题
			我们做得好的地方？
				鼓励士气
				继续保持
			我们做得不好的地方？
				提出改进方案
				在下一个迭代里进行实施（严格跟踪）
			评审整改效果（闭环）

探索式测试的“测程“”模板

人机交互的时间段就是测程
测程点：
时间
沙盒
评审结果