一直以来，我个人都觉得一件事一个流程只有做到规划化和流程化才有可能做到最好，否则可能会面临混乱、错误，甚至是失败。
一个完整的产品开发流程，最近团队也一直在磨合，我们试图找到一种最合适、最舒服的协作状态，虽然过程磕磕碰碰，遇到各种挑战，但总算是有所成长。
产品开发流程的各个阶段大致是这样的：产品策划文案-UI/交互-需求评审-用例评审-开发-测试-验收。需要考虑的问题是“人"和“时间”--每个阶段由谁负责，负责的人需要何时介入，把握好这两个流程节点中的关键因素，才是我们能够完成任务的关键
流程中有个至关重要的原则就是及早的识别并且排除风险，项目成功的概率就越高。
- 产品策划文案 这个阶段正常是需要提前至少一个版本规划好，提前规划留出足够的缓冲时间来思考和完善需求，并且这段时间可以让UI、交互、技术负责人介入，提早发现技术上的风险点、UI/交互上的风险点、逻辑流程是否完善，目的就是让需求更加的完善，更早的发现和识别风险 另外又遇到临时重要紧急的需求排期需要特殊的进行处理
- UI/交互 在产品策划文案之后和下一个版本开始之前就需要介入，最好在下个版本开发工作完成之前完成对应的文档，不影响下个版本的进度
- 需求评审
需要所有利益相关者的参与（产品，开发，UI、交互，测试，数据），识别歧义并且消除歧义，发现风险并且消除风险，尽量的提前发现并且降低可能存在的风险因素，当然完全的消除风险因素是不现实的，程序员写的代码会出现BUG，很大的原因也是因为有些风险是没有被识别，被正确的处理导致的。 - 用例评审阶段 有QA主导的，以思维导图的方式，覆盖可能出现的场景，是QA冒烟测试以及开发自测的支撑文档
- 开发 评审了之后可以开始排期以及着手开发工作，任务以功能点的方式进行排期开发，分阶段的交付。任务拆分和分配的原则有两个：熟悉度以及耦合度。任务的拆分原则是耦合度小，独立的模块进行拆分；任务按照熟悉分配给开发人员。另外如果时间足够，会做交叉任务，让团队所有的成员熟悉彼此的代码，这样也会到CodeReview有帮助
- 测试 大多数是黑盒测试，使用Bugly上的流程分配缺陷，开发需要做到BUG日清（24小时之内，不是自然日），开发修改了BUG需要评估影响点，防止漏测导致的其它风险存在。如果在集成测试阶段发现了缺陷，特别的是在封包之前的1天，发现的缺陷需要评估缺陷的等级，修改的难易程度，修改会导致的影响点，测试是否有足够的回归时间，综合考虑是否需要在当前版本修改，否则可以放入缺陷池，纳入下个版本的修改。
- 验收（UI/交互验收、产品验收） 提早接入，原则上的越早越好
来源：oschina
链接：https://my.oschina.net/FEEDFACF/blog/3137271