makeflow-logo-for-square.svg 官方网站 | 目录


这里我们将以一个普通的需求为例,在产品研发的过程中,从一个需求的产生到最终被实现在 Makeflow 中会经过什么样的步骤,以及任务是如何在不同的同事间流转和执行的。


假如目前的场景是:研发团队正在研发 产品A

研发团队中的成员分别有:小软(软件开发1号),小开(软件开发2号),小产(产品经理),小项(项目负责人),小优(UI设计师)等。

image.png


一、需求管理

1. 创建需求

小软在 4 月 1 日这一天认为我们的 产品A 已经基本开发完善,现在可以设计并开发一个产品的官方网站,于是他在 Makeflow 中的 产品A 团队下建立了一个流程为需求的任务,并打上了「功能」和「未安排」的标签,以提出一个新的需求:产品官网。

Kapture 2020-04-03 at 17.35.37.gif


2. 核对需求

小软任务分配给了产品经理小产,他在接受任务后开始了节点「描述」并逐步执行流程,在任务的描述中补充好了官网的具体需求,然后在任务右侧频道中上传了官网原型图等相关资源。描述节点执行完成,因为他将「需求评审」角色分配给了项目负责人小项。此时任务便流转到了项目负责人的工作台。

Kapture 2020-04-03 at 17.47.10.gif


3. 确认优先级

项目负责人接受评审节点,与同事们沟通后认为这个任务应该尽早完成,并加上了「中」优先级的标签,并通过了「评审」节点。

Kapture 2020-04-03 at 17.52.06.gif




在一段时间后,上个迭代的任务都完成了,进入了下一个新的迭代。在开始之前,小软小产以及小项坐在了一起打开 Makeflow 的「需求管理」概览,准备确定和分配下个迭代需要实现的需求。


4. 需求管理概览

小项在「需求管理」概览中还根据优先级标签新建了(优先/普通/备忘)列,这样就能在每次新的迭代开始前分配任务时能够按照优先级来更加高效的筛选需要提前实现的需求:

image.png


5. 需求分配

在需求管理概览的看板视图中,大家浏览到到了需求任务产品官网,经过讨论决定在这一次迭代实现这个需求,于是小产为任务添加了「迭代2」标签,小产开始了「实现」节点,并在该节点通过子任务模版的功能创建了流程分别为「设计」和「开发」的两个子任务,分配给了对应了开发和设计的同事:

Kapture 2020-04-03 at 18.06.08.gif




讨论结束以后就意味着新的迭代开始了,大家都积极的开始做自己手头的新任务。


6. 设计任务

小优发现经过刚才的需求分配,他的工作台里多出了许多任务,其中就包含了「官网设计」,他对这个比较感兴趣,于是马上开始了这个任务,同时也开始了「设计」节点。然后把「官网开发」添加成了后续任务。

Kapture 2020-04-03 at 18.14.59.gif


在设计稿初步完成以后,小优将设计稿截图粘贴到了任务描述中,完成了设计节点,并把「产品核对」节点分配给了小产,把「开发核对」节点分配给了小开。

Kapture 2020-04-03 at 18.16.01.gif


小开接受节点并查看设计稿后觉得稿子十分完美,涵盖了所有不同状态。通过了审批。

Kapture 2020-04-03 at 18.21.49.gif


小产接受节点并查看设计高后,发现设计稿有一处文案欠妥,于是点击了退回审批,并在备注中添加了修正后的文案,选中了创建自定义检查项,将任务退回至「设计」节点。

Kapture 2020-04-03 at 18.25.06.gif


小优在发现任务被退回后马上根据备注修改了文案,并重新上传了设计稿截图,勾选了检查项,完成节点。

Kapture 2020-04-03 at 18.28.13.gif


此时任务重新到了小产的工作台,小产这次觉得设计稿没有任何问题了,于是通过了审批。

Kapture 2020-04-03 at 18.29.53.gif


于是小优开始了设计的最后一个节点「标注」,在挨个完成流程项后,他在表单中上传了设计稿,并完成了整个任务。

Kapture 2020-04-03 at 18.32.14.gif


产品官网需求的设计任务到这里就告一段落了,下面轮到了软件开发同学,小开上场。


7. 开发任务

小开开始了「官网开发」的任务,同时也开始了「开发」的节点,逐个完成流程项,在本地创建了 git 分支,然后开发完成后提交了 MR 到公司的 Gitlab,把 MR 的链接也粘贴到了任务描述中,填写了实现情况表单。

Kapture 2020-04-03 at 18.40.26.gif


随后把数据评审和代码评审节点都分配给了小软,小软经过 Code review 后,发现代码有一些小问题需要修改。于是退回了「代码评审」节点。

Kapture 2020-04-03 at 18.44.33.gif


小开重新修改代码,解决了 Code review,完成节点。

Kapture 2020-04-03 at 18.45.42.gif


这时小软便通过了审批,同意了 MR 的合并。

Kapture 2020-04-03 at 18.47.16.gif


8. 需求任务

小产在随时跟进「产品官网」这个任务的进度,这时他发现设计和开发任务都已经完成。于是完成了开发节点。

Kapture 2020-04-03 at 18.48.18.gif


此时到了项目负责人小项的交付节点,小项在确认无误后,确认了实现与预期相同。

Kapture 2020-04-03 at 18.49.42.gif

此时整个需求就算完成了。


9. 记录工时

为了大家能够更准确的在以后的任务分配中预估自己的工时,以及让项目管理者能更详细的了解每个人在每个任务上所花费的时间,小项会要求每位员工记录下任务的工时。

小开在完成任务后,估算了一下自己花费的时间,添加了开发官网所用的工时:

Kapture 2020-04-03 at 18.54.49.gif


同样也可以在任务开始时使用自动计时功能。


二、迭代管理

1. 迭代看板

在本次迭代的「迭代2」的概览中,小项为了更好的管理本次迭代的任务,在原有看板中(待办/正在进行/已完成)列的基础上还创建了(紧急待办/缺陷)列,这些列都是通过对应的(高优先级/缺陷)标签来进行筛选的。您可以根据自己的需要创建各种看板列。

image.png

如此一来就可以清晰的看到在这次迭代有那些紧急的任务以及缺陷需要被尽快实现或修复的,小项就可以随时抓紧跟进这些任务。


2. 迭代报表

把「迭代2」的概览切换到报表视图后,小项重新布局了一下报表,他每天可以在这里看到这个迭代所有任务的状态,根据时间来灵活调整跟踪整个迭代的进度。

image.png


三、缺陷管理

在迭代之前的任务排期过程中大多数情况都不能刚好把一个迭代的工时全部排满,有一些同时可能在做完这个迭代需求的任务还有剩余时间,这时就可以来到「缺陷管理」概览,这里可以看到筛选条件内的所有缺陷任务,来寻找优先级较高的缺陷需求,就可以经过流程确认需要实现后开始修复缺陷。如果没有缺陷的话同样也可到「需求管理」中去寻找其他的需求。


在「缺陷管理」概览中,同样还可以通过之前的方式来进行优先级列的划分。如果缺陷任务较多,还可通过右侧的临时筛选按钮来添加不同的筛选条件,以进行更加精细的筛选查看。

image.png


四、工时统计

在每天的工作或是整个迭代结束以后,团队成员都可以进入工时页面查看自己的工时记录情况。同时项目负责人小项也能够在这里明确的看到各位员工的工时,进而可以更好的在下次迭代作出合理的工作安排。

image.png