InfoQ

文章

用“看板图”实现敏捷项目的可视化

作者 Kenji Hiranabe译者 郭晓刚 发布于 2007年9月13日 下午1时30分

社区
Agile
主题
协作,
敏捷技术,
团队协作
标签
计划,
值和度量,
精益,
管理

在敏捷项目里,挂在墙上的“人人可见的大图表”是一种普遍的实践,它被用来共享项目的状态并将之可视化。精益系统里也有这样的设施。“看板”在日语里的大意是“卡片”或者“标志”的意思。在精益生产系统里,看板方法是给每个标准生产单元或者每个生产批量附上一张卡片。只有当一个“进行中”卡片所代表的工作完成后,才会有一张新卡片被“拉”进系统。

相关厂商内容

书评:敏捷模式──指向成功的路标

IBM 敏捷开发 Rational 工具篇

SOY Framework:Java富客户端快速开发框架

IDC:《软件商成长路线图》白皮书免费下载

免费迷你书下载:硝烟中的Scrum和XP

相关赞助商

InfoQ中文站敏捷社区,关注敏捷软件开发和项目管理,通过新闻、深度文章、视频访谈和演讲以及迷你书等为中国技术社区提供一流资讯。

在本文中,我将探究当今敏捷项目中广泛使用的各种可视化方法,并提出用看板图(Kanban Board)来组织三种视角(时间、任务和团队),目的是使整个团队都能理解项目的当前状态,并以一种自发、有动力且互相合作的方式来工作。最后,我将介绍“TRICHORD”这个软件工具,它用看板方法来实现这三个视角的项目可视化。

敏捷项目中的可视化

XP有一种实践叫做“信息化的工作空间”,从中你可以对项目的进行状态一目了然[Beck05]。把故事卡和任务卡挂到墙上是这项实践的一种简陋实现方式。挂在墙上的其他图表有时候也被称为“信息辐射体”[Cockburn01]或者“人人可见的大图表” [Jeffries04],它们在现今的敏捷项目空间设施里已经是很常见了。下面,我将展示在日本的敏捷团队中发现的一些可视化的例子。

第一个例子是任务看板图(Task Kanban Board),它的名字来自TPS (Toyota Production System)所用的“Just-In-Time”(JIT)生产方式[Poppendieck03, 07]。

图1:任务看板图

看板是代表一项要完成的任务的标签。在TPS中,它被用来具体化Just-In-Time的“拉”生产控制。在图1里,看板图显示了在本次迭代中要完成的所有任务的当前状态。任务用卡片(便笺纸)来代表,状态则由板上分别标有“未做”、“正做”和“做完”的三个区域来代表。看板图帮助团队理解当前做得如何,以及下一步要做什么,令团队能够自我指导。

图2是另一种类型的看板图,称为“特性看板图(Feature Kanban Board)” [Highsmith04]。

图2:特性看板图

表的横轴代表时间线,线上的竖直区域代表发布,在区域中的卡片各自代表一项该次发布中要实现的特性。第一个例子常在开发团队中使用。跟第一个例子相比,特性看板图为产品路线图提供了一种更高层次的概观,因此分享范围应该被扩大到整个大团队,包括客户、市场员工和管理层。

图3的“停车场图(Parking Lot Chart)”被用来提供一种最高层次的对项目状态的摘要总结(注意不要同另一种“停车场列表(Parking Lot List)”弄混,那是一种用来帮助捕获未解决的问题的工具)。它是在《Feature Driven Development》(FDD)[Palmer02]里首次提出来的,现在已在敏捷项目中广泛使用。有时候也被称为“项目仪表板(Project Dashboard)”。

图3:停车场图

. 图4所示的另一种可视化方式称为延烧图(Burndown Chart)

图4:延烧图

这种表在Scrum[Schwaber01]中首次提出,用来显示剩余的未完成工作(backlog),现在已经蔓延到了大多数敏捷项目中[Cockburn04][Cohn05]。它抓住了项目的当前状态以及完成剩余工作的进展比率。

图5所示的最后一种有意思的可视化方式叫做表情日历(Niko-niko Calendar或Smiley Calendar),一种日本人的创造,它显示了团队成员每日的心情。当天工作结束后,每个人都在离开团队空间之前往自己的日历上画一个表情符号[Sakata06]。它从成员的精神健康和动力的角度来观察项目。

图5:表情日历

 

用看板图作为主要的信息辐射体

总而言之,以上提到的可视化工具:

  • 用卡片作为任务、故事、特性的象征(看板),并将它们依附在时间线上(看板图)。这里存在不同的粒度。
  • 计算看板(未完成任务)的数目,分时间段来跟踪它们,以显示出工作的完成趋势。这里也存在不同的粒度。
  • 总结最高层次上的项目状态。
  • 除了表情日历之外,还有很多日历变种可以用来显示项目的状态或者计划。

注意在看板图、延烧图和停车场图三者之中,看板图的信息最详细。延烧图和停车场图可以用看板图的每日变化信息来绘制。因此后面我将把看板图作为主要的信息辐射体,而用延烧图和停车场图来作为辅助工具,形象地总结看板的变化趋势。

从三个视角来组织看板

仔细观察看板图,你会发现上面表达了三项主题——时间、任务和团队。下面我尝试从这三个视角来组织看板。

图6:时间与任务的分解

1.时间

在敏捷项目里,项目时间首先被分解成若干“发布”,每个发布又被分解成若干“迭代”,每个迭代又分解成若干“工作日”。

  • 发布的时间长度一般为1到6个月,它是最粗粒度的时间单元。它是整个团队的一个同步点,因此团队中的每个人都应该对此感兴趣。
  • 迭代是第二级的时间单元,长度一般为1到4周。开发团队用它来作为主要的工作、跟踪和改进周期。
  • 工作日是最细粒度的时间单元,团队每天在站立会议上聚集在一起交流项目的状态和问题。

2.任务

任务被分成三种粒度。我把最高层次的叫做“特性”,每个特性都被分解成若干“故事”,而每个故事又被分解成若干最低层次的“任务”。

  • 特性是对用户有用和有意义的一项功能。
  • 故事是特性的一个可测试的片断,以用户的语言来描述。
  • 任务是故事中的一个工作单元,通常以开发者的语言来描述

3.团队

项目团队由为了共同目标而工作的人们组成。一般团队的成员有一个经理,若干客户、程序员、业务分析员、用户、测试员,以及其它利益相关的人。整个团队都应该分享时间和任务信息来达成项目的目标。

用看板图为团队将任务映射到时间

我乐于将看板图定义成一种团队中任务与时间之间的映射。请注意“时间”和“任务”都可以分解成三个层次,分解的层次越高,应该牵扯到的管理层次就越高。所以,按照“发布—特性”、“迭代—故事”和“工作日—任务”的组合来设立看板是合理的,虽然其它时间与任务的组合也并非不可行。

表1:用看板结合时间与任务

“特性看板”的长处在于向全团队提供项目的一个高度抽象的视角。可以搭配停车场图来显示出最高层次的状态。

“故事看板”处在中间层次,向团队提供每次迭代的最广泛周密的信息,搭配迭代的延烧图会更有效。

“任务看板”的层次最低,它显示出每日变动的当前状态,搭配每日的延烧图会更有帮助。

图7:概观——三种视角以及用看板图将任务映射到时间

TRICHORD

我们正在开发一个名为“TRICHORD”的敏捷项目管理工具。TRI指的是三种视角(时间、任务和团队),CHORD则是和谐的意思。

它作为全团队分享项目状态的一个工作空间来运作,如表1所示,里面提供三种层次的看板图——特性看板(发布—特性)、故事看板(故事—迭代)和任务看板(工作日—任务)。特性看板用停车场图来归纳,故事和任务看板用延烧图来归纳。

图8:TRICHORD(看板图+延烧图+停车场图)

另外,TRICHORD有一个表情日历服务用来给全团队分享心情。它也是项目中的SNS交流中心,就像一个简单的“twitter”。

图9:TRICHORD表情日历

TRICHORD用Eclipse RCP实现,可与Trac(问题跟踪系统)协同工作。

致谢

非常感谢Mary Poppendieck,他从头到尾审阅了本文并提出了许多宝贵的建议。

参考资料


[Sakata06] Akira Sakata, “Niko-niko calendar”, 2006
http://www.geocities.jp/nikonikocalendar/index_en.html
[Beck05] Kent Beck, “Extreme Programming Explained 2nd “, 2005 Addison-Wesley
“信息化的工作空间”是一项XP实践。
[Cockburn01] Alistair Cockburn, “Agile Software Development”, 2001 Addison-Wesley
首次使用“信息辐射体”一词。
[Cockburn04] Alistair Cockburn, “Crystal Clear”, 2004 Addison-Wesley
文中认为 “延烧图”是一种有力的技巧。
[Cohn05] Mike Cohn, “Agile Estimating and Planning”, 2005 Prentice Hall
深入探讨了“延烧图”
[Jeffries04] Ron Jeffries, "Big Visible Chart", 2004
http://www.xprogramming.com/xpmag/BigVisibleCharts.htm
[Poppendieck03] Mary and Tom Poppendieck, “Lean Software Development”, 2003 Addison-Wesley
[Poppendieck07] Mary and Tom Poppendieck, “Implementing Lean Software Development”, 2006 Addison-Wesley
解释了TPS中的看板,及看板如何作为“拉”处理机制运作。
[Schwaber01] Ken Schwaber, et al. “Agile Software Development with SCRUM”, 2001 Prentice Hall
[Highsmith04] Jim Highsmith, “Agile Project Management”, 2004 Addison-Wesley
在这里,特性看板被称为白板上的特性分解结构和特性计划。
[Palmer02] Stephen R. Palmer et al., Practical Guide to Feature-Driven Development, 2002, Prentice Hall
首次介绍了Parking Lot Chart。

关于作者

Kenji Hiranable是Change Vision, Inc的CEO。他是JUDE(一个UML和MindMap编辑工具)。他还把《Lean Software Development》、《XP Installed》、《Agile Project Management》以及其他XP/Agile书籍翻译成日文。Kenji把软件开发看作是一种沟通游戏,并一直在寻求提高软件开发的生产效率、合作程度以及乐趣的途径。关于TRICHORD的更多信息请见trichord.change-vision.com

查看英文原文:Visualizing Agile Projects using Kanban Boards

2 条回复

回复

把软件开发看作是一种沟通游戏 发表人 kabbesy cai 发表于 2007年9月18日 上午10时16分
Niko-Niko Calendar 发表人 Xiaogang Guo 发表于 2007年9月18日 下午9时19分
  1. 返回顶部

    把软件开发看作是一种沟通游戏

    2007年9月18日 上午10时16分 发表人 kabbesy cai

    这篇非常赞!“把软件开发看作是一种沟通游戏”当作自身理念后,才能沉淀出来的感受。

  2. 返回顶部

    Niko-Niko Calendar

    2007年9月18日 下午9时19分 发表人 Xiaogang Guo

    我觉得Niko-Niko Calendar真是太直观了,一眼就能看出团队中哪位遇到了麻烦。 另外,一点恶趣味:TriChord——三个代表,和谐社会?

独家内容

OpenSocial规范、实现现状与展望

OpenSocial为构建跨多个网站的社交应用程序提供了一组通用 API。开发人员可以使用标准 JavaScript 和 HTML 创建应用程序,用以访问社交网络里的朋友并更新对应的Feeds。本文是对本次QClub活动内容的一个简短总结,希望对没有到现场参会的读者了解OpenSocial有所帮助,也希望能引起大家更多的讨论。

运用Ruby纤程进行异步I/O:NeverBlock和Revactor

Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。

与杨巍一起探讨OpenSocial

InfoQ中文站有幸与Google中国的产品经理杨巍先生在一起探讨了OpenSocial的相关话题,包括OpenSocial的初衷、构成要素、实现方式、以及要实现它的技术储备等等。

书评:敏捷模式──指向成功的路标

Ryan Cooper对Amr Elssamadisy的新书发表了评价,并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法,而是为读者提供一些模式和工具,用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。

构建的可伸缩性和达到的性能:一个虚拟座谈会

这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。

OpenSocial的分析与实现

本视频主要对OpenSocial进行了分析,并对实现的方式进行了介绍。其中包括:OpenSocial的开发经验、Container Provider的技术准备、平台的构成要素、具体的规范、以及对未来的展望。

缓存系统MemCached的Java客户端优化历程

Memcached在大型网站被应用得越来越广泛,但是Java客户端并不多,本文作者基于现有的开源客户端进行了封装优化,并翔实记录了这一过程。

超越SOA:动态业务应用的新企业应用框架(2)

在他们文章的第二部分,作者探讨了动态业务应用的架构并介绍了资源容器的概念。他们示范了如何在JEE之上构建这个架构,以及它如何影响实现生产力。