项目开发和管理流程(持续更新)

概述：

• 我们要找到符合自己项目开发和管理流程，而不是对一般流程照搬，并通过同类项目问题的根因分析来不断优化流程

需求阶段

• 需求工具：axure、蓝湖
• 需求来源（业务团队原始需求、客服备案的用户问题（迭代）、研发对实现方案的优化（迭代）、以及项目团队成员对项目的看法（迭代））
• 需求分析与制定（需求人员）：需求文档
• 需求确认（业务团队）：需求原型确认
• 需求评审（需求，开发，运维，测试、客服）：要求在评审之前，至少有半天到一天时间，有自己的问题先进行记录
• 需求流程：需求收集->需求分析->产品方案内部评审->产品方案用户确认->产品方案外部评审

注意点：

1. 需求人员需要分清需求来源的对象，一个需求可能来自不同的对象或同时来自多个对象，确定各个对象对需求的不同要求，从而得到最终需求。
2. 对需求要有所取舍。我们对需求要从正反两个方向考虑（正：这样做能解决什么用户问题，反：实现这个需求是否会引发其他的问题，这个需求重要性如何等）。
3. 对于持续改进的项目需要持续跟踪各个项目需求方的现状。项目经理必须对这个阶段加以重视，跟产品经理配合来解决好这件事情。
4. 对于需求变跟要么不做，要么延期做，要么纳入从而重新估时并及时通知其他相关的各方
5. 大的优化和需求不要一起做，不然项目管控难以控制
6. 对新平台的引进不要引入新需求

研发阶段：

 

 

设计

• 部署框架
• 软件模块图
• 软件层次图
• 时序图
• 流程图
• 数据库设计
• 缓存设计
• 接口设计
• 其它

设计评审

• 对设计阶段的产物进行评审，分析其合理性和风险性。

功能分解

• 对功能划分为各个工作包，再根据工作包优先级及其限制（工作包之间限制，时间限制、硬件限制等）对工作包进行排序
• 再根据工作包的内聚性、复杂程度和人的水平、性格、业务了解层次等特点将工作包来划分到个人。将任务分发下去后，先让项目成员进行估时，项目经理在此基础上得到最终的时间。
• 项目成员的工作包要按统一的格式输出，如果是写api，那么写明是什么api，以这样的维度容易计算工作量
• 如果人员不够或截止时间过期则走人员管理进行招聘等。从而得到项目管理计划。
• 估时既要考虑项目中的时间，也要考虑项目外的时间（会议、请假等）
• 工作包本身是不能再次进行分解的，这就要求工作包会非常细化。这样也能保证估时更为准确
• 对一个完全的新系统，研发人员对工作包的估时可能不太准确，可能需要相同岗位的同事进行辅助，尤其是新员工更是如此
• 如果多个项目并行，但需要同一个职能部门（如需求、研发、测试等），要把控两个项目的关系
• 项目与项目的节奏要稳，不要一个项目周期很短，但项目间的周期却很长，这对于产品方案评审及软件质量都有直接关系，这个依赖于产品对需求的规划。

编码

• 编码规范（如阿里云的checkstyle，也可以自定义checkstyle）
• 保证代码至少一天上传一次
• 每日工作立会：当前的项目进度、当天要完成的任务、遇到的问题、已知的风险
• 保证编码工具和管理工具的统一

评审

• 代码评审
• 规范评审

自测

• 开发人员单元测试
• 开发人员集成测试

联调

• 开发人员间系统测试
• 多个系统联调时，要求一个人有多个系统的权限，让着一个人同步跟踪

测试

• 测试人员系统测试
• 测试的测试用例要提前于开发的自测时间，并在联调的时候要走完测试用例
• 测试问题要求：

1. 测试问题
2. 测试账号和密码（不能用截图）
3. 测试标志（如跟踪id，不能用截图）
4. 测试url、测试参数、响应信息（不能用截图）

上线

开发人员要把部署要使用的文档发给运维人员，文档包括不限于：

• 数据库sql脚本
• 服务的配置文件（如application.yml）
• 要发布的服务列表

复盘

• bug复盘：鱼骨图
• 技术复盘：因为设计问题或代码问题导致异常耗损
• 管理复盘：因为工具或其它问题导致异常耗损

过程

• 要进行会议记录，并能进行记录发布
• 需求修改，能进行需求记录（如原型图的体现和需求文档的体现），并记录需求的变动，并能进行发布
• 接口修改，能进行记录，并能进行发布