项目开发流程

观文有感： 不以规矩，不能成方圆 - 《孟子》
前言：项目主要包含（业务和技术），业务和技术这两点都是不确定的，都有很大的可能会修改。但是任何的改变都不应该影响到项目的质量和稳定性。再好的业务也需要通过优秀的技术来实现良好的稳定的输出。经常发现很多公司加班加点的发布项目，修改紧急bug，或者加班加点的完成客户的需求修改等等。

问题的痛点

(1) 问题未能尽早暴露，甚至到了测试阶段需求还在修改。
(2) 完整测试用例缺失，导致未覆盖的问题暴露线上
(3) 合作对接沟通不足，导致问题在最后暴露
(4) 代码管控问题，存在代码误操作情况
(5) 发布需要更加严谨，紧急发布不能成为常态
更多的风险可以参考 百科的《软件项目风险管理》 ；以上问题的出现会影响项目的稳定和质量。更深远的影响视公司而定。

大型项目流程

kick off：参与项目的资源确定，里程碑目标以及大致时间点

小型项目流程

小型项目关注的是时间成本，快速迭代，如下图：

说明：

核心流程较大型项目来说不会变，而是着重突出，由核心流程的完成度保证质量
具有更大灵活性，但不代表放纵，如果本阶段达不到进入下一个阶段的前置要求，需要打回重新进行
小型项目附有责任连带性，如果最终上线出了问题，所有参与项目的人员都有连带责任
特殊项目 - 紧急发布

定位：紧急发布重在”紧急”二字，所以平时的发布不应该也没必要走紧急发布通道

紧急发布原则：

原则上不应该进行紧急发布，当且仅当出现如下情况：
(1) 线上bug同时影响面很广，如果影响面非常小，建议下次发布节点进行发布
(2) 外部造成的系统必须升级
紧急发布必须记录在aone上，需要详细记录紧急发布的系统，原因，造成的影响等
紧急发布需要发布系统owner和浩哥双重同意
项目发布不再走紧急发布，尽量往二四发布日靠，如果实在不行，走项目发布申请
角色定位

项目过程中，产品、技术、测试应三方互相限制，互相促进以及推动，如下图：

产品定位

产品在各个节点的关注内容如下图：

需求评审

评审原则:
需求评审需提前2天邮件发出，并在邮件中给出评审文档
评审不是讨论，不能有过多异议，如果有需求不确定，请放入下期迭代
不接受需求边做边想，质量低很多起源于没想清楚
请将需求user case化，流程图只是辅助，请站在用户角度罗列出其相应的操作，好记性不如烂笔头
参与人：项目全员，各个负责人
PRD文档关注点:
需求是否都通过user case的形式展现，不接受只有几张图的PRD
需求所解决的痛点，价值所在
需求的影响范围，边界是否清晰
需求流程是否清晰。对现有流程改动，是否平滑迁移？新增的流程，是否会对原有造成影响？
异常流程考虑
文案是否完整？
对产品的整体考虑
审查标准:
10%：评审中不应超过10%异议
10%：评审的需求和后续变更出入率不超过10%
无严重影响工期缺陷存在
中期跟踪

进度：随时跟踪项目进度，可每日组织站会，风险点及早暴露
需求check：跟踪实现过程和阶段成果，确保实现和需求保持一致
验收：在发布上线前，验收所有需求流程
上线观察

咨询解答: 提供用户咨询答案，如果是技术问题，转交技术同事
bug跟进: 若遇到bug, 及时反馈技术，视紧急程度修复发布，跟进情况
效果反馈: 在观察周期内，配合运营得到需求效果（数据报表，建议等）
发起总结会议: 项目有始有终，根据各方反馈结果发起项目总结会议，具体见项目总结会议一栏
统计标准

技术会统计过程中遇到的量化数据相关，协助评估产品需求质量，从以下几方面考虑：

user case
初始user case量
新增user case量
变更user case量
是否遇到因需求阻塞后续流程进行等，涉及的user case量
上线后：
需要优化的业务user case量
技术定位

技术在各节点的关注内容如下：

设计规范

基本规范:
有迹可寻: 设计所反映的内容都能在需求文档中找到出处
15%~25%: 设计占用整体项目的时间
暴露: 本次设计的核心技术点必须暴露
5%: 如果后续实现中设计改动超过5%，必须通知之前设计评审参与人员，不能擅自修改核心设计，如果未通知，需要背负全责
新系统设计:
系统整体架构设计图
系统数据库设计
系统包图，核心类图
按需求得出的流程图，时序图，接口设计
系统涉及的中间件，设计和理由
系统异常设计
可扩展性设计
性能方面考虑
普通项目需求设计:
新增需求的流程图，时序图
新增需求的核心类图，详细接口设计
新增需求的异常设计
如果是原有改动，按照新增的要求进行相应图改动
如果涉及引入中间件，给出理由和设计
如果涉及表新增或变更，给出数据库表设计
如果是通用需求，需要展现可扩展性的设计
上线计划
牵扯老系统改造或者和数据相关风险较高的项目设计
对于风险较高项目，除了满足以上设计需求外，还需提供如下设计：
老系统原功能梳理，纳入评审环节
新老系统兼容设计
底层数据兼容设计
详细上线方案设计，最大可能保证平滑上线
详细的回滚方案
设计评审

评审原则:
一般需提前2天发出邮件，并在邮件中给出设计文档
参与者：项目全员，各个负责人
侧重点：设计的合理性以及是否和需求一一对应
评审关注点:
是否满足所有需求？
设计的完整性？
设计方案是否最优？有继续优化的可能么？
风险点如何处理？
是否有技术盲区以及难点，是否提前暴露？
是否存在异议，需要二次讨论的地方？如果后置，是否有风险？
所有设计是否透明化？
审查标准:
见设计规范
开发规范

满足集团编码规约
满足农村物流编码风格
系统owner必须知道当前系统下有哪些分支在进行开发
对于代码目录相关挪动，需要特别注意，svn有时候不会给出冲突提示，很容易造成代码误删
如果对外合作方较多的话，一定要把外部风险前置为第一优先级：
开发联调第一个接口
项目里程碑时，外部模块先行开发联调
时刻询问合作方最新进度，及时暴露风险，尽量将不可控因素搞定
codeReview规范

check编码是否满足阿里java编码规范
重点review编码是否和设计文档匹配，超过5%不一样，需要进行仔细评估，思路不同，风险需recheck
review分为两阶段：一是开发者之间交叉review, 之后再组内人员共同review
如果review发现系统个性化代码太多，或者有重复代码，无扩展性考虑，需要被打回重新修改
各系统owner要定期检查系统代码，保证设计和代码按照规范来执行，发现异常的要及时警告，代码质量从源头抓起
测试相关规范

核心业务逻辑必须要有单元测试
单元测试需要覆盖异常情况
需要逐步形成测试方法，维护完整的case, 根据不同情况得到不同的case checklist
按照需求对影响范围内的所有测试用例进行全量测试
需要有测试用例执行结果记录和展示，否则不予批准上线
发布评审

评审原则：
提前2天发出评审邮件，在邮件中给出评审文档，发布计划
参与者：项目全员，各个负责人
评审关注点：
产品是否验收通过？开发bug是否修复完成，codeReview是否通过？测试用例是否全量跑过？
配置相关，是否有提前变更？
如果有数据库变更，上线方案是否考虑清楚，是否有潜在风险？
如果发布有顺序和配置依赖，整体流程是如何，是否完整？
相应的监控是否已提前配置？或者另有计划？
回滚方案是否合理？异常处理都有考虑？
审查标准：
前提：测试用例全量通过，codeReview通过，已发现bug全部修复，产品验收通过
完整性：对照着设计文档，看相应变更的完整性，是否都有考虑
顺序：发布顺序，配置配合推演合理
回滚：回滚方案合理，同时异常处理都有考虑
发布规范

发布分类：
正常发布：每周二，四发布窗口，上一周的周五收集发布需求，如果后续再提出的需求，视紧急程度按照要求顺延，不在本次发布安排内
紧急发布：见流程中紧急发布一栏
项目发布：原则上项目发布都应遵循二四发布规则，如果实在不能发布，则申请非发布窗口项目发布（不必申请紧急发布）
发布前提：
通过评审，并且所有标准必须达到
发布后续观察

观察周期:
1天~1周: 小型项目
1周~2周: 老系统大型项目, 按照需求改动点，进行涉及流程观察验证
2周~1月: 新系统大型项目, 由于是全新搭建，需要观察验证整体需求流程
1周~1月: 涉及底层改造类项目, 由于是底层改造，同时涉及数据迁移和接口重构，相应的功能，数据都需观察验证，随时待命
总结会议:
见总结会议一栏
统计标准

codeReview:
代码实现与需求文档差异率，是否满足所提需求
代码实现与设计差异率
是否存在个性化代码
测试：
单元测试通过率 - 理论上提测前必须100%
测试用例通过率
bug数量
发布：
发布质量（包括相关配置项是否配置等）
有否回滚
上线观察：
线上bug数量
测试定位

测试在项目中起到的作用如下：

测试用例库: 大型项目，进行测试用例库的完善和补充，后续交接，逐步慢慢由开发同学进行补充
质量监督: 对于小型项目，监督开发自测用例的情况和结果
质量保证: 对于大型项目，测试需要参与，并对质量保证附有一定责任
测试用例评审

评审原则:
提前2天发出评审邮件，在邮件中给出用例列表文档
参与者：项目全员，各个owner负责人
评审关注点:
是否与需求case保持一致？（这就需要产品注重细节，将需求case一点一点指出）
是否覆盖需求的全部场景？
对于影响范围内的现有流程，是否有相应用例？
异常流程是否有对应用例？
审核标准:
100%: 所有需求case都必须有对应的测试用例（包括主流程和异常流程）
现有流程: 影响范围内的现有流程，必须有完整的回归测试用例
5%: 评审的测试用例和最终使用的用例差异率不能大于5%
项目总结会议

强制性: 小项目按需举行总结会议，大型项目必须举行总结会议，总结会议时间并不是项目一发布就开，而是在整体观察验证周期后
有始有终: 项目由产品驱动需求，也由产品开展总结
全员: 会议参与方包括参与项目整体人员，各个owner负责人
内容呈现:
项目实际参与资源
项目是否按需完成，里程碑目标是否实现
产品方面：所提需求是否全部完成，项目中涉及到哪些需求变更，需要罗列具体变更点和数量
技术方面：实现是否按照原有技术设计进行，是否有出入，如果有，罗列具体出入和数量
测试方面：测试质量报告，得出该项目整体需求质量和开发质量
在观察验证周期后，项目的实现是否达到预期需求效果，做出判断
未来基于该项目的深入挖掘，开发，未来蓝图
后续跟踪维护

线上问题(咨询/bug)：统一先由产品运营出面对接，解决不了，再咨询开发，开发每个小组按周出一个对外对接人，协助产品进行指导和问题排查
运营数据: 运营数据持续暴露，跟踪
记录: 线上bug 根据严重性和影响面决定是否紧急发布

本文来自其他网站，已经脱敏，如有违反其他规定，请联系删除。