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

项目管理方法-总结

概要

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

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

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

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

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

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

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

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

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

验收测试清单

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

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

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

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

需求各阶段管理

需求沟通

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

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

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

建立该需求的临时资料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

投入产出分析、结项

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

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

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

团队管理

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

“需求跟踪表”

工作量跟踪表

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

日常记要、临时任务

人员请假、加班记录

临时绩效记录

技术分享、学习

环境账号管理

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

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

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

晨会、周会等沟通方式

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

团队规范

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

详见目录：项目组规范

代码管理

“代码分支跟踪表”

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

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

数据库架构版本管理

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

测试数据库定时备份

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

git子项目管理

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

公共类、分层管理

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

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

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

基础的代码规范要求

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

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

提交测试要求

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

系统组成、应用列表

发布包版本

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

任务管理

任务分类

包括：

需求任务拆分

临时任务、问题处理

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

任务管理原则

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

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

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

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

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

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

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

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

团队协作：

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

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

任务安排与服从：

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

记录方式redminewiki

方便记录、关联详情是

方便层级管理是

方便跟踪工时是

操作简单是

redmine需求关联体系方案

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

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

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

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

redmine项目组任务管理

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

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

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

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

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

或配置不随子任务变化。

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

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

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

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

confluence任务跟踪方式

效果：

文档管理

推荐方式：

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

svn里按需求分文件夹，命名类似如下：

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

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

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

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

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

redmine

wikiwikisvn文档gitqc或redmine

各类工具的比较

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

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

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

文档管理word、excel

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

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

文件管理网盘

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

任务管理jira适合敏捷

任务管理redmine操作略复杂

任务管理禅道

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

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

wiki中文档结构

部门级技术分享管理

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

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

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