【DEVOPS】zentao核心概念速览

最新推荐文章于 2024-06-07 12:56:43 发布

夫礼者

最新推荐文章于 2024-06-07 12:56:43 发布

阅读量887

点赞数

分类专栏： DevOps 禅道(zentao)二开文章标签：禅道 zentao

本文链接：https://blog.csdn.net/lqzkcx3/article/details/115968281

版权

DevOps 同时被 2 个专栏收录

60 篇文章 6 订阅

订阅专栏

禅道(zentao)二开

8 篇文章 0 订阅

订阅专栏

禅道开源版12.5.3。

0. 目录

1. 前言

在原本设想的DevOps推进计划中，笔者一直都在极力避免过早地将产品侧拉入到改革的进度中，并非不明白"以需求为抓手"的关键，只是对于需求管理为突破口的信心不足。

只是，很多时候事情的发展并不会按照你的预期进行，笔者过去几周一直在尝试以禅道为中心，重塑公司内部的需求管理/扭转流程，实现以需求的有序管理助推DevOps实施。

本文作为zentao的开篇介绍，意在对zentao中涉及的常见的核心概念做一个浏览，以期帮助读者快速建立对于zentao的全局了解以及各岗位在zentao中的职责和相关操作。

2. zentao简介

zentao官网上对自身的定位是"专业的协同管理软件"，实现产品经理、研发团队和测试团队的三权分立：

产品经理整理需求，
研发团队实现任务，
测试团队则保障质量。

在禅道中，所有的一切都是围绕产品展开的。产品是整个项目管理活动的核心。
4. 产品是需求方，决定做什么。
5. 项目是执行方，解决的是如何做的问题。
6. 而测试则是保障方，解决的是正确的做事情的问题。

接下来就让我们分别从产品侧，研发侧和测试侧分别对各自相关的常见核心概念进行介绍：

3. zentao核心概念

禅道版本为开源版本12.5.3。

3.1 产品侧

产品线。
a. 产品线作为产品的上一级概念，也是zentao中产品侧的最高级节点。
b. 产品线只是对产品进行一个简单的分类，没有其他的业务逻辑关系。
c. 举例：购房时候办证涉及到的"不动产登记"产品线。
产品
a. 在禅道中，所有的一切都是围绕产品展开的。产品是整个项目管理活动的核心。
b. 产品隶属于某条产品线。一条产品线可以拥有多个产品。
c. 举例： "不动产登记"产品线包含不动产登记软件1.0，2.0，3.0版本。
分支
a. 指代需要针对客户的自定义开发场景。
b. 这一概念在所谓的产品定制化开发的需求管理场景特别有用，能够清晰准确地呈现需求的来源。
c. 分支属于对于某个产品进行分类。一个产品可以拥有多个分支。
d. 举例：不动产登记软件1.0版本又分类为不动产登记软件1.0 - 地区A分支版，不动产登记软件1.0 - 地区B分支版等。
需求
a. 以上三个概念确定产品的层级结构，接下来就是最为关键的"用户需求"，整个研发流程绝大部分时间都是绕着它来进行的。
b. 禅道中“需求”对应的是scrum开发里面的“用户故事(user story)”。
c. 在编写需求描述时候，推荐采用模板：“作为一名< 某种类型的用户 >，我希望< 达成某些目的 >，这样可以< 开发的价值 >”。涵盖了角色，要做的事情，价值或者原因三元的需求描述才容易让团队中的各个岗位对齐认知，避免重复性劳动。
d. 需求属于某个产品。
e. 举例：需求M 属于不动产登记软件1.0 - 地区A分支版。
模块
a. 相当于对产品需求的一个分类。
b. 通过组织模块，可以让大家对产品有一个宏观的把握和认识，也方便对需求进行分类和整理。
c. 举例：需求M 属于模块K。
计划。
a. 产品需要做规划，才能有轻重缓急，才能正确的做事。
b. 对于产品经理自己而言，发布计划可以帮助他规划产品，制定发布的节奏，调整需求的优先级。
c. 对于公司其他部门的同事以及外部的客户而言，发布计划可以让他们知晓产品的进展情况，以便做好相应的安排。
d. 产品经理在创建计划之后，可以将需求关联到计划上。
e. 举例：需求M 属于计划Z。

3.2 研发侧

项目（开发计划）
a. 产品侧的计划属于思维层面的意向，接下来我们还需要借助项目来实际地将计划落地。
b. 禅道里面的项目其实对应的是敏捷开发里面的"迭代"的概念。
c. 项目是执行方，解决的是如何做的问题。
团队
a. 项目创建完毕，你需要指定由哪些人员来进行本次的项目冲刺。也就是将项目关联团队。
b. 除了将项目关联团队外，项目经理还需要为项目关联需求，进而确定项目冲刺相关的时间周期，投入资源，完成哪些需求。
任务
a. 产品经理录入的需求经常需要多个岗位来协同完成，例如某个需求可能同时需要进行原型设计，编码实现，测试验证等等环节。
b. 因此项目经理在确定需要本轮需要完成的需求之后，还需要进一步将单个需求根据实际情况细化为多个任务，进而分配给对应岗位的人来协同完成。
c. 任务分解的粒度越小越好，比如几个小时就可以完成。
d. 任务的分配最好是自由领取，这样可以大程度上调动大家的积极性。
版本
a. 当完成若干功能之后，就可以创建版本了。版本的概念在英文里面是build，可以对应到软件配置管理的范畴。
b. 这个版本主要的作用在于明确测试的范畴，方便测试人员和开发人员的互动，以及解决不同版本的发布和bug修复等问题。

每日站会
a. 在项目的推进过程中，需要进行信息的及时互通，规避重复性工作和理解不一致导致的返工。
b. 遵从以下几条原则：

 1. 每天固定时间召开。
 2. 项目团队成员站立在一起开会。
 3. 每个人讲述三件事情：昨天做了什么，今天计划做什么。有没有什么问题。
 4. 会议控制在15分钟之内结束。
 5. 站立会议不要试着解决问题，大家更多的是沟通互相的进度，而不是解决具体的问题。具体的问题，会后讨论。
 6. 非项目团队成员可以参加，但不能发言。

3.3 测试侧

测试单
a. 研发测所创建的"版本"为研发概念，研发还需要将版本转换为测试单来交付给测试，这一步在禅道中是通过创建测试单来完成的。
b. 这个测试单和项目里面创建的类型为“测试”的任务没有直接关联。
测试用例
a. 测试人员在接收到测试单之后，需要根据测试单所关联的需求和BUG编写相应的测试用例。
b. 测试用例编写完毕，测试人员按照测试用例执行相应的测试步骤并记录测试结果。
BUG
a. 上一步的测试用例执行失败，禅道在记录测试结果的同时会提供一个"转BUG"的选项，测试人员可以借助这个便捷操作快速提交BUG，将软件开发流程推进到下一个阶段。
b. 待研发人员解决完BUG之后，由项目经理创建新的版本关联这些BUG，进入下一轮测试。