敏捷事关整体团队经验

摘要: 敏捷事关整体团队经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去,以便团队中的每一个人都能达成一致的共识。然而,随着项目增大,团队开始迷失在大堆的用

  敏捷事关“整体团队”经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去,以便团队中的每一个人都能达成一致的共识。然而,随着项目增大,团队开始迷失在大堆的用户故事里,很难让每个人都能看到相同的全景图(big picture)。本文讨论了可视化全景图的各种方法。不仅可用于负责人和管理者,更可以用于每一个人。

  在理想的情况下,敏捷团队应该针对当前迭代提出清晰的计划,而后续的发布计划可以较为粗略。而事实上很多情况是,团队在当前迭代只是急于实现下一步的小创意。他们完全忽略了全景图。通常会有这样一种情况:这张图保存在一个角色的脑中,比如团队领导、业务分析师、项目经理、产品经理、甚至是ScrumMaster。这往往是由于他或她没有真正地推动自组织所导致的。这一现象在某些情况下还是可以接受的,比如一个不重要的短期项目,但在许多情况下,这会造成恶劣的后果,当团队偏离轨道时他们也什么也察觉不到,因为他们觉得所有的工作都还在正常地运转。

  商业价值

  在很多时候,我们在一些伟大想法(这可能来自于公司创办人、部门主管、顾客群或社区)的基础上去规划一些事情。在我们的现实世界中,这些想法通常不是静态的,它在不断地发生着变化。如果能够精确地看出项目进展全景图(big picture),可以使我们具备更多的洞察力,帮助我们保持正确的运转方向。

  例如:你的大老板洞察力到通过LinkedIn登录将是一个很有杀伤力的特性,它对于渗透到尚未开发的专业市场很有帮助,但是,一旦传达到产品经理那里,在种种原因影响之下信息沟通产生了畸变,而且优先级未被正确理解。用以连接的API不是现成的。你的生产环境上还有5个其他的问题,以及许多其他正当的理由,导致你没有把这项新功能安排上日程。到最后,距离发布日期还有不到一半的时间了,你们甚至还没有开始这个集成功能的开发。最好让你的老板和团队能够从一开始就知道这种差异,而不是拖到最后。

  有时候,团队迷恋在次要特性的技术问题上,投资过高而业务价值回报较低。假设,团队为了努力解决与FourSquare的集成,在前3个迭代中已经花费了一多半的精力,了解到这一点的产品经理会决定说“算了吧”,然后继续前进。

  那么,我们如何使这些信息可见呢?

  燃尽图(Burndown Chart)

  产品燃尽图是敏捷团队经典的进度可视化工具,它非常有效的描绘了团队进展的速度和生产能力。它可以基于数百个故事的故事点和状态精细地展示概要。它有自己独特的美,但只有这些可能还不够。假设你已经按时达成了目标,但却发现这是一个错误的目标!燃尽图可以判别完成的时间,但不能判别完成的内容。下面这张虚构的燃尽图(来自Mike Cohn的《敏捷估算和规划》)显示,在迭代2末端追加了一些范围,然后一切都回到了预计的轨道上。

  我们如何可视化全景图?这里有几个技巧。

  史诗故事(Epic)

  史诗故事从根本上说只是大的用户故事。凭借Mike Cohn和他《敏捷估算与规划》一书,这个术语已经被广泛采用。然而,史诗故事和类似的术语(如主题和特性)在不同的敏捷团队有着不同的应用,但无论在哪一个团队中,它们都是为用户故事进行分组的技巧。在他自己博客的一个评论中,Mike Cohn提到,最初是Kent Beck向他解释了史诗故事这个术语。这里有摘自该博客的一些定义:

  1、我们将一个特定的故事称为史诗故事时,并没有什么特殊的界限。它的意思只是“大的用户故事”。

  2、“主题”是一系列用户故事。我们可以把关于月度报表的故事分为一组,并拿条橡皮筋把它们束起来,然后称之为“主题”。

  这也意味着史诗故事与主题之间是无关的。下面的图片可以帮你更好地去理解。

  Mike作出一个有趣的总结,“把一个故事称为史诗故事有时能传达额外的含义”。比如说这个故事估计会很大,我们需要将它分解为一些较小的故事。

  精益人还介绍了其他术语,如MMF(最小市场特征或最小市场特征集Minimal Marketable Feature or Minimal Marketable Feature set)这是另外一种定义需求的方式。MMF通常比故事更大,于是许多人已经将它视为史诗故事了,但是它比刚才的大故事有更多具体的定义。如果你发布的东西有客户来买,功能再少了客户就不买了,这样的最少特性集就是MMF。如果它没有市场,可能是它太小了,而且不能分解出更大的故事。一个或多个MMF与最小可用产品(MVP)一起发布。因为精益企业(Lean Startup)活动的出现,最近这个词已经非常流行。

  于是我们有了史诗故事、主题和MMF。现在该怎么办?我们如何使用它们,以帮助我们获得更好的全景图?

  故事映射(Story Mapping)

  故事映射模式因Jeff Patton而流行起来,它是大量待处理故事(backlog)的可视化方式。按照Mike Cohn对史诗故事这一术语的描述,故事映射只不过是一张史诗故事地图,它们所有的子故事都在一面大墙上。主干(backbone)包含一个有序的史诗故事列表,当列出子故事时,你认为要讲述哪些故事,就像骷髅人(walking skeleton)那样在主干下排出优先级(编辑注:即,在只有骨架没有肉的状态下开始行走)。下图出自《新用户故事待办工作是一张地图(The new user story backlog is a map)》一书,由Jeff Patton写于2008年。

  如下,杰夫描述了故事映射的用法。

  当这个项目正在运行时,它成为我们冲刺或迭代计划的公示板。我们直接在示意图上识别或划分出要在下一次迭代中去构建的故事。在迭代期间我们将不只放置故事,我们采用任务墙去管理它们的开发——但这个故事示意图放在规划墙上提醒我们什么是全景图,我们已经取得了多少进展。

  故事映射的确是一个把大量待办工作组织起来的好方法。相比平白直叙地描述待办工作,它可以更好地去讲述一个故事。在同一骨干项目(如史诗故事)下把故事分组,帮助我们可以在更高的级别上沟通,效果优于在详细故事上的沟通。它也非常有助于挑选最小可用产品部件,你或许需要从各个骷髅人的一个(顶层)点堆积组成一个最小可用产品。

  然而,有时候你只需要一张单独的图片来描绘项目概要。你已经给老板展示了燃尽图,但它表达的是“什么时候”而不是“什么”。你很希望老板在大故事映射墙上花些时间,但事实很难如愿。我们该怎么做?是否还有其他选择?

  停车场图(Parking Lot Diagram)

  由Mike Griffiths写于2009年的《重新讨论停车场图——使用区域去展示成就(Parking

  Lot Diagrams Revisited – Using Area to Show Effort)》书中,提到了一个有趣的全景图可视化技术——“相对尺寸”停车场图。

  红绿灯颜色代表了紧迫感,如红色意味着它已经错过了进度,而绿色意味着它可以满足最后期限的要求。因为大多数项目仍然在向最后期限进发的进程中,所以它们一直用黄色来表示。相对尺寸是原始尺寸停车场图的改进版。较大的矩形表示它有较大的估值(在故事点中)。作者指出,该图很容易理解,但在PowerPoint中很难用手工来绘制。博客还提到了一些其他想法,包括一个简单的按比例缩放的柱状图,它比较容易用Excel绘制或编码实现。

  树图(TreeMap)

  另一种可视化方式是通过树图(也称作热力型地图(Heatmap))可视化大型产品的待办工作。这个方式由Mike Cohn写于2008年,我觉得用它来记录大型和复杂的数据集很有意义。尽管写于几年前,Mike迈克在最近的评论中仍坚持认为,它一直是展现大型项目的最佳方法。

  “是的,我仍然认为这是可视化大型产品待办工作的最佳方法。树图已经经受住了时间的考验,比如图形化股票市场,所以在最近这段时间,对我们来说它依然是一门好的技术,我不希望它们被替代 [Mike Cohn,2012年5月11日]。”

  下面这张树图源自Eidos beta版最近的待办工作,是通过Google Chart Tools API绘制的,我所在的公司正致力于这个敏捷项目协同工具。深绿色的块表示下一步的史诗故事已取得一定进展,它们的面积与史诗故事的规模(所有故事的故事点总和)成比例。此树图告诉我们,因为已经完成了许多大型史诗故事,Eidos的beta版本差不多准备就绪了。

  这些图片提供给我们不错的今日快照,但它不能告诉我们关于过去和未来的任何信息,因为这里只有两个维度的数据,比如在本例中,只有史诗故事的规模和状态,但没有时间维度。

  镖靶图(Dartboard)

  下面的镖靶图,由Nicholas Muldoon在《针对产品的史诗故事(Epic)可视化》中提出,每个史诗故事图形化的“计划”由每块区域来表示。每个方块符号是一个故事。最内部的圆圈是当前版本,在它外围的4个圆圈是接下来的4个版本。圆圈外面的符号是计划外的故事。红绿灯颜色代表故事已完成的程度,从红色、黄色到最终的绿色。

  尽管该图显示了时间维度,但它并不能真实地显示出故事之间所需的相对努力。也许,以每个符号的大小去反映它相对的规模,可以很容易地将它进一步增强。

  面积堆叠图(Stacked Area Chart)

  在Eidos中,我们正在研究如何去有效地可视化全景图。还有一个方法是面积堆叠图。本图不仅显示相对规模和状态,并且显示进度已经历的时间。例如,针对故事板(Storyboard)和故事卡(StoryCard)上的史诗故事,你可以看到我们从开始到现在所有的工作进展,以及我们刚刚在迭代6中提交的迭代计划和附件。

  带有史诗故事条的增强型燃尽图

  还有一个方法是在燃尽图下显示史诗故事进度,原始Eidos截图如下。在燃尽图下的条形图中,每个色块代表每个史诗故事的故事点总数。在其他图中,增强的燃尽图还能显示每个史诗故事“还剩哪些”没有实现。

  总结

  所有这些可视化方法都在努力解决同样的问题,比如在时间、规模和需求组等不同维度概括大型、复杂的数据集。更为复杂的数据与可视化,你就需要去更加自动化地表达全景图。

  让我们再来回顾一下所有已讨论过的可视化。关键的不同在于维度和打算要可视化显示的内容。很明显,如果采用了仅显示某时间点的截图(如树图),就无法显示各时间段上的数据。

时间: 2024-11-01 18:14:44

敏捷事关整体团队经验的相关文章

敏捷测试的团队构成

各自分离的功能小组会让敏捷团队更困难.持续的交流至关重要.团队成员需要互相亲密地工作,不管工作是通过虚拟环境还是在同一个地点完成.敏捷测试专家Lisa和Janet分享了敏捷测试团队的组织经验. 独立的质量保证团队 许多组织,不管大还是小,为了得到关于产品质量的诚实的观点,认为拥有独立的质量保证团队或测试团队是很重要的.经常有人问我们:"在整体团队运作方式中有测试组织的位置吗?"以及"如果有,是什么角色?"希望保持质量保证团队与开发团队分离的原因有: ● 拥有独立的检

网易有道笔记负责人谈敏捷开发的实战经验

摘要: 网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用敏捷开发呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师;二.团队内有一名合适的Scrum Master. 有道云笔 网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用"敏捷开发"呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师;二.团队内有一名合适的Scrum Master. 有道云笔记团队成立于从2010年,从成立伊始我们就一直积极地在实践中尝试Scrum(敏捷开发的一种项目管理方法)的做法.

独家 | PHM数据竞赛首个中国夺冠团队经验分享(常用模型&赛题详解&PPT&视频)

昆仑数据首席数据科学家田春华博士演讲视频: 团队成员代表刘家扬演讲视频: 以下内容经数据派THU整理而成: 后台回复关键词"1114",下载两位演讲嘉宾完整版PPT. 昆仑数据首席数据科学家田春华   一.工业大数据背景知识和赛题背景 田春华:竞赛是促进大家研究和交流的一种机制,而各个赛事侧重点不同.在KDD-CUP竞赛中,题目相对通用,对于参赛人员的门槛较低,因此会有大量的队伍参加,最后的前几名基本上是小数点后两位或三位的比拼.而PHM侧重于工业行业,一般会描述一个相对具体的问题,参

Facebook 产品设计总监的团队经验

本文翻译自 http://www.aliyun.com/zixun/aggregation/1560.html">Facebook 产品设计总监(director of product design)Julie Zhuo 所写的 A Managers Manifesto(一位管理者的宣言) .她曾参与过许多 Facebook 的产品开发,也和后来成为 Path 创办人的 Dave Morin 合作过.本文她与大家分享了自己管理产品设计团队的经验. 10. 永远记得,做出决定前要先综观全局.

敏捷Retrospectives - 让团队从优秀到卓越 第一章 帮助团队审查和调整

Retrospectives会帮助团队持续的改进,即使是很优秀的团队.在这章中,我们以一个历时1小时的迭代Retrospectives作为例子来开始讲述.我们会来看看,Retrospectives lead一般需要做什么,同时我们会通过例子来分析一下怎么应用Retrospectives的一些流程. 让我们来看看一个开发金融软件的团队是怎么在他们的2周迭代后进行他们的Retrospectives的.这个团队,轮流负责主持Retrospectives,这周轮到了Dana. 所有人坐好了,一个半圆形.

如何将敏捷项目可视化

敏捷事关"整体团队"经验.我们在一起做计划.在一起编码.在一起测试.在一起检视过去,以便团队中的每一个人 都能达成一致的共识.然而,随着项目增大,团队开始迷失在大堆的用户故事里,很难让每个人都能看到相同的全景图 (big picture).本文讨论了可视化全景图的各种方法.不仅可用于负责人和管理者,更可以用于每一个人. 在理 想的情况下,敏捷团队应该针对当前迭代提出清晰的计划,而后续的发布计划可以较为粗略.而事实上很多情况是,团队在 当前迭代只是急于实现下一步的小创意.他们完全忽略了全

可视化全景图的各种方法

敏捷事关"整体团队"经验.我们会在一起做计划.在一起编码.在一起测试.在一起检视过去,这样团队中的每一个人都可以更方便的达成=共识.但是随着项目越来越大,团队开始在大堆的用户故事里迷失,让每个人都能看到相同的全景图(big picture)是十分困难的.在这里就讨论了可视化全景图的各种方法.不仅可用于负责人和管理者,于每一个人更可以用. 在理想的情况下,敏捷团队应该针对当前迭代提出清楚仔细的计划,而后续的发布计划可以较为粗略.而事实上很多情况是,团队在当前迭代只是急于实现下一步的小创意

《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》SAFe团队层

本节书摘来自华章出版社<SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架>一书中的第1章,第节,作者 迪恩·莱芬韦尔(Dean Leffingwell)更多章节内容可以访问"华章计算机"公众号查看. SAFe?团队层   3.1 团队层介绍 我们.工作.知识是一个整体. --本书作者 摘要 SAFe团队层是项目群层的组成部分,但有时会分开讨论.所有的SAFe团队都是敏捷发布火车(ART)的一部分--ART是项目群层的核心组成部分.团队层为敏捷团队的活动提供了组织

唯品会敏捷Scrum实践系列1:团队组成和人员配比

作者介绍 邱戈川,现任唯品会基础架构部分布式服务框架.定时任务调度系统以及容器化管理平台产品经理.16个年头的IT老兵,除了销售和老板角色,做过IT中的各种角色,游走于架构与产品间.关注Docker.Mesos等容器化技术领域的实践.主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能.低延迟广受好评.个人订阅号:vipdocker.   写在前面的话   写这个系列文章的目的不是为了说明什么是Scrum,毕竟讲Scrum的书和文章已不计其数.我写这个文章是希望总结我在唯品会一年多来