很多时候，公司在真正理解敏捷意味着什么之前就开始着手“实现敏捷”。然后开始出现问题，也没能达到预期，这就让所有人都在质疑完全“实现敏捷”的价值，还损害了您实现这一目标的机会。
事实是，敏捷化将提高团队的生产力并实现更快的项目交付，但前提是每个人都能就游戏规则达成共识。加入来自电子商务巨头 Gilt 的 Heather Fleming 和 Justin Riservato，他们将讨论为什么就敏捷原则达成共识比实施流程更为重要。
具体来说，Heather 和 Justin 探讨了三个重要问题的答案，任何团队在开始敏捷之旅之前都需要准备好回答这些问题：
- “但是你什么时候能完成？”为什么摆脱截止时间的概念对敏捷来说最重要（也是最困难）。
- “这是我的首要任务，但我要等到下周才能与您见面。”当您的业务合作伙伴不能（或不会）成为团队的正式成员时该怎么做。
- “我只想编码。为什么我必须参加这些会议？”为什么实施 Scrum 并不是迈向敏捷的第一步。
观看和学习
问答
在这里，Heather 和 Justin 从本次演示文稿的问答环节中选择了一些最热门的问题。阅读更多内容，更深入地了解如何应用敏捷方法的策略。
Q1：数字敏捷面板与物理敏捷面板？您对他们有什么看法？
A1：这实际上取决于团队设置。团队成员是否都在同一个地方？团队规模有多大？有空间容纳大型实体看板吗？这两件事我们在 Gilt 都做过，但是我们发现，随着我们成长和扩展到数十个团队，JIRA Software中的敏捷面板比物理看板更实用。它们更易于设置和更改，并且更容易与远程团队成员共享。我们喜欢实体看板的地方在于它们很难忽视，就在眼前，非常适合就当前工作进行即时讨论，当然，您也可以采用每日短会的形式。
Q2：如何与不关注或不了解敏捷流程的经理或客户合作？有时候我觉得自己像个不成功的工作流程教练。
A2：重要的是要考虑您的操作顺序。如果您打算在敏捷流程中与那些不相信它的人一起工作，那很容易操之过急。使这项工作发挥作用最重要的一点，就是在执行流程之前就理念达成共识。过去，我们通过观察团队在当前流程中遇到的具体问题并以敏捷的方式解决这些问题来做到这一点。您能否向您的经理或客户介绍他们想要解决的实际问题，以及如何在敏捷框架中处理这些问题？您能否逐步实现敏捷，而不是在整个流程中进行重大转变？然后，随着团队工作得更好，您可以开始以这种方式逐步显示真实的结果。简而言之，采取敏捷的方法来实现敏捷。;)
Q3：当项目是固定出价和/或固定时间表并有一套要实施的要求清单时，如何实施敏捷流程？
A3：首先，如果有固定的时间表和固定的实施要求清单，就不可能成功完成一个项目，那么有没有办法让所有人同意这是理想状态？围绕截止时间和要求的大多数限制都不是真正的限制，而是愿望。开始讨论您为什么要做这项工作，或者您想解决的问题是什么。如果您真正了解项目的目标和限制的原因，就可以确保团队在正确的时间做正确的工作。写下所有要求，并在旁边写下日期，并不代表所有事情都会按时发生。
Q4：大多数项目的发布日期通常会传达给合作伙伴和客户。在这种情况下，唯一可以协商的就是功能集（但是质量可能会有所下降）。如果有明确的最后期限限制，您会怎么做？
A4：我们认为您的问题里已经包含了答案——可以通过协商范围来做到这一点。如果不这样做，那么质量就会受到影响。认为自己可以刚好达到范围要求是个美好的希望——但您需要确保您的团队根据实际情况工作，虽然这不是人们想要听到的。Heather 就此写过一篇简短的博客文章，您可以在这里阅读。
Q5：您认为应该如何改变 Scrum 的实施方式？
A5：Scrum 最大的问题就是僵化。认为一个单一的高规范性流程对所有团队都有效，无论工作内容是什么，也不管团队成员是谁，非常强制性。我们已经看到它适用于团队，但 Scrum 并不是实现敏捷的唯一途径，许多团队在敏捷方面失败了，因为他们认为他们必须以特定方式实施 Scrum，包括所有规定的工作角色、用户故事、验收标准、会议和工件。Heather 对“Scrum 大师”这个职位也有疑问。;)
Q6：如何防止利益相关者直接影响团队成员？
A6：好吧，一个好的利益相关者就是团队成员。因此，理想情况是将关键利益相关者带入您的团队，这样你们就可以一起工作！如果您遇到的利益相关者只是把事情扔给您的团队，或者在项目期间突然插手尝试改变一切，那么整个团队都必须了解他们在做什么以及为什么这样做，这一点很重要。因此，无论利益相关者与谁对话，他们都会得到相同的答案。这就是你们作为团队而非单独个体组合的原因。您需要经常沟通，并确保每个人都保持同步，朝着同一个方向前进。
Q7：您是根据粗略的数量级估算（以小时为单位）还是基于故事点来估算故事？
A7：我们两种标准都有，有些团队甚至根本没有估算。故事点之所以不错，是因为它们更抽象，并且与任何特定的日历时间无关。如果您的团队因为估算更明确而抵制估算，那么作为过渡的小时数可能会有所帮助。估算的重点是能够分辨您的冲刺太重还是太轻，然后再进行调整，一旦冲刺开始，它们真的毫无用处。我们发现，一旦您与团队合作了一段时间，估算流程就没有必要了。我们都可以看一下工作，然后轻松分辨出它是否适合冲刺。
Q8：与仅仅协调技术和商业利益相关者之间的会议以收集需求相比，您认为具有深厚分析技能和产品知识的项目负责人/经理有多大价值？
A8：几乎所有的价值 :) 协调会议、做笔记等...不是专业技能。任何人都可以做到。虽然实现这些目标很重要，但这并不是您能为团队提供的最大增值。如果您所做的只是管理工作，那么团队质疑您为什么参与其中是很正常的。Gilt 项目管理办公室的每个人都对相关主题以及完成工作所需的工具和技巧有深刻的了解，他们将这些知识带给合作的每个团队。我们中许多人以前是工程师，或者曾在 Gilt 的其他部门工作，并带来了独特的主题专业知识。
Q9：一般来说，Gilt 的团队规模有多大，员工有什么背景？
A9：理想情况下，我们希望我们的团队精简但又足够大，能够自给自足，使他们能够在不依赖其他团队的情况下推进项目。我们遵循“两个披萨”规则：即团队成员两个披萨就够吃了。我们还强烈认为，团队中的每个人都会带来一套独特的才能，无论他们的职位是什么，他们都应该能够将这些才能带入团队。因此，如果传统上由产品负责人负责所有演示，但他们并不喜欢，而有一位工程师在讲故事和吸引观众方面表现出色，那么我们将让工程师在团队中负责演示。您不仅仅是您的职位工作！
Q10：如何管理单独的 QA 团队，尤其是在测试可能在不同于开发的冲刺中进行的情况下？
A10：这是我们更具争议的立场之一，但我们在 Gilt 没有单独的质量保证小组。我们相信在整个开发和部署过程中都要进行自动化测试。团队对其代码的质量负责。如果您有时间和专业知识来编写代码，那么您就有时间和专业知识来为它编写测试。把这个问题交给质量保证团队从来都没有给出我们想要的结果，并且需要大量额外的文档和时间才能让质量保证团队快速上手。
Q11：如果您的团队同时负责多个“产品”，那么在冲刺规划期间，让所有产品经理都聚在会议室里，让他们确定各个产品的相对优先级会有用吗？还有其他方法吗？
A11：停！显然这是行不通的。团队应该有自己的产品经理，而不是为团队以外的多个产品经理处理多个产品。无论谁担任团队负责人，都应该清楚地概述团队的优先级方法，以及他们将以什么顺序根据这种方法处理这项工作的执行。这与我们的观点类似，即“实施流程之前，必须在方法上保持一致。”
Q12：我正在努力让营销创意服务团队变得敏捷。我们有一些交付件必须在特定日期交付（设计要在杂志上印刷的广告）。我们如何将这些项目融入敏捷框架？
A12：敏捷能够处理这样的限制。团队有责任确定必须做什么、何时完成，并相应地规划冲刺。敏捷应该可以帮助您满足截止时间要求，因为它使您能够在每个冲刺中调整优先级和规划的工作（范围）。如果您开始追踪自己的速度，那您很快就能确定自己是否能否尽早达到截止时间。然后，要由一位优秀的团队负责人来协商团队取得成功所需的条件。
Q13：改变目标看起来不像是范围蔓延吗？
A13：是的，确实如此，但我们不称其为“范围蔓延”，因为我们希望在项目期间鼓励改变。敏捷理念最大的优势之一，就是允许您适应无法控制的事物。如果竞争格局发生变化，或者您的业务需求发生变化，或者有新技术可用，您是否真的还要遵循几个月前制定的需求矩阵？如果您想为客户提供最好的产品，那就接受变革并利用它来发挥自己的优势。敏捷中没有“范围蔓延”（在此处插入绝地思维技巧）。
