4步看板法,顺畅、高质量地交付有效价值

本文涉及的产品
云效 DevOps 流水线,基础版人数 不受限
云效 DevOps 项目协作,基础版人数 不受限
云效 DevOps 测试管理,基础版人数 不受限
简介: 团队应用看板方法的目标:顺畅、高质量地交付有效价值,看板的设计需要服务于这一目标,所以看板的设计,要真实和清晰的反映团队协作交付价值的过程,做到体现价值、反映协作和暴露问题。

团队应用看板方法的目标:顺畅、高质量地交付有效价值,看板的设计需要服务于这一目标,所以看板的设计,要真实和清晰的反映团队协作交付价值的过程,做到体现价值、反映协作和暴露问题。


作者:舍卫|阿里巴巴集团技术专家


看板设计可分四个步骤进行:

1、分析价值流动过程(工作流的分析)

2、选取可视化设计元素

3、用看板建模价值流动过程

4、如何在云效上配置工作流和看板

1、分析价值流动过程

分析价值流动过程是看板设计的基础。为了分析价值流,需要识别团队交付的价值类型,一般团队交付的价值类型包括业务需求、关联需求、改进类需求和其他任务,而往往业务需求占团队工作的比重比较大,这里围绕业务需求来设计工作流。

如下图所示,首先要确定的是价值流动所经历的主要工作步骤,如分析、开发、测试等,在图中用绿色方框表示;在这些步骤之间可能会发现明显的交接或等待,如计划后等待开始实现,开发完成后向测试移交等,在图中用红色方框表示。等待环节虽然没有具体的工作,却也占用了价值流动的时间,并可能产生积压,也需要识别出来。

2、选取可视化设计元素

看板设计使用可视化元素建模和反映价值流动过程。

队列

用户需求在某个状态停留会形成队列。停留的原因有两种,第一是工作正在被处理,如开发中和测试中等;第二是等待进入下一个环节,如开发完成和等待验收等。对应的,看板上的列也分为工作列和等待列。

如下图,典型情况下,看板上的工作列和等待列交替出现,需求从左至右流经各个列。

列的划分可细可粗,细的譬如可以把开发阶段分成设计、编码、自测和评审等,粗的譬如合并开发和测试阶段,统称为实现阶段。

具体细化到哪一个级别,依赖于两点:其一,工作是否会改阶段显著停留,其二,使用者是否需要特别关注这些阶段。

另一个问题是从哪个阶段开始,到哪个阶段结束。理论上,端到端的看板应该从用户的问题开始,到用户的问题被解决结束,形成业务闭环。而实际应用中,团队可以从自己能影响到的局部流程开始,并随着时间的推移,再寻求向上游和下游延伸,以促进整个组织的协作和需求端到端的顺畅流动。

以阿里内部某全功能研发团队的实践为例,看板的起始阶段是”已选择”,正常终止状态是”已发布“

确定了看板的起止阶段后,就可以根据团队的情况设置中间的各阶段了。

工作项

在看板上流动的基本单元包括业务需求、关联需求、改进类需求和其他任务,这里的其他任务一般包含开发任务和测试过程中发现的缺陷,所有业务需求、开发任务和缺陷都会在看板上进行流动。

3、用看板建模价值流动

在前面两步的基础上,我们可以设计团队的看板了,看板的设计过程是综合选取价值流动过程和可视化元素,即可建立可视化的看板。

如下图所示,是在云效上建立的看板,需求的阶段包括待处理(需求池)、已选择、分析中、就绪(待开发)、开发中、待测试、测试中、待发布和已发布

这里有两个阶段需要特别说明一下:

已选择:由业务方和开发团队代表共同完成,清晰要解决的问题和要达成的目标后,并通过可行性分析,按优先级放入已选择队列。

就绪(待开发):就绪队列在研发团队正式开始开发之前,是研发团队的输入队列,其意思是需求已准备好了,处于可以开始开发的状态,比如:用户的需求已清晰,团队理解了用户的需求,相关的依赖和关联关系已经确认等。就绪队列也是研发团队与其上游产品团队的交接点,是看板系统设计的必选项。


4、如何用云效配置看板,参考阅读

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
SVN版本控制系统
SVN是现在软件开发之中的主流软件版本控制工具,在工作之中利用SVN可以有效的解决多人开发的代码管理问题,本课程将为读者讲解SVN服务器的配置以及基于MyEclipse的SVN客户端插件的配置与使用,并且在讲解之中着重讲解了冲突的产生于解决。
相关文章
测试闭环
一、需求评审 1.需求评审的目的 明确功能优先级,评审业务流程设计的合理性,评估技术可行性。 2.需求评审中注意事项 a)提前了解产品需求,明确核心流程、功能结构 b)评审过程中不避免乏味,时间越长越容易分心,所以先了解重点模块,循序渐进 c)评审中遇到争议点,避免发散讨论,引导大家快速决策,明确沟通,明确产品拍板 d)评审中遇到无法决策的点,记录下来,会后处理,不过多纠缠,后续让产品决策后更新需求文档。
3258 0
|
2天前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用问题之如何在组织层面按月、人员的维度(不按项目)统计工时
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
8月前
|
监控 项目管理
冲刺阶段 - 项目管理ITTO及数据流向图(三)
冲刺阶段 - 项目管理ITTO及数据流向图(三)
44 0
|
敏捷开发 监控 项目管理
项目经理必备——使用燃尽图监控项目整体进度
项目经理必备——使用燃尽图监控项目整体进度
158 0
|
存储 数据可视化 项目管理
|
监控 搜索推荐 数据管理
测试人如何做好质量建设
答案都在这里了
181 0
研发管理-ucp整理-效能工具-状态流转总结
研发管理-ucp整理-效能工具-状态流转总结
53 0
研发管理-ucp整理-效能工具-状态流转总结
|
监控 数据挖掘 测试技术
基于流程管理,提高工作质量和效率
在软件开发领域中,流程协作一直是热门的话题之一,不同的组织架构中,定义不同角色和人员的职责范围,并且通过流程规范来管理不同角色之间的衔接机制,以求不断提高协作效率。
466 0
基于流程管理,提高工作质量和效率
|
存储 SQL 开发框架
软件需求人员-如何提升需求分析和业务方案的能力
  今天我准备再写一篇软件需求人员能力提升方面的文章,也就是把这个问题进一步谈透。对于IT行业来说,前面谈到更多的是招聘软件开发或架构设计人员不容易,特别是架构人员也难以培养。而对于软件需求人员也是同样的道理。   软件需求不同于用户需求或原始需求,对于业务需求往往你无需任何的IT技术背景就能够提出你的需求和问题,而对于软件需求则涉及到业务需求分析,分解,形成完整的业务解决方案,复杂的还是涉及到业务建模,最终才形成软件需求。   因此软件需求人员实际是衔接业务用户和内部技术团队的关键桥梁,软件需求和业务建模做得好,技术实现本身也更加高效。同样,一个软件系统最终实现出来灵活,可复用,那么首先
524 0
|
测试技术 API
项目交接:测试应该如何衔接
很多公司都有一些项目的交接问题存在,有从商务外包团队将项目交接给公司自建团队的,也有因为公司的一些组织架构的调整导致的项目交接。(有些公司叫项目闭环,为什么叫闭环我其实也不清楚啊,就是本来A团队在AA部门做AAA项目,调整后就是A团队在BB部门做AAA项目的一部分或者全部)
275 0