|
本帖最后由 靖待云飞 于 2013-4-18 14:46 编辑
敏捷开发的核心是快速的响应用户需求和呈现开发成果,这一方法被互联网公司广泛采用,但同样也应用在一些区域合作项目中,下面我来介绍一下我们公司的敏捷开发方法SCRUM.
我们公司是一个外企,总部在欧洲西部的一个小国,业务专注于专业领域,已成为全球的标杆企业,我们中国分公司成立于2010年,目前主要的业务是承接总公司的项目,进行合作开发.
总公司:1. Product Manager
2. 质量团队
本公司:1. PO
2. 团队(开发 + 测试 + 文档)
具体的工作流程: 1. PM 提供项目需求及定义
2. PO承接项目需求并转换为用户故事 user story 和 Product Backlog Iteam(PBI)
3. 团队基于PBI创建开发任务
4. 开发进行产品开发,测试进行软件测试
5. 在迭代(Sprint)结束前, 向PO演示本次Sprint的PBI完成情况(产品增量)
6. 发布版本至总公司
7. 总公司PM接收版本,总公司QA开始质量测试.
我们目前一个迭代的时间为 2周, 这对一个非互联网企业来说,这个时间我个人认为太短,不适用于应用产品的开发,但总经理不认可此点,坚持采用2周为一个SPRINT迭代.
最初我们采用的是传统的V模型,即在当前Sprint周期内,等开发把本迭代内的开发工作全部结束后,QA才开始软件测试,以致QA只有一天的时间来测试软件,导致总公司的QA团队反馈了大量的新BUG.
面对这种情况,作为QA Manager开始反省这种测试流程的不利因素,下面是我的心得,与大家分享,并希望得到大家的批评和指正.
软件生命周期
敏捷测试流程
持续集成
测试准备
每日生成
集成测试
|
|