Java互联网架构-项目流程管理(总结)
项目开发规范
整个项目执行有几个大的阶段,产品设计阶段、开发阶段、测试阶段、上线。产品设计阶段的推进工作由产品经理负责,开发阶段和测试阶段和上线阶段主要由开发负责人负责推进,本文主要介绍了开发负责人(以下简称项目经理)在项目执行过程中的主要职责和执行规范,目的是让我们能够高质量高效率完成项目开发工作。
产品设计阶段的最后会进入开发阶段,进入开发阶段之前有两个重要的会议"需求讨论会"和"需求讲解会"项目经理从"需求讨论会"开始全面接入项目执行。"需求讲解会"结束后表示项目经理已经正式接收项目,后面的工作全部由项目经理完成。项目经理要对项目执行的时间、质量负责。
需求讨论阶段
需求讨论阶段由产品经理负责推进,但这一阶段项目经理也是主要参与者之一,项目经理的工作能够有效推进需求讨论进程。
明确项目经理
各端负责人(组长)了解需求后第一时间指定一位项目经理。
主要产出物:组长要发一封邮件,给产品经理,并抄送相应的产品总监、技术总监、测试负责人和项目主要参与者。(主题:**项目负责人。内容:**项目由**负责开发跟进。)从这封邮件开始项目经理就全面参与这个项目的推进。
需求理解
项目经理要充分理解需求的上下文和目标,在需求讨论阶段能和产品经理保持密切的沟通,当技术和需求发生冲突时也可以有效提供解决方案。
需求分析
分析需求的可行性,以及存在的风险,能够帮助产品经理找到考虑不周的需求点,同时和相关技术讨论,保证后期需求能顺利执行,在发现问题时及时组织相关人员讨论。下面总结一下需求分析阶段的问题和解决办法。
1 产品对某个功能点考虑不周---产品经理继续完善需求。
2 某个功能点技术实现成本比较高---权衡需求的性价比和产品需求讨论,讨论无结果的可以找相应领导确认。
3 某个功能点技术无法实现---和产品经理讨论其他解决方案。
4 因为技术改动可能牵涉到其他产品的---请产品经理和其他端产品负责人协商。
需求接收
需求讲解完成后表示项目经理正式接收需求。此时主要输出物:需求预计开发工作日。现在还不能给出具体上线日期,但项目经理可以根据项目情况给出这个项目开发大概需要多少工作日。
需求开发阶段
从这个阶段开始以后的工作全部由项目经理协调完成。
接收PSD
产品经理将确认好的PSD邮件形式交给项目经理。
确定上线日期
项目经理收到PSD后要根据各方面资源情况确定上线日期。并通过邮件发送给产品经理并抄送相应的产品和技术总监以及所有参与者。个别项目PSD较多,可能会分批提供,项目经理可以根据情况决定是否确定上线日期,通常只要第一批PSD已经提供能够保证开发开始工作,同事后面几批的PSD时间也确定就可以确定上线日期。但在后面执行过程中如果PSD没有按时提供,或者PSD发生变更,项目经理可以根据情况变更上线日期。因技术内部原因引起的上线日期变更视为延期。
主要产出物:上线日期的邮件(主题:**项目上线日期。内容如:*项目暂定于**日上线)
需求设计
需求设计阶段要做大量细致工作包括:
需求充分理解,把握,提前将需求的合理性和完整性讨论清楚,减少设计评审讨论需求的时间。
详细查看PRD文档分析细节。
功能实现写入思维导图。
和相关负责人讨论数据设计。
和其他端确定功能实现思路。
有疑问的点也写在思维导图中,供设计评审时讨论。
和其他端讨论接口
明确和其他端的接口输入输出参数,包括平台、前端。
设计评审
输入内容:
数据库设计,包括表名、字段(类型、长度)、索引(唯一索引、联合索引)以及所有涉及到的SQL语句。
思维套图(推荐XMind),包括改动和涉及的所有功能点,改动方案,疑问。通过思维导图要实现伪代码编写,因此思维导图要尽量全面。
接口说明和输入输出参数。
输出内容:修改后的思维导图和数据库sql和接口功能描述。
思维导图例子:
伪代码评审
伪代码评审主要查看代码结构和具体的实现思路是否合理。评审内容主要有:
包路径、类路径及命名、URL命名及路径、方法的参数返回值及命名、方法拆分及实现思路、缓存结构内容和Key的命名。
准备工作
开发负责人安排编写伪代码,根据实际情况可以由一人或多人编写。
开发负责人审核并汇总伪代码。在这过程中开发负责人要和TU负责人确认代码是否合理,并根据业务情况分析实现思路是否合理。
评审步骤
查看思维导图中的功能点或功能模块,配合原型做简单介绍。
按以下顺序介绍伪代码:web端controler -> web端service -> client -> 平台端controler -> 平台端service(重点)
伪代码编写规范及样例
规范:
伪代码中要明确所有类路径、方法备注、方法返回值、方法名称。(重点)
尽量保证伪代码没有编译错误
简单方法的方法体可以为空或者直接return null;
伪代码中的方法个数和方法声明和开发运行阶段的一样。
调用其他方法或平台时参数要写正确
除反映调用关系的代码,不用写任何具体实现代码。
如下:
Client样例:
组织开发
协调各方资源组织开发,开发过程中遇到任何影响质量或者时间的问题及时解决,无法解决的及时找相关负责人开会讨论。
数据移植
开发结尾如果有数据移植操作要在code review之前写数据移植程序,这样可以在codereview 的时候也review数据移植程序,同时测试阶段也可以测试数据移植的正确性。数据移植注意事项:
数据移植程序尽量保证可重复运行,不能重复执行的移植程序一定要和数据库管理员、其他负责人讨论。
字段删除、变更都用加字段、去entity属性的方式实现。线上运行稳定后再进行删字段操作。
保证移植程序的执行效率,在线上应该在1小时以内完成,数据量非常大的移植要选择可重复执行的增量方式。
对于不可逆的数据移植要做好备份操作,特殊情况一定要讨论。
在线下做好数据移植程序的测试工作,尽量使用真实数据进行测试。
所有数据移植程序都要经过组长review,执行过程由组长发给数据库管理员,数据库管理员暂不接收除组长外其他任何人的数据移植程序。
code review
此时所有编码工作都应该完成,功能也是完整的,review 代码是否符合规范,是否有明显的性能问题,是否有逻辑考虑不全的地方。如果此时有大的代码结构调整(增加、拆分、合并很多方法或者类)就说明伪代码评审的力度不够。
功能review
项目经理一定在提测之前自己将功能运行一遍,保证没有明显的bug。同时也可以请产品经理试用开发完成的需求。发现问题及时修正。
性能压力测试
项目经理根据项目可以选择性进行性能或者压力测试。根据情况可以选择以下方式:
使用功能,看响应时间是否有问题(这种情况通常发生在我们调用单个接口很快,但一个操作同时调用了多个接口),查看开发阶段是否有数据库慢日志。
通过QA部门提供的压力测试工具对特殊功能进行压力测试,看是否符合标准。接口响应标准:
100<QPS <=N, Time:<5ms
20 <QPS <=100,Time:<10ms
10 <QPS <=20, Time:<20ms
5 <QPS <=10, Time:<50ms
0 <QPS <=5, Time:<100ms
特殊接口:不要超过1s
项目执行中期碰头会
对于历时比较长的项目项目经理可以考虑在项目执行中期召开项目碰头会,将项目参与者所有问题汇总,评估风险。
测试阶段
测试阶段主要由测试负责人安排测试,但这阶段项目经理也要负责主要推进工作,项目经理应该和测试负责人保持密切沟通,发现问题解释解决。主要关注:
影响测试进度的问题。
主要业务功能、流程是否能顺利测试。
根据测试bug情况评估风险。
邀请产品经理确认
我们可以在开发阶段、测试阶段和上58阶段邀请产品经理对功能进行确认。这三个阶段中最重要的产品需求确认是测试阶段,项目经理可以选择第一轮测试结束后找产品经理确认,这样能保证产品经理看到所有的功能。一定要注意:
产品经理必须对所有功能进行全面确认。
项目经理要保证所有的功能都能正常运行,保证产品经理体验到最真实连贯的效果。
提醒产品经理体验时尽量多录入数据,更贴近线上数据,避免因数据量大引起的样式或者美观问题。
确认过程中,项目经理对小的调整可以直接处理,影响项目上线的调整要组织相关人员讨论。
测试环境确认后,在58或者线上仍需调整的需求,需要记录并整理到项目总结中。
通知BI数据库变动
对于一些数据库结构的变更一定要邮件形式通知BI。
主要输出物:邮件.发送给xxoo@xxoo.com 主题:数据库变动---**项目。内容:*库变动sql 。
预计上线日期:*月*日
推进测试进度
及时发现测试中的问题,保证测试工作顺利执行。
观察日志
通过观察日志可以发现一些隐藏的bug或者慢查询,而QA通常不能及时发现这些问题,因此项目经理要在测试环境观察日志,避免潜在风险。
58测试
58测试过程最重要一点是要保证数据移植程序的正确性。参见数据移植节点。
上线阶段
观察线上日志
查看线上日志、cat、opm、意见反馈中是否有问题,发现问题及时解决。
主要产出物:邮件。主题:****项目 线上日志。内容:将问题和解决日期描述清楚。
项目总结
根据情况可以选择两种方式对项目进行总结。
主要输出物品:
项目总结会:对于项目问题较多、比较大的情况。输出会议纪要发给项目所有参与者和产品、技术总监。
项目总结邮件:主题:***项目总结 内容:将问题和对问题的分析和解决办法描述清楚。也可以写未发现明显问题。
总结
以上是对项目流程管理总结,分享给大家,希望大家可以了解什么是项目流程管理。觉得收获的话可以点个关注收藏转发一波喔,谢谢大佬们支持。(吹一波,233~~)