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

1、背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 分配用例到迭代 

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

 分配执行人 

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

 执行用例 

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

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

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

2.5 交付物

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

2.6 人员分工

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

2.7 迭代工时趋势

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

2.8 迭代报告及发布

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

 发布 

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

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

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

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

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

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

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

3 最后打个总结：

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

有客官可能不知道 Codes 是什么，小 C 在这里最后补一句：

 Codes 重新定义 SaaS 模式的一站式研发管理平台 

 云端认证 + 程序及数据本地安装 + 不限功能 +30 人免费 

 扫码查看详细介绍