超越 Sprint 0：整合团队的另一种选择
已发表: 2022-03-10Scrum 是世界上最流行的项目管理方法，超过 72% 的团队使用 Scrum 或混合 Scrum。 如果您从事 Web 开发工作，那么很有可能您正在以某种形式使用 Scrum。
Scrum 的当前趋势是“Sprint 0”或其更具艺术气息的表亲“Design Sprint”。 关于这些是否是真正的冲刺（它们不是）已经写了很多，但关于它们为什么存在，为什么它们如此顽固地坚持，以及存在哪些替代方案的说法却很少。
我个人喜欢 Scrum，我一直在寻找方法来逐步改进我的实施方式。 在这篇文章中，我想分享我已经融入我的工作流程的方法，并且在合并 UX/UI 和开发以及创建更强大的项目愿景时，我发现这些方法很有帮助。
在我们开始之前的一些快速定义：
- 冲刺 0
团队创建 Scrum 项目所需的指导文件的最初努力：愿景、产品待办事项和产品发布估算。 - 设计冲刺
团队为发布的其余部分创建指导设计的最初努力。
为什么 Sprint 0 和设计 Sprint 存在
说“Sprint 0 不是真正的 sprint，不要这样做”，这一切都很好。 但是这些冲刺式的改编存在是有原因的。 许多团队采用它们是因为他们的项目有超出 Scrum 直接范围的未满足需求。 我的观察是 Sprint 0 和设计冲刺最常用于解决以下情况：
- 缺乏强烈的指导性愿景；
- 缺乏将设计集成到开发工作流程中。
Scrum 流程假设产品所有者已经制定并传达了清晰的愿景。 但是，如果您从事的项目的愿景是弱的、错误的或不可见的，请举手。 我也是！ Sprint 0 是开发团队填补愿景空白的尝试。 这不是最糟糕的想法，那么问题是什么？ 从敏捷的角度来看，Sprint 0 不是迭代的，没有利用整个团队的才能，并且提供了模糊的结果。 在你指出“嘿，这里真正的问题是 Scrum 团队不应该做产品负责人的工作”之前，我实际上相信跨学科敏捷团队是开发强大、现实的最佳环境之一愿景和目标。
我提出了一种更灵活的构建愿景的方法，我已在无切换项目中成功使用过该方法。 我将探讨使用这些类似 sprint 的调整的两种情况，并描述这种替代的第一个 sprint 如何更好地支持敏捷工作流程。
愿景和原型冲刺
在第一种情况下，缺乏强烈的愿景，指导文档或想法太弱，无法真正开始 Scrum 项目。 对于任何流程（包括 Scrum），您在开始旅程之前都需要指导。 敏捷非常适合找出实现目标的最佳方式，但产生最初的愿景不在其范围之内。 事实上，Scrum 完全缺少对开发过程开始所需愿景的描述。 无论是否真的是 Scrum，Sprint 0 只是一个在前线的网络团队，使用他们拥有的工具，试图在开始做之前弄清楚他们需要做什么。
Sprint 0 的真正缺点是，在您掌握的信息最少的时候为项目构建指导文档对随后的开发过程的价值很低。
不符合迭代出现的现实的指导项目愿景要么需要经历另一个 Sprint 0 的昂贵过程，要么更经常被忽略。
更好的选择是原型冲刺：第一个冲刺让整个团队参与其中，同时实际构建初始原型本身。
原型 Sprint 视觉过程
头脑风暴的想法被尽快转化为低视觉保真度的工作原型。 原型是用功能性的前端 HTML 和 CSS 框架编写的，即团队的共享语言。 不是每个人都能理解规格表或愿景声明。 每个人都可以理解一个网站，并且交流更容易，并且包含更广泛的学科。
在第一个 sprint 结束时，原型已准备好在多个方面进行初步测试，包括一般可用性、可访问性和移动响应能力。 在我的团队中，这是一个有效且重要的完成增量。 原型冲刺还产生了初始产品积压。 随着积压项目在未来的冲刺中完成，原型获得了保真度。 原型不是一次性代码——它是基础。
在某些项目中，在生产原型时会生成书面愿景。 但在许多项目中，原型就是愿景。 它以团队的共同语言说话，当然，它永远不会与产品脱节。
例子
下面的示例是一个电子商务应用程序的工作原型，它是根据初始 RFP 中的粗略轮廓完成的。 尽管它很粗糙，但它有助于将团队的精力集中在生产性方向上，跨越许多潜在的干扰和陷阱，专注于功能标准。
初始原型通常会导致需求更改，这只是最好的猜测，直到根据用户体验进行。 例如，我们从上面显示的原型冲刺中获得的一个见解是，定价和“购买”按钮最初在页面上太低了。 最初的要求是将它们放在产品信息下方和推荐上方，但功能原型很快表明层次结构不是很实用。
曝光的另一个功能是画廊图像最初被要求很大并且可以拉伸页面的整个宽度。 原型不是向利益相关者提出假设的原因为什么这不起作用，而是能够以整个团队都理解的共享语言来展示问题。 在与利益相关者的一次权力会议中，我们迅速将这个页面重新组织成一个普遍认可的层次结构。
由于原型天生易于访问且响应迅速，我们可以立即开始在多种设备和技术上进行测试。 尽管设计（如果在这个早期阶段甚至可以称之为）故意保持低保真度，但很明显桌面上的年份切换器消息在移动设备上太大并且干扰了可用性（左）。 我们迅速更新了原型，在标题中使用了一个较小的切换器（右）。
在这个原型冲刺期间，其他一些问题很快就暴露出来了：
- 客户在点击功能导航后，立即意识到他们错过了规范中的一个主要功能组件：博客。 这影响了估算和时间安排，但我们能够快速调整。
- UI 团队很明显，定价显示过于复杂和混乱。 我们与客户一起探索了其他可能性，并能够在原型冲刺期间快速制作原型和用户测试多个解决方案。
一旦开发开始，愿景就不会成为障碍或过时，而是在原型冲刺中共同开发愿景和功能标准并相互支持。 而且由于愿景是由团队产生的，因此无需向团队移交，并且可以轻松避免开发过程中的那个风险时期。
设计和原型冲刺
在第二种情况下——缺乏设计与开发的整合——通常是你会看到使用“设计冲刺”的时候。 我发现这个方向比 Sprint 0 更适得其反。将设计集成到复杂的开发过程中的挑战是真实的，但设计冲刺是一种弄巧成拙的方法。 设计冲刺是针对症状的创可贴——建立集成团队的挑战——但没有解决根本问题——理解和满足用户需求的挑战。 将设计预先加载到一个 sprint 中避免了集成的挑战，但是集成和增量设计过程的好处以及它为理解和接触用户打开的窗口完全消失了。
我在无移交项目中使用的原型冲刺是设计冲刺的高效且完全敏捷的替代方案。 它是协作的，从项目的最早阶段就融合了 UI/UX 和开发。 即使是最有经验的设计团队也可以从其他学科的参与中受益，而且至关重要的是，它可以确保代码和设计目标不会交叉。
通常，设计冲刺也有望充实愿景。 这是一个绝望的举动，基于一种模糊但有见地的理解，即设计过程比开发更能产生愿景。 然而，设计产生的愿景并不能替代真正的、协作的、团队范围内的努力。
可怜的设计师背负着生成最终产品来启动开发的任务，而没有必要的跨学科信息来使这项工作真正有价值。 尽管具有技术知识和更多经验的设计师将有更好的机会做到这一点，但这仍然是非常冒险的。 由于在阶段结束时没有潜在的可交付产品来针对猜测进行测试，因此继续开发。 如果设计没有达到目标，或者如果规格发生变化，则可能会导致长时间的延迟，因为它会返回给设计团队。 敏捷的核心是风险管理过程，我们可以做得比以固有风险设计冲刺开始我们的敏捷项目更好。
原型冲刺设计过程
与更传统的设计冲刺相比，最重要的变化是，在原型冲刺期间，团队直接从纸上到原型，并跳过使用 Sketch、InVision、Photoshop 或其他数字布局程序。 它们在这个阶段充当了视觉拐杖，似乎很快就会引入价值（因为好的设计师做出好看的东西），但是这么早的高保真模型的真正价值非常低，而它引入的潜在危险——婚礼利益相关者的错误解决方案——高。
这些工具最适合高保真平面模型，但最初的原型既不高保真也不平面。 白板、铅笔和纸让团队可以快速通过想法，而不会被他们束缚住。 然后尽快将这种想法转化为功能原型。
每个团队成员，包括设计师，都应该熟悉并能够在低保真阶段直接处理原型。 但如果这是不可能的（或者这是一个长期目标，你现在需要向前推进），那么设计师和开发人员并肩工作的配对方法是好的。 草图可以由设计师描述并由开发人员共同解释，扩大他们对每个观点的共同理解。
例子
下面的示例显示了我们将现有网站的深入分析直接提取为功能原型的过程。 它允许在本地网络环境中评估报告的结果，这与在打印文档中智能分析建议的体验截然不同：
此外，与深入分析文档不同（尽管它很有帮助），功能原型没有行话，并使用每个人都能理解的共享语言和视觉语言。 它以视觉显示向所有团队成员和学科打开对话。
我们在构建此模板时的主要问题是要包含多少设计细节。 因为我们有一个充满分析的丰富文档可供借鉴，所以我们可以进一步开发原型。 但是，请记住，视觉效果可以迅速（并且无意地）从想法领域转移到事实领域，我们保持布局不明确，并将文档提炼成其基本元素和含义。
内部测试使我们进入了一个更加以用户为中心的解决方案的范围内，跳过了许多潜在的问题，但我们有意识地避免在这个过程的早期做出任何精致的设计决策。 重要的是不断权衡所有想法和建议，包括客户的，与已知数据，并记住我们的知识库在这一点上比在项目的任何其他阶段都要小。
保持初始原型低保真且不包含任何“设计”元素至关重要的另一个原因是，团队支持可能会被不相关的视觉元素所破坏，这些视觉元素会引发意外的本能反应。 我们远离颜色，甚至不包括客户徽标（而是使用空白区域或浅灰色框作为占位符）。 对话必须不断地以功能标准为导向，如内容层次结构、可访问性、可用性、语言和意义。 向团队保证“有趣的东西”会到来，但不是在这个早期阶段。
事实上，成功的原型冲刺的一个重要目标是尽可能少地做出前期设计决策。 成功的设计是由用户体验提供的，因此要留出时间让新兴的项目知识为 UI 提供信息。
原型冲刺何时完成
当原型和伴随的工件得到整个团队（包括客户）的批准时，冲刺就完成了，并且认为原型已准备好进行初始可用性和可访问性测试。
早期的功能原型通过规模（页面数量、导航范围和其他主要 UI 元素）、未来复杂性（具有有用描述符的占位符内容，可能一些早期功能编码）和识别需求（需要的特定技术）来实现项目愿景，它们将在哪里部署，任何依赖项）。 有关工具、工作环境和代码堆栈的决策将在整个团队的输入下做出。
对于拥有响应客户的经验丰富的团队来说，达到这一完成增量只需一天时间，但通常持续大约一周且不超过两周。 原型冲刺应该快速推进，超过两周的时间框架可能是一个危险信号。 这可能意味着还有其他问题在起作用。
在原型冲刺期间需要注意的一些常见问题
实施原型冲刺时需要注意的一些常见问题包括：
- 接受低保真度的价值，避免强调视觉效果。 对这一点保持警惕，因为不熟悉这种方法的团队可能需要帮助和保证，因为他们超越了“徽标在哪里”并专注于更深层次的功能和层次问题。
- 上述的不同方面，也要警惕不要依附于你自己的设计/布局想法。 在原型冲刺期间记住没有产生任何宝贵的东西并与最终结果保持分离是有帮助的。 此外，这是保持原型最小化的另一个原因，坦率地说，它相当丑陋。 它的目的是让用户保持分离。
- 领导层的早期流程支持至关重要。 因为整个团队都参与其中，您的客户、您的老板和开发人员都需要用他们的参与、创造力和时间来支持和培养这个过程。 不要成为一个孤独的啦啦队长，你的整个团队需要挥动他们的绒球！
- 沟通不畅是所有团队合作的致命弱点。 原型冲刺不会解决持续存在的沟通问题，但随着整个团队几乎立即投入协作工作流程，它将尽快将它们带到前台。 当您努力达成共识和第一次完成增量时，任何已经存在的沟通问题都会在原型冲刺中尽早出现并且经常出现。 抓住改善沟通的机会，让整个团队参与寻找解决方案。
- 选择正确的前端框架。 如果您还没有，您可能需要尝试各种前端框架，然后才能找到适合您团队工作流程的框架。 我建议研究像 Fomantic 或 Bulma 这样的最小框架，不要被花里胡哨的东西所困扰。 但是，正确的框架始终是适合您团队的框架。
- UI/UX 团队需要开发一个对前端框架的舒适度和访问权限。 理想情况下，他们将直接在原型上工作，避免不必要的交接以及从一种媒体转换到另一种媒体（即从 Sketch 到原型）的需要。 如果您的前端团队不熟悉 CSS 和 HTML，那么配对方法（一名设计师和一名程序员在框架上一起工作）也很有效。
- 最后但同样重要的是，请记住，作为一个团队，你们会变得更好更快！ 运行富有成效的原型冲刺是一项随着实践而增长的技能。
接下来发生什么
第一个 sprint 的完成增量——功能性、低保真原型——为随后的所有 sprint 奠定了基础。 有了一个工作原型，用户就可以立即开始对可用性、可访问性和响应性进行测试，确保未来的 sprint 由 UX 提供信息。
原型冲刺是任何 Scrum 流程的良好开端，但在我的项目中，我们的下一步是转向双轨工作流程，其中 UI/UX 在开发之前工作半个或整个冲刺，进行发现并直观地更新原型以反映新的见解。
在用户体验研究和现实功能需求的支持下，原型有机地发展并变得越来越精致。 这些信息在原型冲刺期间不可用，只会随着项目的进展逐渐出现。 UI/UX 和开发通过双轨敏捷流程反馈到彼此的工作流程中。
没有将设计移交给要构建的开发，也没有将开发的应用程序设计到皮肤。 相反，原型冲刺从一开始就让整个团队参与进来，并为整个项目的协作敏捷工作流奠定了坚实的基础。
原型冲刺产生的指导性愿景并不完美，并且可能会随着学习的更多而改变，但认识到我们在开始时比项目的任何其他阶段了解的更少，这是敏捷工作流程的核心。 当我们通过原型冲刺将同样的理念应用于项目愿景和设计的出现时，结果是可操作的完成增量、真正有用的工件、共享的支持以及可以在整个项目中持续的团队合作和协作模式.
关于代理设置的说明
如果您在代理机构工作，您可能会认为这种方法很难推销。 不幸的是，你可能是对的。 许多机构天生不灵活，并积极争取整体项目交接，通常有官方签字和仔细记录的影响，以在未来做出改变。 在非敏捷组织中提倡原型冲刺是不可能的：它只是不在他们的 DNA 中。 一旦组织接受了敏捷和跨学科团队，他们就可以轻松考虑无移交原型冲刺是否会增强他们的流程。
结论
Sprint 0 和设计冲刺解决了许多 Scrum 团队面临的真正挑战：缺乏远见，缺乏集成设计，或两者兼而有之。 它们是可以理解且合乎逻辑的响应，但它们不能提供高价值或为强大的敏捷团队做出贡献。
用原型冲刺代替它们是解决 Sprint 0 和设计冲刺的缺点的实用方法，同时为未来冲刺期间更强大的敏捷协作奠定基础。
原型冲刺利用整个团队的才能，产生必要的愿景，导致团队第一次完成的增量，并避免项目交接。 通过这个过程，团队建立了项目愿景的共享所有权，并为敏捷精神下的跨学科合作奠定了更坚实的基础。
关于 SmashingMag 的进一步阅读：
- 成为更好的促进者
- 为兼职团队调整敏捷
- 项目回顾的重要性
- 为您的组织带来更好的设计流程