|
网管产品部iposs日常管理规范
文档变更记录
审核
批准
目录
1 引言本流程规范以《DMP开发流程操作手册.doc》为指南，确定日常工作流程规范。加强各项目管理，通过制定相关措施，来提高日常工作效率。 1.1 Iposs组织结构| 层次 | 人员 | 主要职责 | | 组长 | | | | 副组长 | | | | 主要开发人员 | 刘博语、胡兵、刘冬冬、胡超、薛安南、罗功明、葛明久 | | | 一般开发人员 | 任一、韩大鹏、彭达程、张露梅、朱晓兵、王斌、周季剑宇、刘海、张盼盼 | | | | | | 实习生 | | 一般性功能测试，一些常用的统计,mib分析（张盼盼安排） |
2 预评审节点这个是在现场维护人员提交dmp流程之前需要做的。需要研发和现场一起沟通，在达成一致的基础上，才能提交dmp系统。这部分主要由蔡茂南、张亮亮负责。后期需要把副组长也添加进来。 1. 研发侧主要负责人：蔡茂南、张亮亮（接收人，一两小时内需要响应）。 2. 评估的时候需要预先梳理清楚：当前需求的背景、用来解决什么问题的、是否是在需要验收的项目范围内的.研发人员需要明确：当前功能是否合理，合理的话是否已经开发过类似的，能否复用。 3 评审节点3.1 正常dmp评审评审负责人（会议主持者）：蔡茂南、黄磊、赵立阳、张亮亮 评审时间：暂定周四的下午进行需求评审。每周三由专门一个人（暂定张露梅）把需求统一导出来，周知给各评审负责人。 评审参加人员：各组组长、副组长。小的功能可以增加开发负责人，方便直接分配。 评审后跟踪：iposs项目组的svn中有工作计划的目录，评审后的计划文档统一放在这个目录，用来进行任务跟踪。 Svn：【https://10.21.20.140:18080/svn/net_iposs/doc/工作计划】 评审后的产物： 1. 所有当前评审的需求表格。指定任务负责人。 2. 详细设计文档。（各dmp需求的主要负责人。小需求可以当场直接分派给开发人员。大需求需要指定负责人，并且需要负责人进行详细设计文档的编写）。小需求前后台统一，也要做一个分析，改进的思路（主要由开发者提供，负责人审核一下）。制定一个统一的模板。 3.2 特殊紧急dmp评审需要甄别是否确实为特殊紧急的需求，如果不是，放到下期评审。确定为特殊紧急的，指定负责人（各组组长）,同时要求现场提dmp。。当前需求添加到上期评审的文档中，处理流程同【3.2.1】.研发人员不负责直接对应项目组问题。 4 需求分类处理各项目现场负责人所有的功能需求、问题对应都需要有邮件发出。统一发送给研发负责人。研发侧接口人（蔡茂南、张亮亮）。 1. 【大型需求】新的比较核心的功能（比如贵州电信端到端系统、山西联通展示平台），这类走【大型需求】流程。 2. 【中等需求】重要的功能(比如新疆电信lincese利用率统计报表、贵州电信tomcat最新版本升级)，这类走【中型需求】流程。 3. 【紧急小需求】一般性的功能、平时bug、问题，可以直接通过邮件指定开发负责人（主要开发人员、一般性开发人员）。提高效率。需要提交dmp。（外包人员） 4. 【普通小需求】一般性的功能、平时bug、问题，日常巡检、日志跟踪的，由组长（副组长）编写出相关手册，定量后交给实习生执行。（外包人员，实习生） 4.1 大型需求主要是研发时间大于3人周。这些需求往往是比较重要的，并且需要重点去关注的。主要由iposs组织结构中的组长、副组长担当。 4.1.1 负责人素质要求1. 责任心强 2. 有良好的沟通能力和理解能力 3. 良好的软件开发能力 这部分主要由核心人员组成(研发组长、副组长)。 4.1.2 评审方式支持部牵头，和产品线联合评审，完善需求、业务流程、数据流程、接口范围，确定设计人员和大概开发完成时间，设计人员参与评审 4.1.3 制定开发计划研发组长、副组长需要按照功能分解编排表格，制定具体的开发计划。这部分大概要在一周内完成。 同时需要有的产物： 1. 整体功能的分解一览，以及相关的责任人。 2. 分解后相关功能的详细设计书。 3. 需要针对详细设计书进行评审，评审完成后直接交给相关开发责任人。 4. 梳理DMP，使功能和代码相互对应，开发以前确保录入dmp。 4.1.4 详细设计（详细设计文档必须）可以是sql，也可以是表格，只要能把功能描述清楚就行。这部分主要由组长、副组长完成。 重要需求的详细设计要求(必须有)： 1. 数据库结构的设计,要有必要的sql描述。 2. 要有必要的流程说明。 3. 至少2张图，字数多余1000字。 4.1.5 组织会议设计负责人需要组织评审会议，开发者必须参加。刚开始组长必须参加。每次评审视具体功能大小安排开会时长，注意控制时间。 产物：开发负责人、开始时间、结束时间。会议记录。 组长组织每天一次站立会议（如果组长不在，副组长负责组织），每周一次周会（暂定为周五上午）。除站立会议外，其它会议要求必须有会议记录，会议后对应功能的责任人必须要跟踪结果。 每三天一个进度汇报。 4.1.6 开发这部分主要是主要开发人员、一般性开发人员来完成。 必须具备的产物： 1. 功能自测测试文档。页面功能必须要有相关的测试截图，应用程序必须要有相关的日志以及表数据截图。 2. 升级文档。安排各开发人员交叉升级别人的功能。代码根据升级文档统一从svn提取。 3. 有测试数据的情况下，需要自己准备测试数据的入库脚本。 必须要有结果性邮件，表示当前功能已经完成。 4.1.7 测试以后测试人员统一由研发侧人员担当，主要由外包和实习生来完成。主要内容包括： 1. 按照开发节点提交的升级文档，重新取svn库代码进行升级。 2. 按照测试文档进行功能验证。 4.1.8 定时发送周报暂定每周2、周四各发送一次。 4.1.9 结果跟踪主要由实习生、外包人员针对功能进行测试，同时生成测试文档。最后项目现场还必须有邮件确认结果。 4.2 中型需求研发时间大于1人日小于3人周。这部分主要由副组长担当。 4.2.1 负责人素质要求副组长，较核心的员工。 1. 责任心较强 2. 有良好的沟通能力和理解能力 3. 良好的软件开发能力 4.2.2 评审方式支持部内部1日内组织评审，并电话与模块负责人沟通、确认。 4.2.3 制定计划副组长需要按照功能分解编排表格，制定具体的开发计划。这部分大概要在两天内完成。 同时需要有的产物： 1. 整体功能的分解一览，以及相关的责任人。 2. 分解后相关功能的详细设计书。 3. 现场接收客户需求，提交需求单，需求入dmp系统。 4.2.4 详细设计（必须有）这部分主要由组长、副组长完成。 重要需求的详细设计要求(必须有)： 1. 数据库结构的设计,要有必要的sql描述。 2. 要有必要的流程说明。 3. 至少2张图，字数多余1000字。 4.2.5 组织会议负责人需要组织会议，参会的人员主要是主要开发人员。主要产物：会议记录。同时需要有邮件确认进度。会议后对应功能的责任人必须要跟踪结果 4.2.6 开发这部分主要是主要开发人员、一般性开发人员来完成。 必须具备的产物： 1. 功能自测测试文档。页面功能必须要有相关的测试截图，应用程序必须要有相关的日志以及表数据截图。 2. 升级文档。安排各开发人员交叉升级别人的功能。代码根据升级文档统一从svn提取。 3. 有测试数据的情况下，需要自己准备测试数据的入库脚本。 必须要有结果性邮件，表示当前功能已经完成。 4.2.7 测试以后测试人员统一由研发侧人员担当，主要由外包和实习生来完成。主要内容包括： 1. 按照开发节点提交的升级文档，重新取svn库代码进行升级。 2. 按照测试文档进行功能验证。 4.2.8 结果跟踪主要由实习生、外包人员针对功能进行测试，同时生成测试文档。最后项目现场还必须有邮件确认结果。 4.3 小需求4.3.1 紧急小需求4.3.1.1 定义现场接收客户需求，通过系统了解判断，该需求很容易实现，并且紧急，接收客户需求后当日以邮件形式发出. 4.3.1.2 制定开发计划模块负责人接收需求后，1小时内确认属于小需求（需求没有问题，工作量在1天内）、邮件确认。录入dmp后，安排开发人员于2日内开发测试完毕。这部分直接指派给开发人员，不需要有详细设计。按照小需求的设计分析文档模板进行任务的安排，保证java、c++开发的统一性.需求需要书写相关的开发思路，小需求需要书写文档进行阐述，改动地点需要说明和记录。零散性需求，需要进行记录，思路说明，录入svn目录。 4.3.1.3 开发这部分主要由一般性开发人员来完成。 必须具备的产物： 1. 功能自测测试文档。页面功能必须要有相关的测试截图，应用程序必须要有相关的日志以及表数据截图。 2. 升级文档。安排各开发人员交叉升级别人的功能。代码根据升级文档统一从svn提取。 3. 有测试数据的情况下，需要自己准备测试数据的入库脚本。 4.3.1.4 结果跟踪现场当面确认，以普通需求进行完成时间评估。升级前必须验证、测试，必须追求效率,及时维护需求记录表.结果跟踪。这部分主要由外包和实习生来完成。 4.3.2 普通小需求4.3.2.1 定义研发时间小于1人日，并且功能不复杂的需求。 4.3.2.2 制定开发计划现场接收客户需求，通过系统了解判断，该需求很容易实现，但不紧急，接收客户需求后当日以邮件形式发出. 评审组1小时内快速评审，通过，则发给研发人员进行开发。不需要进行详细设计。按照小需求的设计分析文档模板进行任务的安排，保证java、c++开发的统一性.需求需要书写相关的开发思路，小需求需要书写文档进行阐述，改动地点需要说明和记录。零散性需求，需要进行记录，思路说明，录入svn目录。 4.3.2.3 开发这部分主要由一般性开发人员来完成。 必须具备的产物： 1. 功能自测测试文档。页面功能必须要有相关的测试截图，应用程序必须要有相关的日志以及表数据截图。 2. 升级文档。安排各开发人员交叉升级别人的功能。代码根据升级文档统一从svn提取。 3. 有测试数据的情况下，需要自己准备测试数据的入库脚本。 4.3.2.4 结果跟踪现场当面确认，以普通需求进行完成时间评估。升级前必须验证、测试，必须追求效率,及时维护需求记录表.结果跟踪这部分主要由实习生或者外包来做。 5 日常纪律管理规范5.1 加强日常纪律1. 考勤：要求各组员9点之前到岗。 2. 9点左右进行站立会议。 3. 每周四下班前要发周报。 5.2 Java开发规范要求学习【网管产品部java开发指导规范.doc】。 Svn：https://10.21.20.140:18080/svn/net_iposs/doc/规范文档 【网管产品部java开发指导规范.doc】 6 代码自动构建（王总提出来的）6.1 在公司部署每个省份构建代码。目前暂定2个库，以江苏电信为例。 1. 把江苏电信现网环境的代码拉下来，放到公司项目库。原有的class代码保留。 2. 技术组协助在公司的环境上将项目拉起来。 3. 以后所有涉及到江苏电信的功能，统一将代码更新到公司项目库。定期执行自动构建。 6.2 坚持走dmp，交叉进行测试。目前张盼盼带领实习生进行专业测试。 6.3 Iposs组专门找个负责人负责进度的跟踪。目前进度比较迟缓。（暂定胡兵），协调人员部署。7 代码管理7.1 新增功能的代码要保证版本。7.2 原来的代码查漏补缺，增量调整。8 升级规范根据不同的项目组，统一梳理各省份的开发环境。必须要有测试环境、正式环境。制定一个具体的升级规范文档。 项目组进行升级，现场维护人员升级，研发侧提供升级文档，明确人员分工，责任进行分工。 产物： 1. 各省份项目环境部署路径（正式环境、测试环境） 2. 明确现场和开发的职责。哪些是由现场人员进行升级，哪些由开发人员进行升级 3. 明确每次升级之后，添加上后续各自需要跟踪的内容 9 附录9.1 Dmp流程图
| 
发表于 2017-12-14 18:33:04