产品研发过程概述
我们团队的产品研发大体分为如下几个阶段：产品立项阶段、需求沟通阶段、项目策划阶段和产品迭代阶段。产品立项阶段，主要是产品经理和市场人员收集用户需求，对产品进行前期构思和规划；需求沟通阶段确保团队中的成员对产品需求达成一致；项目策划阶段明确每个人的职责；产品迭代阶段，是产品具体的实现，可以是一个或者多个迭代过程，每个阶段的详细工作将会在下文中逐一叙述。
产品研发过程基本流程如下图所示，每一种类型的工作由一种颜色来表示：
项目管理系统使用的是禅道，禅道的安装和使用说明请查看官方文档；持续集成使用的是jenkins，具体使用请查看jenkins的官方文档，或者网友的简易教程。
产品立项
在产品立项前，产品经理做充分的用户需求调研，和市场营销的同事交流沟通，得到初始的用户需求。根据原始用户需求，产品经理规划产品需求功能，绘制原始原型图并整理需求文档（需求点较粗）。
产品经理进行市场可行性分析，同时提交需求文档和原型图给技术经理，技术经理对产品进行技术可行性分析。技术经理进行技术可行性分析时，可能会涉及到线上服务器部署相关的参数，这时需要运维人员协助进行部署可行性的分析。
最后，产品立项阶段产出需求文档、需求原型图、市场可行性分析报告、技术可行性分析报告，这些文档由相关领导评审后，进入下一个阶段。
需求沟通
产品经理对产品原型图和需求文档进行完善，形成包含功能块的整体需求文档，召集项目相关人员进行需求和原型的讲解。相关人员至少包括UI设计师、开发人员、测试人员（包含QA），领导和运维人员可以选择性参加。在需求讲解会上，大家可以提出自己疑问，产品经理进行释疑；大家也可以提出自己的意见建议，供产品经理参考。需求讲解会的主要目的是让项目成员理解产品需求，并尽可能早的发现产品需求的问题，并解决问题。
需求讲解会之后，产品经理和UI设计师沟通，根据需要设计一版或两版的页面风格（每版设计一到三个页面）提供给领导审阅或审批。
技术经理根据产品需求和团队技术软实力，进行项目的技术选型，总体设计和数据库设计等。这些设计相关的工作也可以是团队的架构师或者资深的开发工程师，可以一个人或者多人共同完成。建议2到3人来做，既可以节约设计的时间，也可以给团队成员更多的学习机会。
测试人员对需求原型和需求文档进行详细阅读和学习，发现产品中的不足和风险，及时反馈给产品经理并沟通。当然，UI设计师和开发设计人员在进行设计时，如果发现问题，也要及时反馈给产品经理，这个阶段也是需求更改频繁，需求不断完善和巩固的阶段。
产品涉及的功能可能会比较多，一次性开发完成和上线风险会比较大。产品经理、技术经理和测试经理需要一起讨论商定，把产品功能拆分，分阶段开发上线，每一个阶段既是一个迭代，每次迭代的周期一般不超过一个月。大体确定每一个迭代要完成的产品功能，提交测试的时间点，上线的时间点等。在功能拆分的时候，如果发现需要调整的需求，也要进行适当的修改。
完成迭代周期的规划后，产品经理在禅道中创建产品视图，设定产品计划，禅道中的产品视图：
项目策划
此阶段主要是开发人员的技术沟通，测试人员的测试计划和测试用例沟通，所以产品经理和UI设计师在这个阶段的时间里实际上已经是在做第一个迭代周期的工作了，产品经理在禅道中录入细化需求，UI设计师开始设计页面。
技术经理组织开发人员，进行项目的技术选型讲解和沟通，总体设计师对项目的总体设计进行讲解，数据库设计师对数据库设计进行讲解。讲解沟通无异议后，技术经理对每一个大的需求功能块指定开发负责人，负责人主要负责功能的模块设计、任务分解、功能开发和提交测试的跟踪，具体的开发工作可以是负责人，也可以是其他人，根据具体的工作量调配。
测试经理制定测试方案，并和相关的测试人员沟通，分配测试人员具体负责哪些功能模块的测试工作。
运维人员根据技术人员提的要求和功能需求，对服务端部署进行设计，并把发现的问题反馈给技术经理和产品经理。
完成开发、测试的人员分工后，整个项目就进入的具体的迭代开发周期。
迭代开发
在迭代开发周期中，尽量保证项目成员的工作是并行的，以节约项目时间，保证项目按时完成上线。下文将会从迭代周期的时间点：完成任务分解、提交测试、部署上架，以及每日晨会、自动构建、每日构建、迭代总结会等方面对迭代开发工作进行讲解介绍。
每日晨会
迭代周期开始后，每日项目组所有成员举行站立式会议，沟通这一天的工作情况，会议要点为：
- 时间：每日早晨（上班后半个小时），持续15分钟以内；之前也尝试过下班前举行，但是大家工作忙了一天，状态都不是很好，不利于沟通。
- 地点和形式：公司会议室或者会客室，站立式会议。
- 内容：每人说一下自己在该项目中，昨天已经完成的主要工作，今日准备要做的工作，以及有没有待解决的问题。在会上说话时，要尽可能的面向和自己所说的工作相关的成员。
- 主持人：每日晨会都有一名主持人，主持人负责记录每人所说的昨日、今日工作和问题，并在会后，以邮件的形式把会议内容发送给项目组所有的成员。主持人由项目组成员轮流担当，可以按照姓氏或者座位排序。由项目组成员担当主持人，可以节省专门的主持人配备，并且项目组成员对项目也更加熟悉，容易理解和做会议记录。轮流担当主持人比一个人一直担当主持人，不至于对工作感到乏味，同时可以锻炼每个人的组织协调能力。
需求细化、迭代创建
产品经理（或者SA）把本次迭代的需求录入到禅道中，每一条需求要具体细化，如下图所示：
技术经理创建迭代视图，关联迭代需求，设定团队成员，如下图所示：
任务分解
根据禅道中的具体需求，UI设计分解创建页面设计任务，开发人员按责任人负责分解创建开发相关的任务，测试人员负责分解创建测试相关的任务。任务分解完成后，即刻进入任务实施阶段，UI设计师设计页面，开发人员进行代码编写，测试人员编写测试用例。
其中，UI设计工作是先导开始的，设计完成一部分页面就提供给产品经理和测试经理审批确认，确认无误后，开发人员就可以拿来使用了。所有的页面设计完成后，迭代的后续阶段，UI设计师主要是针对需求的变动做一些UI的细节调整和补充。
在任务分解的同时，技术经理或者其他开发环境负责人，负责搭建开发环境：创建代码库、创建基本代码结构、创建数据库、部署开发服务器站点等。
在开发阶段，会遇到需求不准确或者实现难度较高等问题，产品经理负责需求的沟通和变更，在禅道中变更需求，会有相应的记录并会自动发邮件给相关的人员，如图：
在提交测试之前，运维人员负责跟踪服务器的购买和环境准备。
自动构建
开发工作开始后，使用jenkins自动执行代码规范性检查，编译构建，单元测试，开发测试环境的更新，服务端文件打包，客户端打包等，如下图所示：
提交测试
在提交测试之前，测试人员负责测试环境的准备，准备好测试的服务器环境（服务器环境也可以由技术人员配置）和客户端环境。
在功能开发完成后（大部分功能完成，流程可以走通即可），版本提交负责人（开发人员）创建版本并提交测试，测试人员就可以进行测试了。
提交测试时，首先在迭代视图创建一个版本：
然后关联此版本完成的需求，解决的bug，并“提交测试“：
提交测试之后，再在迭代视图创建一个新的版本，供修改bug时关联和后续发布提交使用：
提交测试后，运维人员就可以先使用第一个版本进行线上服务端的预部署，并把部署后的相关地址反馈给开发测试人员，以供后续的每日构建使用。
每日构建
每天下班前提交一个测试版本，提交测试时，需要部署好测试的服务端，并且生成测试版本的客户端安装包，并把对应的版本文件copy到共享服务器上。每日构建的过程使用jenkins配置管理，配置如下图所示：
测试稳定达到上线标准的版本，可以在测试视图的版本中进行标记，上线更新时找到对应的共享服务器文件即可。
部署上架
从提交测试到部署上架前，测试人员要经过模块测试和综合测试。测试基本稳定后，产品经理对产品进行功能确认，并做好上架的准备，运维人员进行线上的正式部署。
正式部署后，可以邀请一些用户进行测试，测试反馈的问题再进行修改，增量更新。之后，就可以进行上架（如果有移动端）申请并发布正式版本了。
迭代总结
迭代完成，部署上线后，由产品经理或者项目组组长组织成员进行产品的演示和总结。对完成的产品和最初规划的需求进行对比，总结好的经验，下次迭代继续坚持执行；发现不足和问题，在下次迭代中优化和解决。
产品升级
后续的产品升级，就是不断的执行上述的“产品迭代阶段”的过程。如果是较大的产品升级，可以创建产品分支，在分支中执行整个的产品研发过程。