请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 41|回复: 0

看板可视化设计第4步:设计看板的工作项卡片

[复制链接]
发表于 2022-1-10 11:39:08 | 显示全部楼层 |阅读模式
在看板上将工作项用卡片的方式可视化。卡片的设计要遵循“足够好”的原则,即卡片对工作项的状态和风险的呈现有一目了然的效果,足以让团队依据卡片的信息做决策。如图7-12所示,工作项卡片可视化的信息一般会包含这些内容。
粘贴上传202201101136407793..png

) c. y# d  Y4 g* n) H6 b* U9 f! o3 O: e0 i8 x) T
图7-12工作项卡片模板
% t! X1 T/ [8 n' `& r  d2 K# Q
1.工作项类型或服务级别

- K9 V# K+ Q/ i& h$ `
不同类型或者不同服务级别的工作项需用不同的颜色标识,以便于区分。要达到的效果是,当团队站在看板前,不需要猜测或询问某个卡片代表的含义。例如,团队在建立看板的时候可以这样约定(如图7-13所示)。
) _" q) m! Y8 C7 c& n5 }
粘贴上传202201101137135081..png
图7-13工作项的颜色定义

! s- D4 j0 R- I. J4 {: ?% l' @, T  R
2.标题与ID
% n; w! B4 t0 d8 |
每个工作项卡片都需要有个标题,用一句话来描述卡片。如果团队用电子系统管理工作项,每个卡片上一般还会有一个ID号,作为卡片在电子系统里的唯一编号。

& }7 n* g  q( [1 k* v% Y
3.负责人
) c$ E: T# g# J
团队可用其喜欢的方式将责任人可视化。很多团队在卡片上直接写上负责人的名字,这样做不直观,大家需要走近看板并将卡片拿到手里才能看清负责人的名字。而且,如果要改变责任人,则需要修改卡片上责任人的名字。

( W' F) W- M% G. ]$ X# l) C
一个灵活的小窍门是用磁贴标识负责人,将名字写在磁贴上,而磁贴可以自由移动到任何卡片上。
还有一种方法是“阿凡达”可视化方法,即用“替身”图片代表某个人。这种方法让看板变得生动、有趣,有助于营造轻松活泼的工作氛围。

( c# [! P/ s; C
3. 优先级序号
5 X* I) Q" e& W7 m# K  ~
对于如何标识优先级顺序,每个团队有自己的习惯,常见的形式如下。
" C8 y+ q; W- E7 ?$ N
(1)数字序号1,2,3,4,5……
(2)没有明显标识,但是在看板队列里从高到低按照优先级的顺序摆放卡片,从而团队明确地知道下一步该做哪张卡片上的工作项。

3 j) a- c+ I) l* T
很多团队看板上有大量卡片,甚至所有卡片的优先级写的都是“ASAP”(AsSoonAsPossible),即越快越好。

# \1 B, Q$ [6 M, _1 H6 a8 ]' d
优先级的定义是相对的,即A相对于B更重要,B相对于C更重要。如果大量卡片都是ASAP,那就说明团队没有真正分析工作项的优先级。如果所有的工作都一样重要,那么可能就没有真正重要的工作项。

, N9 @/ F& }9 |2 u4 ^& p
问:优先级顺序与服务级别有什么区别?
4 P- [& Q' ~  U1 L+ S) u# S' {
答:服务级别是从延期成本的角度对工作项的服务等级进行分类,而优先级顺序是工作项之间相对的关系。比如,有同样固定截止日期的工作项A和B,A的截止日期更近些,同时工作量也更少些,那么工作项A应该比工作项B的优先级顺序更靠前,团队优先拉入A启动。由此可见,对工作项排优先级顺序的时候,应该先按照服务级别分类,然后,对于同一服务级别的工作项再排优先级先后顺序。
- {" K$ P' }; l) h9 E0 y! F6 L0 o
5.描述

- p- [1 u. H4 ]2 ^0 [
不同类型的工作项有不同的描述形式:如果是需求,团队一般会采用用户故事的形式进行描述;如果是缺陷,每个公司一般会有自己定义的描述模板。
; T4 X4 G8 c. `' X) n- i
6.规模/工作量

& P6 m: o, e; Z- }# C" b# h) M
在不同的企业,甚至是同一个企业里的不同团队都可能会采用不同的工作量估算方式。常见的工作量估算方式如下。

9 \& u; M2 {8 f5 y; y
  • 自然天:一个工作项预计需要多少天完成。
  • 故事点:一个工作项需要几个点数(点数是虚拟的没有单位的相对度量单位)。
  • 小时数:对于将需求拆分为技术实现任务的工作项而言,可以更细粒度地估算到小时。
    $ b2 u8 f+ Y# L* K5 S

7 e6 m7 W; ~; b1 x! A
此外,估算不是必需的,取决于团队的成熟度和工作习惯,以及需求拆分的粒度。需求拆分得越小,估算的必要性就越小。
5 `5 A5 D$ A+ V1 z0 d' x$ l$ R( F
7.时间信息

3 }* N& V  }" ?0 ~  Q# V+ D
团队根据自己的需要,可以记录以下时间信息。

! I) G; s! Q- d* j0 ~  D% I: ?
  • 卡片的启动日期,即卡片开始进入看板就绪队列的那一天。打个比方,启动时间相当于我们点完菜后下单的那一刻,我们以此作为计算饭店上菜周期时间的起点。
  • 卡片的实际完成日期,即卡片流动到看板最后一列的那一天。实际完成时间相当于饭店服务员将菜端到我们面前的那一刻,我们以此作为计算上菜周期时间的终点。
  • 卡片的周期时间,即卡片的实际完成时间减去卡片的实际开始时间。如果团队用电子看板系统,卡片的开始时间和完成时间都是自动记录的,不需要人工记录。此外,很多具有度量统计功能的电子系统可以自动统计出周期时间。
  • 卡片的截止日期,或团队的承诺日期。对于固定交付日期类型的卡片而言,团队需要记录卡片要求的交付日期;对于非固定交付日期类型的卡片而言,如果团队已经向利益干系人承诺了交付日期,那么也应该记下这个日期,在每日站会的时候关注对于承诺的达成是否有风险。) L* w' h' v4 c! }: M3 d, C0 D) P

4 F; ]! J. s9 m0 L% T4 h
很多团队喜欢更精细化地管理,在卡片进入看板的队列后就开始详细地计划卡片的开发启动日期、开发截止日期、测试启动日期,测试截止日期。
3 n" G$ ]' e, _: O3 D; j& [6 j6 I
这样做貌似让计划看起来很靠谱,团队也有了安全感,但其实削弱了团队应对变化的灵活度。很多工作项在开发还未启动的时候,开发过程中会遇到什么困难是未知的。如果这时候就设定开发的截止时间,甚至用这个截止时间来推算测试的启动日期和截止日期,那么这样的测试计划实际上是将开发过程中的不确定因素纳入自己的工作中。这种过早的计划不但不靠谱,反而是一种管理上的浪费。更严重的负面作用是,当特性A的开发截止日期临近的时候,如果此时有更高价值的特性B流入看板,团队为了确保特性A在原来计划的截止日期之前完成开发,会将更高优先级的特性B搁置,结果导致团队优先交付的是更低价值的工作项。
) J$ J/ F4 c% X/ E6 O: ]& U8 A
8.风险和依赖

1 f) |/ w3 q7 v$ W; @! P
卡片的风险和依赖都需要显性标识,标识的方法有很多种。比较简单的方式是用一张颜色醒目的纸贴,标记这个工作项有什么风险或依赖,并将其贴到工作项纸贴的上面。每日站会上,团队都要跟踪风险或依赖,了解其是否已经解除。

# @! q0 C# h# t) I+ |' [5 Q( p' c

9 H! j1 o9 S4 @; c( p& I: ~
5 f" w; Z4 R* D4 `+ m6 w8 W" @8 e/ Y' j




上一篇:看板可视化设计第3步:设计看板的泳道
下一篇:什么是看板拉动式生产
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 18:23 , Processed in 0.102777 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表