一个完整的软件项目管理系统需要支撑需求管理、项目规划(里程碑、进度、版本发布、迭代、测试等)、需求拆解、任务管理、测试管理、缺陷追踪,以及项目生命周期内的文档管理
同时,项目协作平台提供看板作为可视化管理工具,使用看板的管理思想推动项目阶段工作,可视化项目工作,使团队目标统一,管理更加简明、工作容易执行。
项目协作平台提供以项目的方式组织研发过程,提供基于事务的管理流程,以PDCA的工作过程推进敏捷管理方式,同时兼容传统管理模式,提供从特性、计划、需求、执行、测试到效能分析以及文档的管理,以团队为人员管理及工作空间的分离,为组织提供研发全流程的组织管理平台。
在工作执行过程中涉及到不同的研发团队角色,项目协作平台内置以下8种角色:项目管理、产品、技术管理、开发、UI、测试管理、测试和配置管理。同时提供不同角色的权限配置,为您的团队配置满足您需求的权限。
无论一个软件开发项目的规模和重要性如何,规划对项目的成功都是至关重要的。软件项目通过里程碑计划、进度计划、发布计划为软件交付过程进行规划。
好的规划通过
为企业提供价值
估计和规划是重要的,但也是困难和容易出错的。项目早期给出的估计没有晚期给出的估计准确。不确定性锥形显示了这一逐渐细化的过程
交付物管理,上传及下载;
时间轴,当前项目进度;
自动更新里程碑状态。
甘特图、粒度切换,直观感受时间和进度。
表头设置,设置您关注的字段。
关联工作项,直观查看工作详情。
一个项目可能有不同的产品线,通过版本库建立不同的产品线,每个版本库下包含发布release版本计划,每个版本计划中,会规划不同的发布内容,从而增量发布产品特性,产生价值 。
工作项包括需求、任务和缺陷
特性、需求和任务的关系
1.通过对业务需求的分析,明确产品特性,找到产品价值,以价值大小来排列产品优先级、可以更好的为用户提供价值,以实现产品的价值。
2.产品特性是产品的一个特质,在特性下有对应的用户故事,即产品需求,通过需求支撑用户不同场景的使用,以需求来支撑特性的价值,每个需求都是可验证的,可交付的、完整的,可以在一个迭代完成的。
3.对需求进一步拆分,形成任务、任务要求能跟踪和更新日常进展,通常可以由单个人完成,工作量不超过20人时
将特性拆解成一个一个的需求——以特性划分需求,当然,一个大的需求可能涉及到多个特性,需要将需求拆分到每一个特性中去;
需求拆分到一个迭代可以完成的子需求——创建子工作项;
子需求可以拆解对应的任务——需求创建副本任务、关联任务
相似的子需求/子任务之间——克隆需求/任务
需求的错误交付——关联缺陷
附件管理——对应的文档或图片等说明
缺陷是指不符合最初定义的业务需求,除了错误编码外其他导致不符合最初定义的业务需求问题都属于缺陷范畴。
通过好的缺陷管理体系,时刻了解开发进度、保证开发质量,交出满意的工作单。
缺陷管理流程
状态说明:
待确认:测试人员新提的缺陷
修复中:开发人员修复问题
拒绝:开发人员认为不是问题,拒绝该缺陷
重复:开发人员认为与已存在的某个缺陷重复
挂起:开发人员认为是问题,但推迟修改
待验证:开发人员修改完成
已拒绝:测试人员同意该缺陷拒绝
验证通过:测试人员缺陷回归测试通过
验证不通过:测试人员缺陷回归测试验证不通过
已关闭:缺陷关闭
看板是一种项目管理工具,是一种最轻量的管理流程的方法
看板帮助团队实现工作流的可视化,一目了然了解工作项进度和流程
支持快速拖拽实现工作项状态的流转
测试用例是为了实施测试而向被测试系统提供的一组集合,这组集合包括:测试环境、操作步骤、测试数据、预期结果等要素
• 根据项目**——**特性**——**用例树状展开测试用例,最大限度发挥测试分析的灵活性与自由度
• 提供统一的模板,快速形成团队用例规范和指导
• 支持线下编写、批量导入
• 支持批量删除用例、选定特性下的批量删除
测试用例是贯穿了整个测试流程和项目研发流程的,用例也同时起着指导测试、保证质量度作用,因此用例至关重要。对于如何提高用例设计的质量,评审是必不可缺的一环。
测试计划是测试用例的集合,它描述了本次测试活动的对象、范围、方法、工作进度与预期结果。通常在完成编写测试用例后,使用测试计划进行逐项功能测试。
目录:已发布文档目录,结构化的文档结构在目录中树状展开
模板:项目文档模板,支持自定义模板,从模板创建文档
草稿箱:将文档保存至草稿箱,直至可发布
回收站:删除的文档在这里存储,方便找回。如确认不需要改文档,从回收站中彻底删除即可