SCRUM：敏捷团队的故事（SCRUM: The Story of an Agile Team）——（2）

任务板

  我记得有天早上：我到达办公室时,却发现我们的scrum 负责人准备了一个临时任务板、A4纸、透明胶带。我不知道他在做什么。与往常的每天早上一样,我准备了一壶咖啡,就只是等着看。
  当完成时,一个白色的板被放置在墙上。它有几个列,演变成一个矩形。几个彩色的便签布满在看板上。“那已经是两年前的事了。

  这个看板呈现出我们现在所使用的精益管理流程。记住,敏捷是改变和适应变化。不要盲目的遵循规则。
  所以，在看板上的是什么？

下列展示了开发过程

  总共有四列：

• 版本产品需求——所有的需求都来源于当前的发布版本计划。是的,产品已经准备好在每次迭代后进行发布，但这并不意味着我们一定要发布它。我们通常有五天的迭代时间。
• 迭代需求——当我们和产品负责人计划、协商哪些是想要在迭代期完成。我们如何判定哪些可以完成?通过估算每个需求的难度(见下文-估计需求)。最终的结果是一组需求从release Backlog 移动到sprint backlog中。团队在即将到来的一周时间内专注于完成那些需求。
• 进行中——这个简单。当团队成员领到一个需求,他们将它添加到本栏中,展示给每个人他们正在做什么。这意味着员工控制,确切的说是与团队成员沟通。每个人都应该知道自己的队友正在做什么。在上面的图片中,黏贴的便签包含我团队成员的名字。
• 已完成——完成所有的事情！是的,这是已经完成的任务的去处。然而,重要的是定义“什么已经完成。“理论上，迭代结束时, 该次迭代需求的所有的任务和Bugs都应该包含在本栏。

提示：许多团队喜欢将进行中列分割成几个不同的列，这样能更好地定义不同的工作阶段。我们将我们的分为设计、开发和测试。根据你的情况，随意的定义自己的步骤。

完成的定义？

  什么是完成?什么时候你能满怀自信的说,一个需求已经完成了?你是怎么知道的?
  “完成”必须清晰和精确的定义,这样每个人都知道一个需求完成的状态。不同的团队，甚至不同的项目，有不同的“完成”定义。没有明确的规则。我建议你在团队会议上提出这个问题,并决定是需求已经完成应该具备什么条件。这里有一些建议,你可以考虑:

• 创建一个简单的设计。
• 创建一个GUI模型。
• 使用TDD（测试驱动开发）或者确保有单元测试。
• 编码。
• 让另一个团队成员手动测试你的故事。
• 整个系统可以使用新代码可以进行构建、编译。
• 在新代码集成到系统中，功能或验收测试能够通过。

  在定义“完成”时可以考虑这几个方面。选择并使用那些对你团队有必要的方面。另外, 随着时间的推移别更改“完成”的定义。如果你注意到你的定义变得过时，你可以考虑删除或添加必要的一些元素,而不是忽略。
  在上面的图片中,绿色的便签描述了每个部分中哪些是我们认为必须要做的。

填充板

  这是我们自己的问题。在此之前,我们没有使用便签进行计划。我们使用软件来跟踪用户需求和缺陷,但是,除此之外,我们什么都没使用。午饭后,我们的敏捷管理者提供了大量的彩色便签。在准备了一打便签后,他向我们解释这些便签的作用。

用户故事

  用户故事是一个特征或功能的简短定义。
  这些代表我们想要实现的主要功能。用户故事是简短的，用一句话定义特性和功能。它被称为用户故事,是因为它从用户的角度提出的。当然,这个用户是使用我们产品的人。这个人可以属于一个或多个不同类型:可以是系统管理员，受限用户，经理等。
  用户故事的例子就像,“作为一个使用者,我想与我的队友共享一个文件夹。”
  在这点上,我们没有产品负责人这个概念,所以我们的敏捷管理者虚构了这些故事。这在刚开始的时候是可以接受的,但我强烈建议你分开这两个角色。否则, 敏捷管理者怎么和产品负责人就待迭代需求进行商议?
  你可能会认为,“为什么要商议?实际上一个人决定什么时候做什么不是更好?“不。这两个角色会受一个人对系统或项目观点的影响。两个人，在另一方面,有一个更好的机会为团队提供更客观的路径,确保达到最终目标(更有价值的软件)。
  产品负责人应该定义用户故事；团队应该商议如何实行用，scrum管理者代表团队。
  用户故事定义一切新的,需要做的事;他们在任务板上由黄色便签描述的。

缺陷，缺陷，缺陷

  跟踪你的缺陷是非常重要的。
  我们也将Bugs写在任务板上。你看到那些红便签了吗?这些都是我们为了下一个版本的发布需要修复的bugs。
  不同的团队以不同的方式对待错误。我们的团队将Bugs和故事混合,我们总是会在下一个迭代版本开始时修复bugs。
  我知道一些团队会将三个迭代版本的bugs进行堆积，在第四个迭代期进行修复bugs。一些团队则是在每个迭代版中以bug /任务的比即25/75比例进行修复。甚至，另一些团队可能早上进行故事开发,午饭后进行bugs修复;这只是取决于公司的规则制定。
  你应该为你的团队寻找最好的解决方案,当然,保持记录你的Bugs。将bugs写在便签上,这样您可以跟踪你的系统的问题并且解决这些问题。跟踪你的bugs是非常重要的。

任务或子需求

  任务从开发人员的角度来看是写简单句子。
  理想情况下,每个故事应该足够短并且能相对轻松地完成,但将故事分割到其他的故事是有困难的。有些项目根本负担不起这种可能性。不过,你会发现几个团队成员可以一起执行一个大的需求。将大量工作划分为更小的、更容易管理的子故事是很重要的。
  有一种将大故事分为任务的方法。任务从开发人员的角度来看是写简单句子。例如,前面的文件夹共享的故事可能分为几个任务,如:“创建UI分享”,“实现公共共享机制”,“实现访问控制功能”,“添加访问控制复选框”,等等。关键是,每次将故事分解成更小的任务时必须要多考虑。当你分析每一个细节后，你的团队将会更好的控制掌握每个故事。
  在看板上我们用淡蓝色便签代表任务。看看最后一列(“完成”列),你会发现我们的任务在用户故事便条纸下面。这个故事分为四个任务。

技术任务

  为了将任务,需求,或迭代作为一个整体结束，我们需要制定一定的规则。这些任务通常是相关的基础设施即服务,但你可能会发现有些任务需要根据系统修改。这个过程可能是也可能不是一个故事的一部分。例如,您可能会发现为了实现应用程序的共享功能必须安装第三方应用程序。这是我们的用户故事的一部分吗?可能,但也许不是。
  我们确定这些任务应该脱离实际的需求。这有助于我们更好地跟踪这些额外的任务。在看板上,你可以找到这些任务在绿色的便签。有一个在sprint backlog,有三个是在测试中。

技术需求

  对于一个没有任何敏捷和Scrum经验的年轻团队,最好是用分解需求突出这些任务。
  这些是基础设施即服务的需求,如更新自动化测试系统,配置一个新服务器,以及其他使我们的日常开发工作变得更加容易的操作。在某种程度上这些都是必须完成的事情,但不直接与开发相关。
  你不需要把这些变成独立的需求。事实上,我知道团队没有分离这些待办事项。在几个月前，我们团队调整了技术需求,决定基础设施即服务与其他任务一样重要。然而, 对于一个没有任何敏捷和Scrum经验的年轻团队，最好是用分解需求突出这些任务。所以,我建议你应该试一试。这可能对你有效,如果没有,那你把基础设施即服务规划放到任务板上,以不同的颜色标签存在。

最大的挑战：评价

  在规划会议期间, 我们确定下个迭代版本的用户故事以及待修复的bug。这听起来简单,但实际上,很复杂。
  产品负责人会提出一系列的需求。这个列表通常包含的工作多于迭代版本能完成的数量。Scrum管理者和团队需要一起说服产品负责人，在这个版本期间什么是可以完成的。随着时间的推移,这个过程变得更容易,因为产品负责人掌握了团队的进度。版本的每次迭代提高了团队的效率,从而让更多的需求被完成。达到这个效果的关键是团队有激情和愿景!
  现在,产品负责人想要制定超过我们一个版本可以完成的需求。从产品负责人提交的需求中，我们需要估计我们可以完成的工作量。

需求点

  需求点是最常见的一种估算需求、bug或任务的方法。他们不一定是最好的方法,但他们确实一个不错的方法。
  那么需求点是什么呢?在项目开始阶段,团队在看板上寻找最简单的需求点。不在意困难与否,或者需要多长时间才能完成。当他们发现最简单的需求,会把它作为参考点。例如在某些项目中，10分钟内固定UI元素这样简单的需求，在复杂的系统下可能需要三个人花两个小时来完成。现在,可以此为基线评估其他需求和bug并将它们分配成点。
  这看起来似乎很困难,目前有评估需求点的方法。这里介绍两个:

• 使用斐波纳契数列（Fibonacci number）——1、2、3、5、8(也许13,但13-sized的需求对于我来说太大了)。
• 使用2的幂次方 – 1,2,4,8（也许是16，但是这个数字是要避免使用的）

  你可以自由选择任何你感觉最舒服的数字。敏捷!也许你想使用递增2的方式,因为你的任务使用这个方法能更好的估计。那么我为你欢呼！

信号灯

  数字是伟大的,许多技术人员爱它们。然而,你可能会发现,在某些时候,程序员开始将需求点与时间相关联。他们会想,“我花了两天的时间来做这个。它值5分”。这是错误的。需求点不能与时间相关联。
  使用信号灯颜色可以帮助缓解这个问题。团队可以将需求与颜色相关联而不是与数字关联。几个月前，我们的团队就使用这个方式，它极大地帮助了我们。

当然,每一种颜色都有不同的意义

• 绿色意味着一项简单的任务,可以在接下来的版本中完成。
• 黄色指的是一个艰巨的任务——需要几个团队成员更多的努力。在下个版本中完成它的机会是很高的。
• 红色标签分配的是极其困难的需求点,有可能不能在一个迭代版本中完成。这样的需求应该比较少,除非你采用一个星期冲刺,五天是一个很短的时间。

T恤尺寸

  数字比较丑陋，颜色太艺术。那就轮到t恤尺寸出场!它需要放弃比较需求的复杂性和竣工时间。简而言之,代替数字,使用像S,M,L XL,XXL的尺寸来估计需求。
  我个人从来没中意这种估计方式。但是,有人认为这是最好方法。如果你觉得这主意不错的话，可以试试。
  产品负责人、股东和经理需要知道迭代版本结束后会发生什么。他们必须决定是否发布已经完成的需求,必须知道何时功能是准备好的。产品开发周期的最后阶段发布所有新功能不是一个好的方式,更频繁的发布最有价值的功能才是一个更好的方式。为实现这一目标,他们必须在短期内了情况,而这些信息来源于团队。因此,团队应该最准确的估算他们在一个版本中所能做的工作。

原文地址：https://code.tutsplus.com/tutorials/scrum-the-story-of-an-agile-team–net-29025