VSTS探讨.pptVIP

研发部项目开发过程探讨 第一日:回顾历史 回顾历史,总结经验 透过历史展望未来 一朝被蛇咬,十年怕井绳 没有对过去历史经验进行总结回顾 也就不能从以往的成功失败中汲取经验 回顾历史 读史使人明智 挖掘历史,汲取经验 如果可以重来,我们如何抉择?我们会怎么做? 分阶段回顾 需求如何定义? 需求如何提出 需求人员提出(用户提出/使用中发现) 测试人员测试中发现 其他... 需求如何定义 客户要求,必须满足 操作不便....需要提供该功能 其他...需要满足... 需求如何沟通 口头沟通:局部人员沟通 邮件通知 其他方式 开发如何处理? 分析需求 如果需要则跟需求/测试简单讨论(口头/邮件) 分析原有设计 设计 简单设计满足需求 编码 原有代码添加新需求 对现有代码进行更改 自测 或有或无 发布 请求测试替换 打包发布,在原有基础上添加新增功能 测试如何保障产品质量? 获取需求 准备测试用例 接收开发发布版本 开始测试 提交缺陷 回归 Whats Next? 发布? 需求/项目管理人员针对新需求开发情况进行主动判断是否可以发布版本 发布(将安装包/更新包)提交给客户 客户卸载-安装 阶段性成果? 阶段性需求开发结束 接下来做什么? 只有这些吗? 测试发现与预期不一致 测试发现部分以前正常的功能有问题 需求人员发现功能实现与预期不符 客户发现其他问题 开发发现部分代码有问题 ...... 怎么处理? 突发事件! 客户/测试需要知道该版本添加/修改了什么功能/需求,如何处理的?.... 答案是?等等我看看代码 谁知道呢?这个可能也许或者... Release Notes? 如果历史可以重来? 现在大家重新思考一下如果历史可以重来,我们怎么样做的更好? 我们遇到的最大问题是什么? 沟通是一大障碍 测试的理解 开发的理解 需求的理解 明确目标 明确目标 分阶段迭代开发 迭代周期内按需求优先级进行开发 优先处理交互接口 在迭代周期中除非有非常必要,将不处理突发需求 缺陷优先处理 分解,将大功能分解为小任务 迭代开发 以两周为一个迭代周期 仅计划两周工作，后续迭代大体规划 持续发布 迭代周期中持续发布版本 确保提交代码可以编译 谁来定义目标? 需求人员 开发人员 测试人员 三方会谈,明确目标/时间 记录讨论结果,以讨论结果为蓝本进行后续跟踪 实施过程中不得擅自修改,若确定需要修改则需要提出相应申请,并加以讨论. 谁来跟踪进度? 管理人员负责跟踪需求进展情况,并对需求整体质量进行保证 将大任务分解为小任务有助于项目的推动 规范需求定义 简单描述用户使用场景 关键描述特殊情形 根据场景进行分析抽象 针对单个/多个场景进行分析,并加以抽象描述 规范化开发 明确目标:要解决/开发的是什么? 明确开发计划:设定里程碑,迭代开发 定义开发规范:分析-设计-编码-自测 定义部署要求:站在部署角度进行设计 ... 事先做好沟通 谁来约束开发? 需求人员/测试人员参与开发方案讨论 测试负责验证开发结果 开发人员互相代码重审 计划-预留时间:讨论/重审 开发人员对于自己开发的质量负责 缺陷比率 规范化测试 明确测试目标:需求,缺陷 定义测试用例:分析-设计用例-测试-回归 明确执行过程和结果 做好重现准备 数据 步骤 如何保证测试质量? 测试模块的质量就是测试人员的工作质量 测试模块的质量就是测试人员的个人绩效 产生测试报告 版本发布依据: 发布明确遗留问题的版本 加强沟通 推荐 需求分析/设计需要三方会谈明确 有问题及时沟通,但是建议不要打断别人,可以预先通知 有争议及时讨论,切忌个人处理 问题处理 整理Q/A问题列表,养成记录的习惯(好记性不如烂笔头) 一个问题不要重复多次 养成较强的分析,探索和解决能力 加强基础知识和动手能力 QA 结束 非常感谢! 个人感觉:沟通是一个非常大的问题 而软件开发中最重要的是什么? 沟通,沟通,还是沟通!!!!