您现在的位置是：主页 > news > 网站设计理论/云seo
网站设计理论/云seo
admin2025/6/15 14:36:11【news】
简介网站设计理论,云seo,孝义做网站的公司,上海嘉定区网站建设公司软件研发过程是一个跨职能团队协作的过程，通常涉及项目线、产品线、技术线、质量保证线等各个职能部门或小组之间的协调和交互。随着团队成员的增多以及业务系统复杂性的提升，跨职能团队的协作和交互过程中信息的有效传递和维护，或者说“信息…
软件研发过程是一个跨职能团队协作的过程，通常涉及项目线、产品线、技术线、质量保证线等各个职能部门或小组之间的协调和交互。随着团队成员的增多以及业务系统复杂性的提升，跨职能团队的协作和交互过程中信息的有效传递和维护，或者说“信息的透明性”日益成为研发过程中的一个瓶颈，信息透明化是否完善很大程度上影响着研发过程的结果。本文从研发的范围和时间出发，介绍这两个特定领域在Redmine这一特定平台下的表现形式和透明化管理的操作方式，并探讨基于该平台的团队协作和流程。
一. 范围和时间基本概念
在经典项目管理知识领域中，项目管理通常追求以下三个方面的平衡：
软件行业中，“成本”这个概念普遍没有像传统行业那么直观，所以我们重点关注的是“范围”和“时间”。范围和时间同样涉及方方面面的内容，本小节从“信息的透明性”角度出发，关注如何剖析信息透明在这两个领域之中的表现形式以及如何对这些表现形式进行抽象以便能够将其映射到实际的工作流程中。
1. 范围的透明化
范围的信息透明通常采用的手段就是两个字：分解。项目管理中“WBS”就是如何进行范围分解的有效手段，当然分解的方式和结果也是根据组织会有所不同，我们可以采用需求(Requirement)->模块(Module)->功能(Function)->活动(Activity)分四级对范围进行分解，参考下图(注意下图中功能与活动之间的对应关系可以是1对1，即功能不需要再分解就可以作为活动；也可以是1对多，及功能需要再次分解才能成为活动)：
按照分解的结果，范围的最底层表现形式是活动，范围最终由一系列的活动构成，这就需要我们对活动进行剖析，看看针对一个活动我们需要如何把控。个人认为活动有如下主要特性：
- 类型：活动的类别，如Feature(面向交付的功能)、Task(面向开发的任务)、Bug(影响交付的缺陷)、Defect(不影响交付的缺陷)等
- 主题：活动的主题，是具体活动而定
- 状态：活动所处的状态，可以有新建、进行中、已解决、已关闭等
- 优先级：活动的优先级，根据项目线/产品线的需求而定，通常包含低、普通、高、紧急等
- 责任人：活动的指派者，即需要完成该活动的人
- 完成时间：活动需要完成的时间
2. 时间的透明化
时间的透明化相对没有统一的模式，个人认为“分版本”是时间透明化的有效手段。通过项目的阶段(Phase)和对应的计划(Schedule)结合工作的开展顺序(Order)确定工作版本(Version)，这样就把整个研发过程从时间上分成了一系列版本的组合。那版本从何而来？版本从以下版本等式而来：
一定时间 + 一定活动 = 版本
二. Redmine上的范围和时间
Redmine是一个支持多平台的面向Web的开源项目管理平台，作为研发管理平台而言功能也是比较强大，本文只介绍其中一小部分功能，大家可以参考其官方网站。
Redmine上基本工作单元称之为“Issue”，一个Issue的实例如下：
我们把Issue与范围透明化中的活动做一个对应，我们可以看到一个活动的主要属性都能在Redmine的Issue中找到对应的元素：
- 主题：对应活动中的主题
- 跟踪：英文为Tracker，对应活动中的类型
- 状态：对应活动中的状态
- 优先级：对应活动中的优先级
- 指派给：对应活动中的责任人
- 完成时间：对应活动中的完成时间
有了Issue，我们再分别从范围和时间上对Redmine的特性进行进一步描述：
1. Redmine上的范围要素
Redmine上有两个要素与范围透明化有关，分别是：
- 类别(Category)：类别一方面可以对应范围分解中的模块，另一方面也可以对某些有关系性的活动进行分类管理，这在信息查询和统计非常有用，后文会再展开讨论。下面是使用类别的实例：
- Issue：上文讲到功能可以分解成若干个活动，也可以直接映射成一个活动，这取决与该功能的特性与大小，无论哪种情况，Issue代表的就是一个可以让研发人员直接开展工作的活动。Issue通过“跟踪“属性来区分这种活动的类型。下面是使用“跟踪“的实例：
关于“跟踪“，我们根据范围分解结合与QA部门的协作抽象成以下四种类型：
- Feature：即直接面向测试和交付的活动，如UED设计、表现端开发等都是从用户角度出发进行验证和确定的工作
- Task：即面向开发的活动，如数据库设计、服务层接口提供等从技术角度出发的工作，测试通常不介入也无法接入
- Bug：直接影响交付的系统缺陷，如果版本中存在Bug，则该版本就不可以发布
- Defect：缺陷但不影响交付的系统缺陷，其存在与否不影响版本的发布性
2. Redmine上的时间要素
Redmine上有三个要素与时间透明化有关，分别是：- 目标版本：目标版本对应时间分解中的版本。如果我们把阶段和计划也看出一个大版本的话，也可以用目标版本进行映射，如：
- 问题的优先级：通过优先级把握时间分解中的顺序，如：
- 问题的开始完成时间：具体时间点的管理，如：
三. Redmine操作
新建/更新Issue使用的是同一操作界面，确保以下属性进行正确设置：
- 跟踪：*必填项，不同角色根据问题类型确定
- 主题：*必填项，清晰简洁
- 描述：图文并茂；附件；使用格式
- 优先级：视问题紧急程度情况而定，默认为普通
- 指派给：*必填项，不能确定则分配给自己
- 类别：多数情况需设置，不能确认设为空
- 目标版本：多数情况需设置，不能确定设为None
- 完成时间：多数情况下需要设置，不能确认设为空
Redmine的查询功能勘称强大，通过组合“过滤器”、“选项”和“分组”等多种条件能够形成多维度的查询结果：
常用的查询视图包括看按类别查询、按版本查询、按指派人分组等，具体不再截图一一展开，大家可根据需要灵活设置查询条件。这些视图在协作交流和过程控制中充当团队的信息辐射器，对“信息透明性”起到推动作用。
对研发主管或产品经理等管理角色而言，新建类别、新建问题和新建/更新版本等操作也是日程工作中的一部分，操作方式也非常简单，不展开。
