2017-06-30迭代回顾
一、团队内部迭代
1.需求同步
2.需求质量不好
3.case点分析 变化的地方 相关的地方
4.缕顺业务 根据业务梳理 业务流
二、打包构建的频率规定
打包的频率：阻断性性问题解决、前期比较频繁 bug的优先级
小问题：OK 打包频率较小 长的开发周期 一谈一次
测试周期较短，头三天一天两三次
测试触发打包 构建过程
三、bug状态的关闭
开发在开发集成环境验证过折后才能fixed
四、萍姐问题：
1.需求分析，时间较短 评审的开发不是研发的开发
没有前期分析需求、导致有很多漏洞、 需求分析时间仓促
2.开发计划 迭代没有明确的目的 迭代周期的目的 客户的需求 线上的目的 需求落地的过程不明确
时间计划不明确、 上线目的不明确 、资源时间未分配好
3.需求质量不高 需求质量没有把控
需求来源 是否上线 是否满足需求的目的
从需求池里边拿出一个 需求的优先级是否经过评审 对线上和客户的影响 有效的需求分析
需求设计完就有个评审，比如：指标趋势图 葛总提供的需求 需求设计完是否跟葛总review过
搜集需求-设计-需求评审
需求评审：可实施满足定义的需求 满足用户的需求、体验、
需求培训：讲解需求是干嘛的
需求推演：数据流 业务流 让开发明确自己的任务
4.实施 以master为首 技术调研
体检、检验展示的插件 ( 指标趋势图)
测试：调研 工具
质量控制部门包含：版本控制 配置管理 流程管控（QA 包括制定开发规范，过程流程规范化）
质量管理包含以下三方面：测试、 过程跟踪和管理 、版本控制和管理 -----自己感兴趣可以后期多关注一点
ark---ARKdesign （architect lead 技术总监）去把控项目中各个技术方案 插件等的选择 全局把控。
5.测试
（1）case点
（2）配置管理和版本管理 branch 管理 多个项目多个branch
版本梳理和配置 摇一摇上了demo环境 没上生产
（3）测试流程顺畅 打版本-构建-case 点验证
（4）测试报告总结 bug管理工具更新 出daily report 比较重要，目前出的测试报告质量比较低，后期要自己慢慢试着出报告，时间长了，就有经验了
（5） 交付：性能测试和压力测试 ---预发布、生产
（6）case集编写 本期上生产之后出
每个case简单易操作 功能点明确
6.兼容性测试
第三方平台介入（1）兼容性策略的定制 （2）什么时候测
7.上线标准和流程
出一个东西----萍姐出
8.测试是没有结束的时候，问题也不会完
每个迭代要发现有价值的bug feature
9.SVN日志分析----周期（两周）
a.动了哪些地方，有什么影响 我和妮娜各自分析 一起review
b.加commnet 为什么这么加 fixed1352 修改了XXX 目前开发没有说为什么
c.不该动的地方不要动 动了这个地方影响了哪些功能、模块
d.书写规范 哪种comment比较规范
e.没有change需求的 不要动相关的代码
f.code review 要求做的 他们能做的 我们能做的----IBM 的 RFC 代码覆盖
g.持续集成，集成交付，持续部署
网友评论