转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
在DevOps的研发过程中，好的看板功能有助于优化项目管理、提升开发效率，是较重要的功能之一。本文从需求分析角度入手，分析DevOps产品对看板的需求，并结合普元DevOps产品看板部分的实际开发经验和用户反馈向大家介绍DevOps看板的设计实践之路。
1.DevOps需要的看板
看板是DevOps较为常用的功能，整个项目开发周期都离不开它，从需求划分、任务分配、功能实现到测试上线都需要看板的协助，看板使抽象工作流程可视化，让项目管理者能更清晰的掌握项目进度。由此，看板设计实践就成为了DevOps实践的重要内容之一。首先我们需要了解一下，DevOps中的看板需要具备怎样的功能：
1.价值流
广义的价值流指的是从原材料变为成品、并给他赋予价值的全部活动。包括原材料的获取，对原材料进行加工后转变为成品交付给客户的过程，其中还包括了各个阶段各方之间的沟通形成的信息流也是价值流的一部分。完整的价值流包括供应链成员之间的沟通，物料的运输，生产计划的制定和产品的生产过程等。
举个简单的例子，服装加工厂要按照客户要求生产一批服装，生产方首先需要和客户确定衣服的款式，用料，具体尺码信息，然后采购制衣所需的布料，将衣服制作图纸下发到相关工人手中，工人按图制衣，完成既定数量的通过质量检测的成衣后将成品送到客户手中，这就是一条完整的价值流。
DevOps中的价值流
在DevOps中，价值流的概念同样适用。定义：把业务构想转化为客户交付价值的、由技术驱动的服务所需的流程。
价值流贯穿了整个开发周期，好的价值流在保证快速的交付的同时还能保证部署工作不会产生混乱和破坏。只有打通业务、开发运维等一些列的价值链条，保证价值可以完整畅通的流动，减少积压重组，才能保证产品的顺利交付。在此前提下，提高开发效率实现敏捷开发才是可能的。但是技术价值流与制造业的价值流不同，它是不可见的，因此我们很难发现整个价值流是否顺畅，在哪里产生了阻碍积压。因此我们需要将价值流可视化，清晰的把价值流的呈现出来，这样价值流是否完整，哪里存在缺失就一目了然了。
2.DevOps的三步工作法基础原则
《凤凰项目》一书把三步工作法作为基础原则并由此衍生了DevOps的行为和模式：
（1）开发到运维的工作快速的从右向左的流动------流动原则
在保证质量的前提下加快价值流的流动速度，尽可能的优化工作流，减小流动单元合理控制流量，减少等待时间，提高工作效率，可以归结为以下几点：
- 使工作可见
- 合理控制最流动单元
- 减少交接次数
- 消除阻碍价值流的问题
（2）从右向左的每一个阶段中，应用持续、快速的工作反馈机制------反馈原则
反馈原则是在流动原则的基础上建立的一条信息流，价值流上的各个环节通过这条信息流沟通，好的信息流有助于及时发现并解决问题，从中分析并总结经验可以提升项目开发效率。
（3）建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验——持续学习与实验原则：他打造出一种高度信任的文化和一种科学的工作方式
常见的项目中每天的站会、每周的周会一般是项目成员集中在一起交流并互相学习的机会，大家对工作作出自我总结并提出自己的想法互相交流意见，实现工作中的自我提升。
看板在DevOps中主要作为价值流的载体的一部分，使价值流中一些较为抽象的信息可视，并让用户可以从中看清楚价值流的流通情况、每一个环节及环节的具体操作情况，何处需要改进、何处存在问题。三步工作法则可以帮助提升工作效率。结合对价值流的概念以及三步工作法原则的分析，看板需要具备以下功能：
（1）清晰描述最小工作项单元及工作项间的关系
（2）提供便捷的小组成员互相沟通方式
（3）快速直接的反馈某工作项的各种情况
（4）一目了然的任务完分配集成情况，方便开会总结
2.看板实践及优化
首先是工作的最小单元——工作项，工作项是看板上各类工作内容的最小显示单元，负责显示工作内容的各种信息，一些类似的工作项管理看板对工作项类型进行了极为细致的划分，但过于繁杂的工作项类型难于记忆并且存在概念重复反而不利于，结合实际项目开发情况我们将工作项类型分为三类：
（1）故事——一个故事代表一个完整的需求点，可以包含多个任务、bug，一 个故事及其包含的所有子项目可以完整的诠释一个需求点在价值流上流通的全过程
（2）任务——将故事拆分为一个个的具体工作内容，分配到具体人员
（3）Bug——测试人员向开发人员、项目管理人员提出反馈的途径
工作项的要展示很多的具体信息：
（1）描述信息（标题、描述、附件、Comments、所属迭代、所属版本）
Comments是提供给开发人员的交流空间，让开发人员可以在这里进行简短的意见交流，一些较小、内容简短的讨论可以在这里进行，无需所有相关人员聚集在一起讨论节约时间
（2）状态信息（工作项状态、优先级）
（3）人员信息（责任人、创建人、解决人）
明确工作项的相关人员，责任划分明确。
（4）时间信息（创建时间、预估时间、耗费时间、到期时间）
提供明确的时间信息，有利于项目管理者控制项目开发进度
（5）关联的工作项（子任务、Bug）
将有关的工作项关联到一起，完整描述产品中某一项功能，从需求分析到开发实现到测试反馈的全过程
工作项设计完成后需要考虑的就是如何一个个的工作项集中在一起展示，考虑到DevOps的用户有很多不同的角色，对看板的关注角度也不同，例如项目经理更希望可以一目了然的看到任务的完成情况，开发人员需更关注的是分配给自己的工作项的具体的内容，综合各方面分析考量，对看板设计了四种展示方案：
（1）普通列表
普通列表视图用分页列表形式展现工作项，不会展示过于详尽的信息，意在为用户提供一个可以快捷操作的页面，如添加工作项、快速修改工作项的状态。
（2）详情列表
详情列表视图将页面分为左右两个区域，左侧是简化的目录列表展示全部工作项，右侧展示用户在目录列表选中的工作项的全部信息，适用于快速浏览工作项后切换查看各个工作项的详细信息。
（3）状态甬道
从工作项状态的维度展示工作项的简要信息，标题、负责任、状态，方便项目组举办周会，每日站会时汇总展示当前所有工作项所处状态，统一分配任务、总结任务完成情况使用，采用拖拽形式来修改任务状态，方便快捷。
（4）时间甬道
针对每日站会的甬道，项目进入较为紧张的开发阶段时往往需要每日或较短的时间内分配任务、查看任务完成情况，以时间为展示维度，让项目管理者看到每个时间段内工作项的数量、完成情况，方便把控项目进度。
根据真实使用反馈的优化完善
DevOps的看板设计完成后经过一段时间的使用，发现了许多问题，我们对此做出了总结和改进：
（1）检索功能优化
工作项具备很多检索条件，条件过多，选择控件按钮在页面上堆叠，用户体验不佳，所以改为采用折叠形式的查询栏并提供常用查询条件存储功能，优化体验。
（2）时间甬道看工作项板卡片优化
工作项具备很多属性，开站会时经常需要修改负责人、任务优先级等一些信息，甬道修改时间方便但是要修改其他属性则需要进入详情页面，增加了操作步骤，浪费时间，因此将一些常修改的属性添加至卡片上方便修改。
（3）列表视图信息快速修改优化
列表视图的使用者一般对工作项内容较为了解，很少查看工作项详细内容，此类用户要修改工作项的一些基本信息时不希望进入详情页后才能修改工作项信息，因此将列表的单元格改为可编辑形式，减少点击页面次数。
以上就是普元DevOps产品看板模块的设计和实践历程，在价值流可视化和项目成员沟通等方面我们仍在持续改进，希望能打造出更便捷、更清晰的看板，完善DevOps平台看板模块。
*参考书籍：《DevOps实践指南》
