记 Codes 重新定义 SaaS 模式开源免费研发项目管理平台——多事项闭环迭代的创新实现

来源: 投稿
作者: 豆蔻蔻子
2024-06-17 10:01:00

原计划本篇要写0代码接口测试,因最近询问Codes 迭代的人多,就先写多事项闭环迭代的创新实现。

    

1、简介

     Codes 重新定义 SaaS 模式 = 云端认证 + 程序及数据本地安装 + 不限功能 + 30 人免费 

     Codes  是一个 高效、简洁、轻量的一站式研发项目管理平台。包含需求管理,任务管理,测试管理,缺陷管理,自动化测试,cicd 等功能; Codes 帮助企业加速融合研发、测试、运维一体化进程。商业版不限功能,本地安装只限用户数,30 个用户免费 ; 社区版当前只开放了测试跟踪管理 (主要功能用例管理,缺陷管理),后续接着分离其他功能代码出来。

官网 https://icodes.work/

gitee 代码仓库 https://gitee.com/xiaoming1q/icodes

       2、背景

      市面上老一点的项目管理工具迭代下只含任务,其他一些新的项目管理工具迭代下包含了需求、任务和缺陷。迭代下只包含任务显然很不合理;只有需求、任务和缺陷,也是有问题的。

      一个研发周期的闭环:从需求-->到研发任务-->到测试-->到上线。一个迭代就是一个研发周期,迭代下的需求除了可分解为开发任务外,也应可分解为测试用例才方便测试左移;很多项目管理工具,迭代下虽然有需求和任务,但是他们是隔离的,不能从需求中拆分出任务,这也不符合一般的敏捷开发过程。

        3 多事项闭环迭代功能说明

        3.1  敏捷场景拆解为迭代的业务过程

       Codes 产品团队基于以上众所周知的认知,不走寻常路,从实际出发采用多事项闭环迭代的实现方式。敏捷开发的场景如下图所示:

       Codes 中把上述敏捷场景拆解为迭代,迭代作为一个完整的研发周期闭环,包含了从需求、到任务、到用例、到测试、到缺陷、到自动化测试到上线,并自动生成迭代总结并存档。

     敏捷场景拆解为迭代的业务过程:1从需求池中分配需求到迭代下 2在迭代下把研发把需求拆分为任务 3在开发拆解任务的同时,测试同学可进行需求测试并针对需求编写测试用例 4待开发同学完成研发任务提交测试后,测试同学执行测试用例,且执行不通过就提交缺陷 5在工作的过程中提交工时日报,自动计算迭代进度   迭代总结及复盘 7上线发布。

      3.2 Codes多事项闭环迭代功能说明

       如下图所示,迭代下有需求、任务、缺陷,测试用列,功能业务场景,接口场景,交付物和发布,场景内用例,人员分工。需求可分拆解为任务和分解为测试用例;功能业务场景为场景用例,是一组有执行顺序的用例集合;交付物为迭代中产出的各种文档;发布指上线时执行的一系列有先后顺序的事项,也可当一个发布的check list 来看,省得因粗心引发问题;人员分工,显示迭代下各人员事项分工及进度;工时趋势显示预估工时、实际工时和已用工时趋势。

     Codes 的迭代也为不完全按标准流程的场景提供了灵活性。比如,如果需求很简单可以不拆解为任务,直接把需求当任务来处理;另外如果没有需求,直接建任务也是可以的,这时在迭代下任务的TAB页中可以把不关联需求的任务分配到迭代下。迭代下任务TAB中的任务有两个来源,拆解需求的任务,以及手动分配到迭代下不关联需求的任务。

      3.3 为方便从不同维度来查看相关工作项,需求、任务,缺陷和用例都支持分组显示。

需求分组,可按负责人、创建人、来源、优先级、流程、需求分类、状态来分组以及以看板视图来显示。缺省为标准视图,也就是不分组的列表显示。

任务分组,可按负责人、任务类型、紧急程度、需求、状态来分组以及以看板视图来显示。

缺陷分组,可按待处理人、提交人,状态、等级、需求来分组以及以看板视图来显示。

      迭代下的缺陷可以是当前迭代中新提交的缺陷,也可能是需要当前迭代解决的存量缺陷。

 

用例分组,可按执行人、状态、类别、优先级和需求来分组显示。标准视图是缺省视图,就是不分组的列表。

 

      3.4 以迭代方式组织测试的特点

      传统是以测试计划来执行测试,一个计划下分配要执行的用例,难以体现出测试执行人员的分工以及不同执行人员之间的执行进度。一个执行人一个计划,多人就要建多个计划,非常不方便,同一个计划下如不同的人执行不同的用例只能口头来安排。

     Codes 中,把用例分配到迭代下后,再分配执行人,也就是在同一迭代下,各自有各自要执行的用例,然后可以查看到总进度也能看各自的进度。

分配用例到迭代

在当前迭代需求下,编写的用例自动分配到当前迭代下,当然也可以分配其他的用例到当前迭代下。

分配执行人

     可勾选要分配的用例,也可以左边的树上勾选相关需求,也可把当前查询到的用例全部分配(不用一一勾选)

执行用例

可快速执行,比如回归测试时,不需要查看用例明细后再执行。

也可点用例状态,在用例明细中执行

查看执行情况,有总进度也有各人各自的进度

      3.5 交付物

    迭代中的一切产出物可以在这里维护,且会自动放到项目文档下,在项目文档和迭代交付物中都可方便的查看迭代中所产出的文档。

     3.6 人员分工

     这里可以看迭代下各人员的事项安排及进度

       3.7 迭代工时趋势 

       可以查看迭预代估、实际及已用工时的趋势,Codes 中还可查看阶段以及项目的工时的趋势。

 

      3.8 迭代报告及发布

      迭代报告可导出来,且迭代设置为完成时自动在项目文档中存一份迭代总结。除总览的TAB外,其他TAB都是明细数据。

发布

主要作为上线前check list事项 ,确保上线不会因遗漏出问题。

 

3.9 采用多事项且闭环的迭代的好处

      以迭代为中心来组织研发工作,围绕需求拉通上下游所有研发活动。方便复盘,过程管理更通透和全面。那会不会带来混乱呢?肯定不会,虽然所有事项都在一个迭代下,但不同职位的人员进入迭代的执行时间是不同的。

      因迭代中包含了的所有事项,那么迭代的进度和工时更完整的。用例我们用执行成本而不是用例个数来计算工时,另外在Codes 工时日报中除把迭代下,需求,任务,缺陷,用例工时都记录下来外,其他事项,如开会等也计算到工时中,没有预估工作量的待办事项也通过日报中剩余工时记录下来,也就是说Codes 计算进度的数据是全面的,所以计算的进度更准确。

上图迭代进度还可下钻到人

       原本就浑然一体的工作形成闭环,打破使用者的割裂感:不需要文档在叧一个功能模块中集中维护,做到研发和测试不分家,实现统一管理。也解决了测试在DevOps快速迭代中的木桶效应,促进了研发、测试、运维一体化融合进程。

       更具灵活性,可闭环选代,也可非闭环迭代即和传统做法一样只有部分事项参与迭代。

 

     最后打个总结:Codes多事项闭环迭代一点技术门槛都没有,我们这样实现就是为了方便完整管理一个研发周期,可以按版本来规划迭代,也可按交付的时间周期来规划迭代。创新不是为了玩新奇,是为了解决问题,下一次我们来聊聊另一个创新点,也是很酷的功能,欲知后事如何,且看下回分解。匠心打磨,持续创新是Codes的产品基因

展开阅读全文
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
分享
返回顶部
顶部