Tommy Norman的《培训视频帮助入门者理解基本的敏捷以及Scrum概念。\

视频运行总共超过九个小时，广义的分为“Scrum基础”和“高级Scrum”。视频运用了动画来解释这些概念。\

“Scrum基础”对敏捷历史，以及敏捷价值与原则如何激发团队持续交付高质量产品，从而快速增加客户价值提供了有用的见解。它涵盖了完整的Scrum框架，从项目发起到执行冲刺（Sprint），再到交付产品增量。它的话题如下：\

• 敏捷历史；\
• 角色、工件，以及Scrum活动；\
• 如何开始Scrum项目；\
• 编写好的用户故事的要点；\
• 如何维护产品待办目录和发布计划；\
• 敏捷估算技术；\
• 如何有效地计划和执行一个冲刺\
• 敏捷工程的最佳实践；\
• 如何在冲刺中融入QA；以及\
• 如何检查和调整流程。

“高级Scrum”深入讨论了Scrum的实施以及采用Scrum的挑战，探索了如何应用敏捷和Scrum的价值与原则来避免常见的陷阱。这部分包括：\

• 关于需求管理的敏捷价值与原则；\
• 如何制作好的用户故事以及何时获得更多细节；\
• 关于质量保证的敏捷价值与原则；\
• 如何在Sprint中融入好的质量实践；以及\
• 把测试用例整合为需求管理的一部分。

InfoQ采访了Tommy，谈论了这些视频课程以及对他的观点进行了讨论。\

InfoQ：有没有什么特殊的原因让您制作一个视频，而不是写一本书？它对听众如何更有帮助的呢？\

\

多年来我一直在教学和展示敏捷及Scrum，所以把这些内容放到培训视频中是一个自然而然的过程。我个人觉得人们从个人培训中会获得更多的知识，而视频比书籍更接近这种方法。我也相信观众用这种方式培训可以获得更多，因为我使用说的方式、用相当多的动画来描述我的观点，从而帮助大家更好地理解。

InfoQ：请详细说明一下概念与机制。让团队理解这个差别有多重要？\

\

很多实施Scrum的人仅仅采纳了它一系列的规则，却没有真正地理解他们背后的原因。Scrum是一个框架，是基于敏捷价值和原则的特定实现。在“Scrum基础”视频中，我花了相当多的时间讲述敏捷的价值、原则以及通用的概念。对于我来说，那些是培训中最重要的内容，因为团队或者组织最终可能因为某些原因需要采用他们的“规则”或其他规则，但隐藏在那些规则背后的基本价值和原则并没有改变。\

当你的团队在实施任何流程时，最重要的是要理解差异。例如，很多团队的每日例会遵照文中的规则。他们问三个问题，保持会议在15分钟之内，他们每天在同一时间和同一点开会等等。但你有时候发现，如果在会议之后你问一些基本问题，例如“团队在做什么？”，“团队现在的主要障碍是什么？”，或者“我们离Sprint目标还有多远？”，你会发现团队无法回答。每日例会背后的价值是给个人机会，Scrum团队可以面对面的交互、审核他们的Sprint计划、决定是否有人需要帮助、并评估他们的进度。如果你遵循这个规则而并没有获得这个会议的价值，那就是浪费时间。\

当人们盲目地遵循这些规则，从中获取很少，或者没有获取价值，那么他们的实施通常会受挫，并且无法得到他们想要的结果。通常他们会说Scrum无效，因为他们完全遵循这些规则，而没有成功。这种货车文化（Cargo-Culture）思想会毁掉任何流程的实施。\

如果团队真正地理解价值与原则，他们会试图遵循Scrum实现，接着他们能够更好地演化他们的机制，因为他们可以做出明智的选择，什么时候实施一些不同的内容。在我早期的教练生涯中，有一个团队的每日例会进行得很困难，然后决定用“走动板”的方法，在他们Sprint的任务板上检查每一个用户故事，看看哪些完成了、在进行中或者遇到障碍。他们并没有明确要求回答这三个问题，而是从这个方法中得到更多的信息，并更好地坚持这一基本价值。在我看来，这才是真正所在。

InfoQ：Scrum团队通过创建产品的愿景来启动项目，一个好的产品愿景的属性是什么?\

\

我认为给与团队目标感是非常重要的，这通常会激发他们成就大事。产品愿景是与团队沟通其目的的简单机制。这基本上是个简单的业务案例，你描述解决方案的目标客户，如何帮助他们解决现有的一些问题或增添价值，有时候解决方案有助于客户到达一个新的层次，以及你公司如何受益。\

我认为好的产品愿景的品质之一是简洁明了。我的一个客户说他们不需要产品愿景文档，因为他们的业务范围文档内容和这个是一样的。这是一篇50页的Word文档，存在SharePoint的服务端。我问团队看看谁知道那篇文档是什么、在哪里，以及谁读过它。答案是没有人。所以尽管内容非常好，而且存在某个地方，但它并没有与团队沟通，在这方面并没有提供任何价值。\

我认为愿景也是一种激励。就如我以前提到的，如果团队相信他们构建产品背后的目的，他们通常会构建更好的解决方案。在我们的入职的前一家公司，公司的CEO/所有人会过来讲述他是如何被激励地创办这个公司的故事，。你剩下的只有那伟大的使命感，并且我因成了它的一部分而感到自豪，我会努力超越，得到更好的解决方案。\

最后，我认为愿景应该突出展示，并且时常重提。所有这些在我们的日常工作中都非常容易，而不会忽略我们实际目标的解决方案。我非常喜欢公司用创新的方式来展示愿景，例如在主要的、高度可见的墙上写下来，并附带客户的感谢信。我认为领导应该时常提起，从而提醒人们为什么他们做现在的事情，并给他们更广泛意义上的目的。

InfoQ：您提到了捕获“如何演示”的步骤。您可否更多地解释一下？可否提供一个例子？\

\

当我写第一个用户故事的时候，我会用简单的要点概述验收标准，就像我最初学的那样。在这些要点中，如果我们漏掉了一些隐含的信息，很快就会发现。这个列表描述了所给功能的各种兴趣点，但并没有真正地给与一个清晰的愿景，它们在一起如何帮助用户实现他们的目标。我们在Sprint中发现事情比较晚，并且有时候不能完成，或者当我们完成了，我们不得不在后续的Sprint中重新审视这个功能。\

我曾读过“如何演示”的方法，并且决定试一试。我们与产品负责人和适用的用户一起合作，描述完成他们的目标需要些什么。这是高层次的用例，特定描述用户的需求，但开始并不是像静态规范那样非常详细。花费一些时间把它转成适当的详细层次，但是，我们一旦开始做，立刻就看到作为一个团队，我们开始更好地掌握这个故事了。我们发现估算变得更好，因为我们更早地捕获了一些隐含的需求，并且我们交付了 与用户真正需求更贴近的功能。\

在修整会议上，就团队和产品负责人如何讨论一个用户故事，我们真正地把这个整合在一起。我们做了很多白板和纸质原型，并且当要实现的用户故事临近Sprint时，我们更侧重于讨论。这很重要，这些“如何演示”的步骤被认为是可协商的，并作为之前对话的提示，因此，当我们在修整会议或规划会议上重新审视一个故事的时候可以再次挑选。\

我们还发现，从一个抽象的用户故事开始，团队很难得到头绪。我们开始更多地用人物角色，并贯穿真正的用例场景。这有助于集中讨论，并让他们更有感觉。不是说“作为一名银行账户持有人，我想要取钱，因此…”,而是说“我是一名忙碌的妈妈，急于让孩子参加足球比赛，并需要用现金到小卖部买东西。”这样我们有更多的讨论。我真的很喜欢这种方式，可以帮助团队更好地识别他们的用户，并开始用他们的声音说出来。

InfoQ：您是如何将测试实践整合到需求管理实践中的呢?\

\

质量应该贯穿到交付软件的整个过程中，而且肯定适用于收集和提炼需求。如果我们得到较差的用户故事，不管我们在工程实践和测试实践中做得有多好都没有用，因为我们可能交付给客户错误的东西。\

所有内容都是始于用户故事，并且我们必须从开始就强调质量方面。这就意味着QA团队的成员要和团队的其他人参与所有的用户故事会议、修整会议以及计划活动。一旦他们参与了这些工作，我们必须还要确保他们是积极地参与，并且我们的测试顾虑及工作与应用程序结构应当受到同等重视。我通常看到的是，开发人员和产品负责人是在谈话中主要参与的人员，而QA并不是同等地参与。我们，作为一个团队，大家必须都要考虑质量，而不仅仅是QA。\

验收标准最终会演进到测试场景中，并且我们越快地做这个的流程，我们测试的工作就会越好。我描述了这个“如何演示”的方法，就是记录验收标准。并且这种方法使之转换成测试更加简单，因为它代表了客户的主逻辑。当团队在修整一个用户故事时，他们需要密切注意验收标准，不仅要识别“如何演示”的主逻辑，而且还要包括替代逻辑和负逻辑（Negative Path）。然而，整个团队都需要为此争取，有经验的QA团队成员对功能的其他逻辑会自然地开始询问。例如，在讨论一个用户故事的时候，其中一条验收标准是用联系人导入文件，我认为QA会开始问当文件地址无法访问该怎么办，如何处理不正确格式的文件等等。这样有助于暴露产品负责人和开发人员开始没有考虑到的一些场景。作为一个团队，我发现这样做的越多，团队就越会按照这样的方式开始考虑，并且我们的用户故事也开始慢慢变好了。\

通常，一旦我们在Sprint中开始做一个用户故事的时候，我们会将所有的验收标准转化成测试。从那时起，我们不再参照用户故事的那些文字，而是围绕着测试用例交谈。很重要的是整个团队一起在做，尤其是产品负责人。现在这个机制（测试用例）中有了自己的验收标准，团队可以很容易地验证他们是否满足一切所需的功能。对于那些会漏掉的隐含需求减少了歧义；并且如果我们后期改变这一解决方案，它可以立即告诉我们它是否与这些标准相矛盾。

InfoQ：在敏捷中您如何管理文档？\

\

认为敏捷就是不编写任何文档，这是一个常见的误区。这是愚蠢之见。尽管我们推崇面对面的沟通和个体交互来收集和提炼我们的需求，但最终我们需要在各个阶段记录和存储这些信息，这通常就意味着某种形式的文档。用了敏捷，我发现我们改变了收集和提炼需求的方法，并且根据何时获得信息、以及获得的详细程度，我们管理他们所使用的技术也发生了改变。\

我还认为这个概念有两种类型的文档：输入和输出。我之所以会经历大多数人都会遇到的有关文档的常见问题，那是因为我试图对这两种类型的文档使用同样的方法。以功能描述说明为例。我们在传统的瀑布式流程中很早就用它来收集有关需求的所有细节。这就是我们认为用户需要的，以及认为需要实现的内容。同样的一份文档，在交付之后，也应该记录我们实际交付的内容。因为大多数的复杂项目都有过修改需求的经历，我现在不得不投入过重的工作到需求管理中，从而保证当有内容改变时，这份单一的文档是及时更新的。文档最初越是正规、复杂，在必须改变的时候就越是困难。\

当我们应用这一概念时，即对输入文档和输出文档使用不同的方法，我们探索了一些好的实践，减少了摩擦和浪费。作为输入记录和管理需求的用户故事是很好的方式。他们相对轻量化，专注并且应该很容易变更。管理需要实现的用户故事，产品的待办列表是非常好的一种机制。用产品待办列表中的用户故事来管理输出的信息却不是很好。一旦你实现了一个用户故事，它就已经完成了它的目标，应该弃之。如果你用更传统的方式来收集信息，这个概念的确让你感到混乱，但在敏捷环境中却很有意义。\

输出的文档应该反映真正交付的内容，而收集和创建这种类型的文档应该有比最初的用户故事更好的方式。作为流程的一部分，如果我们将验收标准转换成测试用例，那么实际上这些测试最准确的表示了系统是如何工作的。如果我们勤于回归测试，就更能真实地表现，因为这些测试经常被验证。接下来我们可以把这些测试内容放入更正规的文档中，例如，如果你需要一个功能描述文档。根据你使用的工具，实际上你可以直接将这些数据导出到一些格式的文档中，这就给团队节省了大量的时间。这也可以让你在系统变更之后容易地更新文档，因为测试作为流程的一部分必须要更新。其他类型的输出文档也许需要更多的手动工作，这可以作为Sprint以及发布层面的完成定义（Definition of Done）的一部分，从而确保他们是软件交付的内在组成部分，而不仅仅是在周期中晚些要做的内容。

InfoQ：您提到敏捷团队中QA角色的转变，可否详细阐述一下？\

\

QA通常被人为是在一个相对筒仓发生的事情，即在瀑布式项目的后期。我看到QA团队在组织中被视为二等公民，并且他们保证质量的工作通常受到妥协。我认为这是瀑布项目合作性质与敏捷项目更加协作性质的对比。\

合作是个人追求自己的目标，并分享相关的信息。考虑一下，开发人员的目标是编写代码用以满足描述的需求。他可能会、也可能不会注意整体的商业目标，他主要关注在如何做好整个流程中自己的那一部分。协作是所有的团队成员有一个共同的目标，并且通常在一定程度上会共担责任。例如，在Scrum 中，团队花费大概Sprint10%的时间帮助产品负责人做产品待办目录修整。这就是团队在收集和提炼需求上共担责任，而传统上这个工作被认为是业务分析师在项目的分析阶段应该自己做的。\

在协作的意识下，我们的QA成员会参与到软件交付周期的所有方面，而不仅仅是后期的测试。他们会帮助提炼需求。他们会参与到适当的设计讨论中，影响最终的解决方案。他们在自己的测试工作中还会引入其他团队成员，这是很大的改变。我发现大家对质量的理解有了真正的思想意识，而不仅仅认为他们的目的就是找到缺陷。

InfoQ：您打算对敏捷做更多的事情吗？\

\

我承认，从在观众面前讲述这些材料到更具结构性的录制视频，这种跨越比我想象的要困难。在制作中需要有更多的准备，并更具严谨。这两个视频是很好的学习体验，并且我肯定愿意制作更多。我确实想过，希望能探索更好地获得在线培训体验的方法，我喜欢Bryan Beecham制作的TDD视频，这是在他的工作坊录制的版本。我非常喜欢更深层次地讨论话题，就像我在第二个视频做的那样，我正在考虑 Scrum和Agile的其他方面，我想我们可以进一步探讨。这不是一个如果的问题，而只是一个时间的问题。

关于作者

Tommy Norman是纳什维尔的 公司的敏捷实践负责人。Tommy Norman拥有CSM/CSP（的认证），以及PSM（）认证，他具有20多年的工作经验，帮助客户使用敏捷以及传统的方法构建解决方案，并6年获得生命周期管理（Application Lifecycle Management）的。他的职业生涯跨越了多重职位，从基本的职位到软件架构师、软件开发总监、QA经理以及敏捷教练。Tommy是 的协调员，和的贡献者，并且还是地区和国内活动频繁出席的演讲者。他有关Agile和ALM的博客地址是 ，并且在Twitter. 有他几乎所有的内容。

查看英文原文：