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

  Scrum是最经常使用的一种敏捷技术。它不是编码相关的;相反,它更侧重于组织和项目管理。如果你有空,让我告诉你关于我所工作的团队,和我们团队如何采用Scrum技术。

一个小故事

Scrum的根源实际上早于敏捷时代。

  Scrum的根源实际上早于敏捷时代。第一次提到这种技术可以追溯到1986年,由 Hirotaka Takeuchi 和 Ikujiro Nonaka为商业产品开发所提出的。首次正式定义Scrum是由杰夫•萨瑟兰和Ken Schwaber在1995年在论文中写到的。
  在2001年，敏捷宣言出版后，由Ken Schwaber和Mike Beedle合著的SCRUM的敏捷软件开发这本书和SCRUM 越来越受欢迎.

一些事实

  Scrum给出了一系列规范,鼓励团队去跟进。它还定义了几个演员——或称为角色（如果你更喜欢这个术语）——加上产品和定期计划的迭代过程。这里有几个工具很适合Scrum过程。我将在本文中引用一些,但我认为最有用的工具是白板和便签。

“Scrum最佳实践”列表是不存在的,因为团队和项目背景的实际情况胜过其他注意事项。——Mike Cohn

角色

  就从猪和鸡开始说吧。鸡问猪是否有兴趣一起开一家餐馆。鸡说,店名可叫做“火腿和鸡蛋。猪回答:“还是算了吧,谢谢。这样我是生产人员,但你只是个参与者!”
  这就是Scrum !它指定一系列具体的角色,其中分为了两组:

• 生产人员——那些直接负责生产和最终产品的交付的人。这些角色作为一个整体,包含了团队、其中的成员、scrum负责人和产品所有者。
• 参与人员——代表着对这个项目感兴趣,但不直接参与生产和交付过程的人。这些角色通常是利益相关者和经理。

我们是怎么开始的

  一切都要基于奉献和意愿。如果希望团队高效、有创造力、并且能够按时交付，就需要有人去尝试一些敏捷技术。不管scrum是否适合你的团队，但是毫无疑问从它开始是一个好的选择。发现你的团队中有人愿意帮助别人，或者你愿意承担引入Scrum的责任。
  你可能会问为什么你应该关注其他像我这样做Scrum的团队。因为你应该关注的是我们都是如何通过借鉴由其他人做成功的，尤其是那些做的很好的事例，来学习和做好Scrum的。——Mike Cohn
  我的团队是一个很有才的团队，已经了解很多关于敏捷的东西了。我们从瀑布开发转向一个更敏捷的过程，并且经常发布。我们成功地每三到六个月发布一次，并且每个版本的bug数量都很少。
但是，我们依然远没有达到我们今天的水平。我们忽略了过程，或者说是规则，这迫使我们去改变对于产品和过程的一些看法。就在那时，我们的团队经理向我们介绍了我们那时从来没有听过的一个词——Scrum。
这个人承担的角色是Scrum管理者。

Scrum管理者

  Scrum管理者无疑是最重要的角色之一。这个人是负责连接产品所有者（下文中定义）和团队（下文中定义）的桥梁。这个人通常拥有强大的技术知识，并且积极参与开发过程。他或者她也会与产品所有者沟通用户需求，并且安排一些代办需求。
  Scrum管理者协调的是整个开发过程，不关注微管理（这个团队自己组织）。但是为了提高团队的互动和自组织能力，在这个过程开始的时候，Scrum管理者可能会选择部分团队的模块来进行微管理。
  Scrum管理者有很多责任，我将在这个讲解的过程中逐一提到。

介绍术语“小版本迭代”

  在我看来，我们三到六个月发布一次没有任何问题，但我原先无法想象我们有如此频繁的发布计划。我认为这太快了，而且并没有提供完整的调试产品所需的时间。不过接着我们的Scrum管理者给我们介绍了这个词“小版本迭代”。
  迭代：是搭建Scrum的基本单元。通常经过一周至一个月的版本迭代，产品会处于一个稳定的状态。
  这听起来很不可思议。版本每周都稳定—-这不可能！但是事实上是很有可能的。首先，我们减少我们的生产周期，从三个月到1个半月，直到只需要一个月。在这期间，我们的做法不作任何变化。需要做的只是再制定一些让周期小于30天的版本迭代规则。规则不是有魔力的；只是必须对项目有益。
  如果我没记错的话，第一个明显改变是出现在构建过程中引入版本迭代计划。

版本迭代计划

  这是其中一个Scrum会议推荐的建议。在新的版本迭代之前，团队、产品负责人、Scrum管理者就要开始计划下一次迭代。会议可以开一整天，但是更小的版本只需要2个小时左右。
  我们这个过程主要是审查产品需求，并且决定哪部分的用户需求要被纳入下个版本。这些是由整个团队、Scrum管理者和产品负责人共同讨论后决定的。

产品负责人

  通过设想哪些小功能将提供最大的价值来制定产品方向，这可能是最难的任务。
  这个人负责定义用户需求和维护产品需求。他或者她也是团队和更高的管理层之间的桥梁。产品负责人需要评估来自股东、更高的管理层、用户和其他渠道反馈来的需求（如bug报告、用户调查等）。
  他或者她应该重视这些需求，为股东在最短时间内获得最大的价值。产品负责人可以通过制定一个可以及时完成的最有价值的用户需求来实现。这听起来很复杂—-确实是这样！实际上，通过设想哪些小功能将提供最大的价值来制定产品方向，这是最难的任务。但从另外一个角度来看是很简单的。比如有可能有一千个用户需要这个特定功能。在这种情况下，正确的选择是显而易见的。
  若是一些用户代表了大部分的用户群，这会为你新增这个特殊功能增加了保障。
  但是，怎么样实现到让100%的用户群的对这个特定功能都有需求？这是一个艰难的抉择。所以你可以选择增加当前用户的忠诚度，或者增加用户群。哪个是正确的选择？这一切都取决于当前的业务方向和产品负责人为产品所做的一些定位。
  在我们公司，这些决策会知照到整个团队。这不是一个Scrum过程的要求，但这个方法对于新团队来说很有用。信息的分享有利于大家理解为什么会有这些决策，以及理解为什么有些可能看似很明显的功能被推迟或放弃实现。

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