以下流程，均基于现有的开发环境（设计、程序并行）和开发者水平重新提出的构想。
原则
- 每一层做完本层任务后，都需要直属上一层测试是否正确、如愿完成
- 每进行下一步之前，都必须开会，无异议后签字，签完字才动工。
- 顶层是客户，需求书是主导。
一、需求分析
动工之前，客户、产品，需要开一个需求分析会议。
产品必须听懂客户的需求，且产品必须并做到以下几点：
系统模块化
一个完整的系统必然是由多个小系统构成的，而这个小系统，对于程序的角度来说就是一个可以动工开发的最小模块。
模块组件化
独立子系统，每个子系统必须是一个逻辑完整的可用模块。
在项目再紧急的情况下，也必须一个模块一个模块，以完整逻辑的形式分到下面的程序实现。
如果不是，则开发开始后造成的一切改动都是不必要的成本浪费。
组件层次化
大功能、小功能。
每层要完成的事情要清楚
知道你要干啥（这很重要）。
需求书说明书
本次会议结束后，产品需要根据脑海里的最新印象，出标准的需求说明书。
需求说明书写完后，必须开会给客户检查，看是否表达出需求的完整性。如果客户对此需求书无任何异议，则需要客户和产品当面在需求说明书签字，表示开发流程可以正式启动。
尤其要说明一下，需求说明书很重要，它是所有工作的开始（草图的重要依据），也是所有工作的结束（测试的重要依据 交付、验收的主要依据）
小结
这一阶段需要完成两件事：
- 听懂客户在说什么
- 将自己听懂的以「需求说明书」的形式记录下来
二、草图
产品根据上一阶段总结的内容，开始将需求表达出来。
表达需求的第一步就是画草图，通常由最了解需求的人完成或指导下完成。
每个模块的草图设计完后，必须要开会，让客户看看是否和需求说明书上一致，不是则根据情况修改，直到客户满意。
注意：这时候是以需求书为主而非客户口头说明为主了。
客户满意后，需要双方签字，表示这个模块的草图可以交到设计师出稿。
小结
在这一阶段必须完成：需求的轮廓从无形到有形之间，尽可能无损表达的目标。
三、设计
经过客户检查通过并签字的草图，将交到设计师，设计师根据草图出稿。
设计完成后，开会，交给产品检查，看草图中提到的东西是否完整。如果检查通过则称 「定稿」。
检查通过后，谁设计的，就由谁开会向前端和后台讲述其需求细节，并提出需要注意的。
这里，当设计图定稿后，技术组需要选择相关人员参与页面和功能的设计
前端和后台做好记录，有疑问现场提出，得到解答，记录设计师对疑问的解释。
小结
这一阶段必须完成：将需求概念用 psd 实体原样表达出来，以便传递到前端使用。
四、第一次时间估算
页面和程序听完需求说明和提出存在的问题并得到解决后，便估算自己所需的时间。
然后相关人员签字，便开始自己的工作，其中，后端人员估算的时间包括两个部分：
- 架构设计和数据库设计：这部分不需要出页面就可以估算时间。
- 关联功能：这部分是需要看到前端交来的最终页面来，视页面成熟度和关联难度来估算时间
前端人员和后台人员估算时间结束后，分别和设计师开会结果整理成表，复印多份，相关人员签字，由参与人员人手一份。
之后，前端才写页面，后台开始架构设计，数据库设计。
小结
这一阶段必须完成的是：程序必须知道自己要做什么，并作出合理的时间评估。
五、页面
页面「写好」后，谁写的页面，就由谁开会负责像设计师展示其功能，包括按钮、跳转、特效、基本交互、图片尺寸等等。
设计师负责检查页面和设计稿的出入，决定是否可以交到后台。如果可以，则开会为本次页面测试通过签字，表示可以将页面交给后台人员完善功能了。
小结
这一阶段必须完成的是：设计稿所表达的东西要尽可能无损输出为页面。
六、第二次时间估算
当设计师测试完页面的完整性后，页面将交到后台，后台估算自己关联上功能的时间。
这时候需要第二次估算时间，因为在团队现有水平的基础上，一些 JS 交互，以及和获得后台数据的 JS，需要后台人员来完成。因此，这时后端需要看到经过设计师检查通过后的具体页面情况来进行第二次时间估算。
第二次时间估算结束后，需要和设计开会，双方确认后表示可以进行下一步。
小结
这一阶段必须完成的是，后台人员根据页面“复杂”情况，估算出关联上功能的时间。
七、后端
后台功能写完后，首先自己测试完基本的功能是否可用，是否对异常／边界情况进行妥善处理。
我们程序在这方面，尤其要做到：不要让客户看到任何程序报错。
然后自己对照需求和设计稿初步测试完成后，交到测试，由测试进行统一测试。
小结
这一阶段必须完成的是：功能、逻辑、数据，的完整性、正确性、安全性等。
八、最终统一测试
原则
- 测试结果按格式出表
- 简洁明了描述出现错误的具体环境，以及如何复现该错误
页面样式
- 主要测试主流浏览器兼容情况
- 对照设计图和需求书测试和设计图、需求书的出入
功能
- 主要对照需求表测试功能的：完整性、可用性、便捷性、安全性
- 对照需求书验收功能。
动态疑问
如果开发期间仍然遇到疑问和建议，比如现有设计在功能实现上有：实现不了、复杂度高、不合理等等，
开发者须立即向设计师和需求方沟通，达成一致后根据讨论才可以继续下一步。
每达成一致后，如果有在上一次定稿基础上进行修改的东西，则需求方和程序要进行统一签字，然后按最新定稿执行。
项目需求变动时怎么办？
- 本次迭代中不允许变动需求
- 重新解读需求，提出自己疑问，评估需求变动：考察「时间进度」和「技术实现」。
- 能接受，对则疑问以及，需求方对疑问的解释进行文字记录
- 签字，拿到四方签字才干活 (也不一定需要签字, 只需要四方确认即可)