会议总结1



上一个迭代的时候,出现了燃尽图没燃完,我们就把任务完成的现象。一下是开会的时候总结:
有可能出现的所有原因:
1.每个任务,估计的时间不对,测试的时间不对,在计划会议的时候没有做具体怎么做的预测,只是简单的时间
   估测
2.任务分配不充分
3.燃尽图画错了,算错了,造成的
4.效率不高,没有预留时间,质量低的问题
5.人员保障,正干的人,被抽调去干别的事情去了
6.需求变更,迭代中的其他事情,反工,质量问题
7.代码规范浪费时间
8.对需求的不准,集成的时间无限延长,两个模块之间集成的时间没有预估出来
9.当前任务完成的定义不明确
10.测试不到位导致的链形问题:5,2;5,3的问题
11.关于需求的变更没有采用诱导方式,直接修改
12.插任务:影响元素:加人,其他任务往后推,提高效率
13.总结时间比较晚
14.合版本:BOSS1,boss2提的需求在不同版本发布
15.解决BUG的时间太过长
16.如何了解需求:不是原来的讲解,而是在计划会议的时候对要做的东西与原来的需求横铺与纵铺,但是需要
开发人员不会马上去问,而不是不会装会,
17.关于禅道上任务状态的更新
18.配置管理员,质量工程师:每个已经上线的系统,当用户操作出问题的时候会写错误日志,这个错误日志的跟踪以及修改的跟踪
19.对需求的了解不彻底,导致BUG的产生
20.测试不到位,造成的BUG
21.在线上产生的bug需要最及时的干掉:bug处理的速度,以及如何调试BUG是很大的问题

改善点:
开发的速率与质量:技术 提高:看书,结对开发,以及经验。人状态:中午午休。个人节奏:与人本身的性子有关系。
环境:打断的次数
22.质量:代码质量,需求质量(原型解决这个问题),BUG数,文档质量(需求文档,帮助文档),测试质量,
     性能(动态代码的质量)
23.版本 CCNET改成项目,改成项目,改成项目之后不可以单独扔JS了甚至页面
24.自我管理
25.团队合作,新员工怎么切入到团队里面,以及执行力
26.如何带一个团队,在里面推开发与测试
28.关于开发的时候一定要带着需求去写代码的问题,以及在点页面的时候带着需求去点,而不是只是想数据库表结构
29.如何发现与解决问题?直接定位BUG的可能性配置对BUG的麻木,在后期有每个人最多也就2个BUG
30.关于对ERP的熟悉程度以及HTTP的安全过滤与脚本防御
31.以及如何去管理自己的知识点
32.关于写代码的一个技巧:为了防止打断的方案:先写伪代码
33.关于单元测试的问题:业务逻辑层,测试驱动的开发,以及测试用例,一个方法下面有N个case,
  读XML文件,数据的批量插入;UI层需要插件:单元测试+自动化测试
34.纵轴是产出的效率
我们看到底燃尽图,当与燃尽图平行时,说明今天进度是可以的,当有相交的趋势的时候说明效率高,但是没有出现
这种现象。
关于横轴时间的预估是13.5D+2D(预留时间)+2d(集成时间)
35.关于读书,一定要有选择的去读书

原文地址:https://www.cnblogs.com/muer/p/2214093.html