敏捷日记（持续ing）

【2014年1月6日】

A。估点

估点不准确：涉及到环境搭建的可以提出来单独作为一个story或者task，RD和QA可以分开考虑

B。打点

打点很随意：story不能完全独立（页面的story不应分得太细）

C。bug修复

集中在上线前：QA在完成某个story的过程中，插入了其他的task，做到一半的story无法踢到下个迭代。解决方案：迭代周期延长或上线延后

D。早会

早会：如果中途插入的事情耗时较长，RD或QA记得加task，主持人在聆听时也应有意识地提醒大家

E。产品资源不足

产品在整个团队中把控着团队的方向进度，是非常重要的角色，由于人力资源紧张，产品近期的参与度很低

【2014年12月11日】

忙忙碌碌，加班到十点半，终于结束了第二个迭代。之前保证的每日一总结，想想也是醉了~

A。早会

现在已经养成了会前5分钟回顾昨日工作的习惯，望继续坚持！

B。测试

1. 头轻脚重。

形成的原因：1）需求不够明确，在开发过程中，甚至等到测试SH才发现某些需求不明确。QA在之前构造的有些case，相当于做了无用功。

                     2）测试经验不足，在拿到需求时，能构想到的case不多，需要在测试过程中逐渐完善。

C。估点

1.该阶段的估点，我是以开发的时间+1天 进行计算，这是源于前期的测试工作中，联调和bug修复占据很大一部分时间导致的，因此，并没有考虑到四个功能相似，代码复用的情况。以后估点时，应对该迭代的需求做一个分类，类似的几个接口可以合起来估点，再均分。

D。Story的划分

1. 敏捷的其中一个原则是stroy的粒度尽可能小，这样才能高并发工作。但是确实是那么有一部分需求，并不适合这样做，或者说并不适合分开做，可以分成一个个小story，但是分到多个开发身上却不适合，不利于设计。

E。敏捷前后测试时间对比

以这次迭代中纯冻结解冻为例

之前：1~1.5天了解接口实现 + 1.5天看代码 + 3天写成功case（2个接口的，包括调通）+ 2天写其他异常case + 1天bug修复 + 1天上线 = 10天

现在：3天了解需求和写出文字版case +  3天写出能想到的所有case，但不包括具体校验 + 2天用于数据校验、调通自己的case、补充其他case + 1天bug修复加上线 = 9天 

其实对比前后，敏捷后的效率还是有一定提高，当然对于我来说，前6天的的时间肯定是可以进行缩减的，这依赖于开发方是否给出了数据结构和接口文档。

如果依照之前约定好的，开发是在设计完成后进行开发，那敏捷应该更容易推行，唯一不足的是，感觉团队人有点少，而且只有一个测试！！臣妾真的做不到啊%>_<%

【2014年12月3日】

由于个人原因，第一个迭代的总结一直拖延至今，希望接下来的日子可以坚持每天做一次回顾。

A。敏捷的理解

直到现在，我仍不能用专业术语清楚地去描述敏捷到底是什么，但有以下几点亲身体会可以分享：

1.目标更清晰。因为分解成一个个story，并赋予它们优先级，使得复杂问题简单化

2.发布周期变小。再也不用担心上线时已全然忘记一个月前自己做了什么，导致遗漏上线脚本或者被迫再次回归等问题

3.QA能尽早地加入到项目中，提早做准备，与RD并行工作

B。早会

1.时间控制得很好，几乎没有超过15分钟的时候，可能是因为一开始杨洋就强调了这个问题，大家在这个问题上都具有很强的意识

2.但建议在开早会前几分钟，最好能仔细回顾下昨日在工作上的时间分配，到底花了多少时间在支持联调、维护环境上，又花了多少时间在当前自己跟进的任务上。有时候经常会忘记汇报这些不在计划之类的工作，造成了工作量的压缩，这样就只能通过加班来解决进度问题。

C。估点

1.对于我来说，估点是整个敏捷中最难的部分，原因有几个：对自己的工作能力效率不能清楚地认识；在估点之前没有很好地了解需求，导致工作量评估有困难；担心联调等其他工作的插入，不能按时完成任务，有意识地多估计了一些时间。

解决方案：迭代启动会前花时间好好了解下需求、合理管理自己的时间、提高工作效率、参与到他们的设计阶段尽可能早点写出较全的case，从而对工作量进行调整

D。测试工作

1.测试思维的转变。在这之前，我至少需要看一遍以上开发的代码，才能写出一系列case，这样做容易去迎合开发的思维，难以发现bug。但同时，不知道对方的设计逻辑，也可能会漏掉一些case。

解决方法：在开发写代码前，先从需求写一部分case，拿到接口文档后，写一部分case，设计完成后再完善case。