软件项目管理测试文档,软件项目管理具体方法体系示例

项目管理方法-总结

概要

项目经理的工作包括这些方面:

需求、团队日常、任务、文档。需求各阶段管理团队管理团队规范代码、开发任务管理文档管理文档-总结资料

需求分析大需求计划、工作量跟踪表开发版本、分支、子项目管理需求任务开发方案、功能点

开发人员请假、加班记录需求公共类、分层管理临时任务数据字典

测试绩效记录测试部署资料准备问题处理需求沟通记录

上线技术分享、学习发布代码走查,规范完善周期任务

验收日常记要、临时任务任务提交测试要求日常任务

运维文档系统组成、应用列表需求阶段时间点及汇总用户手册

投入产出分析、结项功能风格数据库版本

验收测试清单

需求管理:完成“需求”是核心目标,流程化、风险可控化是手段。

团队规范:项目经理需要整理出“团队规范”、书面化标准,以明确要求,避免反复口头传达要求。

任务管理:任务可跟进,是达成“需求”、项目正常运转的保障。

文档管理:需要引导明确要求,组织好文件存放的层级结构,以可持续的更新。 是项目长治久安的保障。

需求各阶段管理

需求沟通

评估需求是否达到可以分析的详细程度,是否外部达到启动条件,如果不能达到,可以拒绝花费时间分析。

细节工作可以下发,但项目经理要对需求内容整体都了解

将需求汇总到项目组的“需求跟踪表”中。

建立该需求的临时资料svn目录,如:“4.55精品商务经济座积分”,保存需求文档及后续文档。

立项

完成《开发方案》、wbs、流程图、样式设计(RP软件),示例:

后续重要沟通结论、识别的新问题,及时补充到《开发方案》或专有主题的文档。

避免单个开发人员总揽方案,而没有多人评审环节,这样容易出现功能设计风险问题。

《开发方案》中包含功能设计、风险点、待沟通问题、对接项目组及负责人及时间点、性能、可用性等的考虑。

将风险点加入项目组的“风险跟踪”中。

将开发、测试、上线时间点、对接时间点、uat测试时间等加入“需求里程碑跟踪”表。要求产品经理也要关注与其相关的时间点。

开发

开发人员对《开发方案》中不够详细的详细处理流程,使用易交流的方式补全。

完成srs,完成输入输出等详细约束、定义

代码分支开发,sql脚本、部署说明文档,按代码分支保存。

将分支名加入“代码分支跟踪表”

测试

测试人员梳理测试点,以达到理解一致。需要考虑上线后的验证方法、过程。有需要功能开发帮助测试验证的内容,提前提出。

使用工具记录、处理bug

预验收、培训

上线前需要及时组织产品经理、业务人员,对功能做uat测试,培训(立项时预约时间点)。可有效减少体验问题。

发布

准备上线发布步骤、清单等信息,准备线上验证点、步骤、时间点计划。

安排一人整体协调发布过程。

涉及外部联调,提前准备接口地址、账号等信息。

线上跟踪

上线后,一周内需要关注相关功能的错误日志、服务日志。有问题优先解决。

更新“代码分支跟踪表”

更新“线上服务配置信息汇总”,包括配置参数、日志关键字等。

将《开发方案》的功能点细则,合并到“业务规则”文档

更新“依赖的接口及汇总、依赖的接口及汇总”,包括接口、数据的外部项目组负责人、接口地址等信息。

新上线的项目,要更新“线上发布记录”

日常运维

项目上线后,可考虑加入系统的监控系统,如“数据量变化监控功能”

响应业务部门对功能的咨询

响应其它项目组对接口、业务的咨询

处理线上问题、bug

尽量及时处理旧问题,避免合并到新问题一起处理。

业务咨询的问题,及时补充到“业务规则”或“用户手册(单独空间)”。

其它注意点

某需求分拆多次上线的,要跟踪多次对应的时间点。

一个需求中,既有新功能,又有对原功能的修改时,要考虑修改原功能产生的风险大小,如果大的话,分拆上线是否可以减小风险。

修改多个原有功能时,也要考虑产生的风险大小,是否可以分拆上线,减少风险。因为分拆后,可以及时验证、关注该功能点的影响。

需求分期模板版本工时

分类1功能11版本110

功能12版本260

分类2功能21版本130版本1版本2工时

功能分类1功能1110

功能1260

功能分类2功能2130

总工时4060

投入产出分析、结项

项目的目的是产出效益。在可能的情况下,接收需求前分析投入产出,是否值得做。

在新项目上线初步稳定后,结项、评估实际投入产出效益。之后转为维护与优化项目。

大的版本变更需求,作为独立项目开启,评估投入产出效益。之后重新变为“维护与优化项目”。

团队管理

目标:团队高效高质完成任务,提升团队成员能力。

“需求跟踪表”

53954678_202003250034360387.png工作量跟踪表

基于任务的分配记录,汇总每个成员未来几个月所负责的任务。

53954678_202003250034360512.png

日常记要、临时任务

53954678_202003250034360668.png

人员请假、加班记录

临时绩效记录

技术分享、学习

环境账号管理

测试环境的服务器、数据库账号等,可考虑不同人不同账号权限、不对部分人公开账号。

团队动员、鼓舞、团建,等团队协作提高

寻找适当自己的方式,提高团队协作。

晨会、周会等沟通方式

使用晨会、周会、每天任务检查等方式,保持有效沟通和跟踪。

团队规范

项目经理需要整理出“团队规范”、书面化标准,以明确要求,避免反复口头传达要求。

详见目录:项目组规范

53954678_202003250034360777.png

代码管理

“代码分支跟踪表”

分支管理,避免分支、需求 被遗漏发布,所以需要分支命名规范、分支信息做记录。

分支命名:f_需求编号(4.58)_功能名

53954678_202003250034360965.png

数据库架构版本管理

数据库架构的版本变更,可以导出生成数据库的脚本,在git中跟踪变更。

测试数据库定时备份

测试、开发数据库,还可以考虑定时备份,避免人为误删除。

git子项目管理

不同子项目互相引用时,为了单个项目的代码量可控,宜对git项目进行拆分到相对独立的模块大小。

公共类、分层管理

多人合作开发,不可避免各有各的风格、沟通不及时。公共类、项目代码分层,需要指定一两个资深开发人员负责,其他人需要与他们沟通后,按要求放置。

负责人要把“公共类、分层管理”的逻辑形成文档。

代码规范,代码走查,规范完善

基础的代码规范要求

日常代码走查的制度,检查结果记录文档。

将走查到的突出问题,整理到规范要求并提供示例。

提交测试要求

提交测试前,要求开发自测、单元测试(视项目组制度)、代码走查,方可提交测试。

系统组成、应用列表

发布包版本

单应用的发布包(测试环境),也可以放单个git项目中,以方便提取发布包到线上。

任务管理

任务分类

包括:

需求任务拆分

临时任务、问题处理

总结、周期任务、日常任务

任务管理原则

任务责任制,被指派任务人,承担完成任务的主要责任。需要寻求他人支持时要讲明背景、详细信息、需要的支持内容,带着可选方案提出问题。

任务分配,要有记录可查,任务要求提前在项目组规范中说明。避免大家对任务的范围、质量要求理解不一致。

每天需要及时在redmine中登记工时在相应任务下。如同时做多个任务,可分别登记工时(注释中写工作内容)。同时更新完成百分比、状态。

需要拆分任务到一个个可以标记是否完成的“交付物任务包”,而不是都标记完成百分比,却没有一个可以完结的任务。

例如:拆分一个功能的任务为:开发完成(可提测)、文档、bug修复、部署

项目信息中,可查看所有工时登记

53954678_202003250034370230.png

53954678_202003250034370418.png

项目经理,可以视情况将任务细分到大小不同的粒度。成员可以对任务继续做细分,但不能新添同级任务。识别出新的任务时,应由项目经理创建同级任务。

项目经理每天关注“进行中的大任务的进度”、每个成员的工时填写情况。

团队协作:

项目团队作为一个整体,必须团结一致、同心协力,为实现项目目标而共同努力。在项目中,项目的成功是团队成功的基础,团队的成功又是个人成功的前提。因此每一位项目成员都必须以项目目标为重,以团队业绩为重,并为之付出努力。

当某些项目成员遇到困难时,应该充分发挥团队的力量,发扬互帮互助的精神共同解决问题。在项目团队中,每一位项目成员都有义务在力所能及的方位内,为其他项目成员提供帮助。

任务安排与服从:

在项目建设过程中,项目成员可以对项目经理的任务安排提出异议,但项目经理仍有最终决定权。对于项目经理最终决定的任务安排,项目成员应无条件地服从。

记录方式redminewiki

方便记录、关联详情是

方便层级管理是

方便跟踪工时是

操作简单是

redmine需求关联体系方案

53954678_202003250034370574.png

IT现有redmine体系 没有很好讲解设计原则,项目组可操作性差。

redmine项目,应以部门、项目组为管理主体,方便他们集中管理。

业务需求、IT产品需求、项目组版本任务,彼此关联。

年度计划,需要提前录入“IT需求”项目做跟踪管理 。

redmine项目组任务管理

项目组任务包括:需求工时、临时任务(线上bug、问题分析、待处理bug或优化、支持外部工时)、日常任务(日常任务、周期任务)。

某类临时任务,能提前识别并指派的,就归为日常任务。

如果使用redmine替代qc记录bug,则一个redmine项目记新需求工时、临时任务,另一个记bug跟踪。

53954678_202003250034370793.png

使用“跟踪任务”列(或“跟踪”=“任务跟踪”,推荐前一种方式),识别每个人在处理哪些任务。每个人同时在处理的任务数应在3~5个以内。“跟踪任务”另可加自定义属性“质量打分”(1~5分,用于绩效计算=计划工时*“质量打分”)

redmine任务管理有一个问题:添加子任务时,会把父任务的计划日期、计划工时覆盖掉,所以需要3个新属性来记录(当子任务尚未全创建完时)。

或配置不随子任务变化。

53954678_202003250034370980.png

需求的里程碑,也可以创建一条redmine任务(“跟踪”=“里程碑”),跟踪时间点。 相比不如在wiki里直观。

53954678_202003250034380199.png

开发阶段bug修复的任务如何编排

方式一(推荐):排在“测试”期间,按人建bug修复任务。发布也是一样,按人建任务。

方式二:开发任务工时包含bug修复工时,但计划完成时间仅指编码实现。

confluence任务跟踪方式

效果:

53954678_202003250034380434.png

文档管理

推荐方式:

wiki为主,svn为辅的方式管理文档。

svn里按需求分文件夹,命名类似如下:

53954678_202003250034380543.png

上线时,将svn目录中的文档拆分、合并到wiki中(开发方案、数据字典、线上服务信息、配置账号等)。

开发方案 分为两个:一个概要(功能点与规则,上线后合并到 业务规则)、另一个是详细设计(补充细节规则、实现逻辑,上线后合并到开发方案)

测试整理的文档,存在 测试文档

备选方案:某功能的”开发方案“,做为该功能的“业务规则”的子节点。

关于“业务规则”的书写,建议项目经理先做几次示范,以后的再分配给成员做,并自己检查修正后使用。任务文档补充文档代码测试、bug部署

redmine

wikiwikisvn文档gitqc或redmine

各类工具的比较

使用svn的话,操作繁琐,不方便频繁变更、高效交流。不建议组织一个很大的文件,在svn里频率更新。

使用wiki的话,部分文档类型不够强大,还是需要线下再处理一些文档(excel、word、project、思维导图、流程图等)。功能优点缺点

文档管理confluence方便分享、协作

文档管理word、excel

文件管理git分布式版本管理

文件管理svn适合修改频率低文档管理

文件管理网盘

文件管理共享目录快捷、临时用途访问限制不好控制

任务管理jira适合敏捷

任务管理redmine操作略复杂

任务管理禅道

任务管理confluence无法层级管理、工时登记

任务管理project、excel适合临时计划不利于长期汇总

53954678_202003250034380777.png

wiki中文档结构

53954678_202003250034380918.png

部门级技术分享管理

1.在”技术分享“下创建文档

2.为技术文档添加技术名词标签

3.在”技术分享“页面,可以按标签搜索文档

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值