runningya的专栏

迭代特点：小批量交付、快速反馈

目的:可以对DailyBuild的版本进行风险控制,快速验证版本功能和质量,减少手工测试,提升版本质量.流程:如图所示,各个迭代组把每日构建的版本下载到自己独立的服务器/环境,执行完整的/较完善的版本级测试用例(验证所有功能/特性的测试用例),及时发现问题（各个迭代组的代码可能出现耦合，或者开发的特性相互影响），根据问题的严重性进行定位，

1、代码没有集中检视，计划列出的检视人员都分别检视，造成前后意见不一致，浪费较多时间2、测试人员能力不足，对业务了解不够深入，只能站在黑盒外看到产品，不熟悉产品的内部实现，测试用例没有覆盖到点；开发人员代码量估计也有差，造成计划安排不准备3、计划制定诂计不足，对突发事务应对不足；4、好的想法、缺陷规避措施没有实施，只停留在概念阶段，说说而已5、设计、实现阶段开发设计依然沟通不够充分

1、资料测试在很多人看来应该是再简单不过的工作了，对于编码人员来说更是不屑去做的事，刚开始也抱着这种心态，非常排拆。但是随着工作的进行，才发现原来资料测试也不容易，对每一页面，除了要检查基本的文章结构、逻辑，还要看是否有错别字、描述不清晰等低级工作，最困难的业务的测试，由于这些资料的使用者是前方的用服或开局人员，很多业务他们未必清楚，资料如何能做到通俗易懂、易操作，要求资料写作人员的细心、全面地考

    测试与开发感觉永远都无法磨合，尽管敏捷已经把他们拉近，但是测试与开发由于知识积累，问题角度的差异，总是在一些问题有些争执。在开发看似完美无缺的设计，测试总是钻出空子质疑，因而也造成种种不快。    在设计初期，开发与测试都是处于摸索阶段，对开发来说，除了熟悉新需求，还要熟悉内部已有实现，或参考或对比；而对于测试来说，需要查询需求来源背景，关注可能涉及的正常和异常场景，提供给开发。这个时

每个迭代周期结束的回顾会议刚开始对我而言是例行公事，我一直在思考我到底从回顾会议里得到了什么？整个团队得到了什么？首先，回顾会议的在于回顾，之后总结。在公司里我们总结的议题包括“好的点TOP3 ”，“坏的点top3”，“经验教训”，“可以改进的点和措施”。与会之前所有兄弟反馈意见，会上每个人都在会上进行回顾，发表的意见，对不好的地方提出方法措施规避或保证。为什么好的、坏的都只提出3点，今天终于