通过小迭代实现敏捷开发 的实践已有三个月，始于 6 月中旬 前端结构 の 里程碑（v3）的调整也有一个月，前端开发的压力还是比较大的。
周三（7月13日）事件的发生有日积月累的因素，经过 深入分析，我们有一个新认知，新共识，就是要将 UI 设计稿串讲 活动引入到流程中来，提升协同效率，促进跨领域学习。着重提升产品可运营性、迭代可实现性、服务可测试性。
就像当初的产品需求串讲一样，在 UI 设计稿串讲活动 中，设计师通过阐述其设计思路，更全面、更系统、更深入地向工程开发人员传递其设计理念和设计手法。
目标
- 通过市场检验业务思路和产品设计；
- 快速迭代，通过数据验证市场反应；
- 一个迭代内，产品线框原型仅一版；
- 一个迭代内，UI视觉设计稿仅一版；
- 以相对最小代价取得相对最好结果；
周迭代－敏捷开发－示意流程图
示意流程图说明
- 从上到下代表的一种最简单理想线性的情况，通常我们是并行开展工作；
- 禅道可以帮助我们记录、跟踪、协同；
- 禅道不能代替我们的语音、视频以及面对面交流；
产品需求串讲
- 产品主持需求串讲；
- 产品、设计、工程和测试共同参加；
- 用户故事和价值交付，需求优先级；
- 鼓励串讲前提前上传，依惯例命名；
- 迭代依惯例如0.6a, 0.6b前缀标识；
页面需求澄清
- 页面需求基于 rdoc 下的线框原型；
包括业务说明和交互演示，是针对线框原型的一个补充、升级，是测试验收、对外发行的基本依据；
- 页面需求由测试组负责产出；
- 鼓励测试组在产品串讲前和产品双边沟通，尽早测试；
- 鼓励测试组页面需求在串讲后同天尽快发布；
- 澄清需求 是测试组的基础职责；
-
澄清需求 是否做到位，看其本身结构划分是否合理；
1. 页面要组织得当，能清晰反映具体包含哪些页面；
2. 重点、难点、新鲜点、复用点要单列； - 依据惯例，可以在线查看页面需求，提供访问便利；
- 依实际需要由测试组决定是否串讲；
UI 设计稿串讲
- 设计师主持设计串讲；
- 产品、设计、工程和测试共同参加；
- 设计师阐述设计思路、重点、新鲜点、注意点；
- 鼓励设计时，设计师和工程师交流，促进设计和实现双提升；
- 测试组注意设计图与产品线框的一致性，尽早测试；
- 工程组关注 Bootstrap、immy 以及业务模块的复用，同时注意组内关于实现思路、重点、难点的整合；
- 产品确认本设计实现了业务意图；
- 共同支持一线工程开发人员更快、更好地用代码把大家的想法（概念、设想）实现；
工程实现（迭代任务）
通常来说，业务需求上提出的要求越多，开发复杂度和工作量就越高；但是，这通常也是提高设计编程水平的一个好机遇，没有什么比业务需求更能强有力地快速推动我们技术的发展进步了；
划分优先级、逐步迭代实现是一个工程上的实施策略，我们一直在执行；但要明确无误地理解，这是一个策略，不是目的；开阔思路提高设计开发水平、直到完全满足业务需求才是我们一切行动的指针；
经过我们的实践发现，分解好 和 跟踪好 迭代任务是工程实现环节的关键，敏捷开发常常濒临混乱的边缘，但又能在混乱边缘把握好进度，迭代任务在其中起着十分重要的作用。
- 任务是实现页面需求的关键跟踪点；
- 工程开发人员有创建任务的必要，任务是立会交流的基石；
- 测试组有主动跟踪任务的责任（创建、了解、澄清、测试、验证、回归、建议发布）；
- 产品和设计应当增强通过禅道了解任务进展的兴趣和技能；
- 模块开发，分支开发，持续集成（基于自己的开发分支进行开发，模块测试后合并到迭代主干）；持续集成的好处是 快速发现和修复问题（Martin Fowler）；
- 开发人员任务完成后，应当指派给测试组，由测试组核实后关闭；
- 建立必要的有关产品、设计、测试的任务，目的是 排期 需要，高效协同；
- 除了必要的有关产品、设计、测试的任务外， 建议围绕工程实现类开发任务流转即可；
交付&部署（delivery vs deployment）
- 持续交付
- 持续部署
积极鼓励进行持续集成、持续交付、持续部署的自动化尝试；
开发集成-》交付测试-》生产部署；
模块测试-》功能测试-》端到端测试；
The Product Managers’ Guide to Continuous Delivery and DevOps
