1. 需求调研阶段
目的：
搞清楚用户想要干什么以及现阶段他们是怎么干的。
内容：
0) 向大家讨论这种工作方式和机制，要得到大家的广泛的支持和理解，让他们执行过程中基于认识和理解办事；
1) 整理一个需求调研的规范，比如命名，文件存放，工具使用，节奏等等；
2) 记录会议记录，记录客真实想法；
3) 开完会议后，基于会议记录编写用户故事，然后内部Review用户故事。编写用户故事主要目的是用客户熟悉的方式确认需求理解，同时也是未来开发人员了解需求背景的第一手资料，避免只有项目经理的脑子里面有需求的情况发生；会议的讨论问题：
1st.本次会议的核心业务是什么；
2nd.会议上面有那些概念、原理；
3rd.会议上面讨论的处理流程是怎样的；
4th.这些概念、原理以及处理流程目的（隐喻）是什么；
5th.这些概念、原理以及处理流程和其他部分有什么关系。
4) 设计原型，然后是内部Review。用户故事和设计原型的目的是类似故事的主要目的是用客户熟悉的方式确认需求理解；
1st.原型体现的业务故事是什么；
2nd.原型数据的输入-处理逻辑-输出是什么；
3rd.小组讨论，这个原型是否体现了用户故事的隐喻；
5) 用户故事得到确认后书写需求分析文档（阶段性），然后是内部Review。需求文档主要是记录输入输出，处理的识别和说明，备忘。也是未来规格概要说明书的蓝本；
成果物：
用户故事，需求规格说明书，原型设计
2.设计阶段
目的：发布一个经过验证可以满足业务需要的系统解决方案。
内容：
0) 向大家讨论这种工作方式和机制，要得到大家的广泛的支持和理解，让他们执行过程中基于认识和理解办事；
1) 整理一个设计阶段的规范（比如命名等，提供一个CheckList），文件存放，工具使用，节奏等等；
2) 划分模块，任务承担人对于模块进行DB（表结构，表间关系）<-业务逻辑设计->页面设计（基于原型设计）。这里业务逻辑设计包括类图（类的介绍，核心方法的声明和介绍以及类图中核心方法的SQL），复杂的业务交互的时序图。需要确立，这种设计的思路是一个业务的DB+逻辑设计+页面，而不是先设计全部的DB，再回过头来设计全部的逻辑设计。业务逻辑层的设计可以和数据库的设计并行开始，其实真正的设计是逻辑设计的同时完成数据库设计。
3) 半箱炉灰原则的阶段性Reivew，Review如果时间充裕，可以采用循环队列机制来共享设计内容。
1st.Review的问题有哪些；
2nd.如何避免这些问题以及更佳的解决方案是什么；
3rd.这些问题的共性之初在什么地方，那些可以提炼成为设计、开发标准，是否可以通过框架来标准化；
4) 首先需要做的就是将几个经典页面设计出来，然后规定项目组画画面的都是按照这样的页面布局和样式来进行，如果发现又不适合的，找负责页面的人进行统一处理。
成果物：数据库设计文档，逻辑设计文档，核心业务的页面设计。
3. 开发阶段
目的：实现系统的解决方案。
内容：
0) 向大家讨论这种工作方式和机制，要得到大家的广泛的支持和理解，让他们执行过程中基于认识和理解办事；
1) 整理一个设计阶段的规范（比如命名等，提供一个CheckList），文件存放，工具使用，节奏等等；
2) 在开发者开发之前必须进行评审，有开发者向大家介绍开发的思路，方式，实现的逻辑；
3) 定期Review开发人员的代码；
成果物：源代码。
4.项目组成员角色
1.页面负责人：一到两个人，负责主要页面的样式设计，以及未来新页面的设计）；
2.需求分析师：两个到三个，负责对需求的分析以及文档成形，还包括未来向项目组成员介绍需求）；
3.架构师：一人，负责技术把关，全局架构设计，负责书写样例代码，供组员使用；
4.开发人员/ 评审组成员：所有的开发人员都应该是评审组的成员，对代码进行评审。