敏捷开发持续集成讲解.doc

敏捷开发持续集成 目录 1.目的和范围 3 2.流程活动说明 3 2.1提供产品功能、发布日期及内容 3 2.2制定里程碑 3 2.3召开启动会 4 2.4执行开发 5 2.5执行测试 5 2.6用户测试 6 2.7是否通过用户测试确认 6 2.8产品上线 7 2.9召开迭代总结会 7 3.日常工作 7 3.1每日站会 7 3.2更新任务版 8 1.目的和范围开发使产品研发效率，高质量的成果目标体现为：客户满意：满意。 2适应变化 3、可持续 4、使开发简单当从事开发工作时，张最简单的解决方案就是最好的解决方案。教育产品中心和智慧教学产品中心。 说明功能发布日期内容 任务 输出 主导者：产品负责人 定义产品特性，输出《产品待办列表》，内容包括产品功能、功能特征的优先级、发布日期、发布内容。 《产品待办列表》 2.2制定里程碑 角色 任务 输出 主导者：产品小组负责人 参与者：产品负责人、客户 根据《产品待办列表》，与产品负责人、客户沟通，了解产品具体需求，制定并确认《里程碑计划》。 《里程碑计划》 2.3召开启动会 角色 任务 输出 主导者：产品小组负责人 参与者：开发团队、测试团队 产品小组负责人组织开发团队、测试团队召开启动会，会上产品小组负责人介绍产品《里程碑计划》，所有人根据计划，对自己感觉能完成多少内容作出相应的承诺，所有人制定2周以内的迭代目标和工作结果，每个人将目标和结果以“用户故事”的形式写到便利贴上。 所有“用户故事”在启动会上讨论，最终达到一致认可后，粘贴到白板上，粘贴了“用户故事”的白板称为“任务版”。 所有人务必在启动会上明确自己2周内的任务。 “用户故事”便利贴 注：“用户故事”样例如下 ID (通过后产品小组负责人统一编号 重要性(低/中/高) 初步估算（用户故事的大小） US_00001 中 5 故事描述 (业务层面的描述用户故事，诸如避免出现“我要加索引”这样的故事描述。 用户故事必须清晰，明确用户故事的通用格式：做为xx我希望xxx这样我就可以xxx。) 作为一个用户，我希望可以使用用户名和密码来登登录到系统，这样我可以继续其他的操作。 验收条件 (验收条件通常描述用户角度对用户故事点期望，即如何演示) 在登录页面的用户名输入框内输入正确的用户名，在密码输入框中输入正确的密码，点击登录按钮，用户登录成功 非功能性需求 (非功能性需求通常是可选的) 用户登验证使用https链接 2.4执行开发 角色 任务 输出 主导者：开发团队 开发团队根据“用户故事”进行开发。开发完1个“用户故事”后，开发组员之前互相走查代码；多于3个开发人员以上的“用户故事”开发，需要设定一个开发组长，当该“用户故事”开发完成以后，开发组长必须走查开发组员的代码。 2周内未完成启动会上通过的“用户故事”，进行惩处；顺利完成，进行红包奖励。 可测试“用户故事” 2.5执行测试 角色 任务 输出 主导者：测试团队 测试团队根据每个“用户故事”编写《测试用例》。 测试完1个迭代里所有“用户故事”后，输出完整的《测试报告》。 2周内未完成启动会上通过的“用户故事”，进行惩处；顺利完成，进行红包奖励。 《测试用例》 《测试报告》 2.6用户测试 角色 任务 输出 主导者：产品小组负责人 参与者：客户、测试团队 产品小组负责人将2周内已完成的迭代目标，部署到用户测试的环境上（该环境模拟真实用户环境），协助客户进行测试。 2.7是否通过用户测试确认 任务 输出 主导者：产品小组负责人 参与者： 客户 产品小组负责人与客户确定用户测试的结果，输出《用户测试结论书》，该文档需要客户签字确认。 如果用户测试结果是“不通过”，则将该迭代的内容进行返工。 若用户测试结论是“通过”，则产品小组负责人安排后续上线事宜。 《用户测试结论书》 2.8产品上线 任务 输出 主导者：产品小组负责人 参与者：开发人员 用户测试结论为“通过”，产品小组负责人安排开发人员完成该迭代上线工作。 产品小组负责人需要将上线内容做版本标识，便于后期进行版本管理。 2.9召开迭代总结会 任务 输出 主导者：产品小组负责人 参与者：开发团队、测试团队、产品负责人 每个迭代完成以后，产品小组负责人组织所有人召开总结会。 每个人在总结会上根据迭代完成情况，总结和分享在本迭代收获到的经验教训，以此来优化下个迭代工作的方式方法。 3.日常工作 3.1每日站会启动会开始后的第二天开始，、开发团队、测试团队每早上-9:30间举行站会。通常在每日站会上只讨论三个问题： 自上次站会我做了什么； 下次站会之前我要做