选择瀑布模型还是scrum
摘要
Scrum将产品演示作为其默认技术,以了解是否开发了具有正确功能的正确产品。 虽然产品演示非常有效,但也可能会受到限制。 像任何研究和验证技术一样,恶魔有其长处和短处。 这篇文章概述了其他验证方法,因此您可以选择最适合您产品的验证方法。
Scrum中的反馈和数据
收集反馈和数据是Scrum的重要方面。 它使您能够了解是否创建了具有正确功能的正确产品。 Scrum采用三步过程来实现这一目标:创建产品增量,然后将其展示给用户,客户和其他利益相关者。 生成反馈和数据,从而触发产品积压变更,如下图所示。
为了利用此过程,用于收集数据和验证产品的技术至关重要。 如果使用错误的方法,则可能会收集错误或不足的数据并得出错误的结论。 尽管有多种可用的技术,但Scrum仅识别一种:产品演示,该演示在sprint审查会议中进行。
但这并不意味着您应该或不能采用其他技术! 反之亦然:sprint演示可能适用于产品,也可能不适用。 另外,长时间使用单一数据收集方法通常是一个错误。 每种技术都有其优势和局限性,没有一种总是合适的。 因此,您应该选择对您的产品最有帮助的一种,并结合补充技术。
有用技术的选择
为了帮助您选择正确的方法,我在下表中汇总了Scrum中愉快使用的五种技术。 我将在以下各节中讨论每种技术。
技术 | 描述 | 长处 | 弱点 |
产品演示 | 演示最新增量。 听取反馈,并提出未解决的问题。 | 测试有限的功能:帮助人们想象使用该产品的感觉。 反馈立即可用。 | 反馈基于用户听到和看到的内容; 影响用户的危险。 |
可用性测试 | 观察用户如何在受控环境(如实验室)中与原型或产品进行交互。 | 了解用户是否按预期使用该产品。 可能使用分析软件收集数据。 数据立即可用。 | 人工环境:用户不要在野外使用产品; 观察者效应。 |
释放 | 向一组目标用户发布该软件,并使用分析功能收集数据。 | 了解如何在目标环境中使用该产品。 到达更大的测试组。 运行A / B测试。 | 不解释为什么用户以某种方式使用该产品。 可能需要一些时间来收集足够的数据。 |
观察 | 观察用户最好在其目标环境中使用该产品。 | 了解用户如何与产品互动。 | 可能很耗时; 观察者影响和偏见的危险。 |
穗 | 创建可执行原型以解决体系结构风险。 | 了解架构或技术选择是否可行。 | 可能导致过度设计的解决方案。 |
产品演示
顾名思义,产品演示将最新的产品增量提供给适当的用户,客户和内部利益相关者。 演示者解释了用户将如何使用该产品来完成工作。 产品演示在早期的sprint中特别有价值,因为它们使您可以立即获得有限功能和很小增量的反馈:通过将增量包装在故事中,人们可以想象使用该产品的感觉。
这种优势也是一个主要弱点:反馈是基于人们的见闻,而不是基于他们实际使用产品的经验。 此外,演示者可以通过谈论产品或提出封闭的问题来不适当地影响用户,而像高级经理这样的有能力的人可以影响小组的意见。 我的文章“ 作为敏捷市场研究技术的产品演示 ”分享了有效使用产品演示的更多技巧。
可用性测试
可用性测试可让您了解用户如何与您的产品进行交互。 可用性测试通常在受控环境中进行,例如会议室或实验室。 目标用户被要求使用最新的产品增量执行任务,该增量可以是纸质原型或可执行软件。 然后,您观察并记录人们如何使用该产品,然后可以通过向参与者询问他们的经验和印象来结束测试。 通常可以在sprint审查会议中进行测试。
尽管可用性测试可以快速生成真实的用户数据,但是与“野外”(即在将要使用产品的环境中)使用产品相比,人工环境和观察结果可能导致用户的行为有所不同。例如,在家,在工作,在汽车,在火车上。 这就是下一项技术的用武之地。
释放
发布软件意味着向一组目标用户访问该产品的早期版本,并要求他们在其目标环境中使用该产品。 然后由分析工具(例如Google Analytics(分析))记录使用情况数据。 该产品现在在其目标环境中使用,并且可以使用更大的测试组,从而降低了收集不代表目标市场的数据的风险。 使用正确的分析软件,您还可以收集数据,例如谁在何时何地与哪个产品功能进行交互以及人们偏爱某个功能的哪些变体(A / B测试)。
不利的一面是,该技术无法解释人们为什么使用某个功能,或者为什么不使用某些功能。 此外,还有一个延迟:需要花一些时间来下载,安装和开始使用最新的增量,才能有足够的数据来得出正确的结论。 在Scrum上下文中,这意味着您要么必须推迟下一个冲刺,要么继续使用其他功能来减轻朝错误方向移动的风险。
如果您主要使用发行版,则您的sprint审核会议会更改:现在,它用于同步内部利益相关者并审核项目进度,而不是验证产品。
观察
观察意味着在用户在目标环境中使用产品时要仔细观察他们。 这可以帮助您了解人们如何与产品互动以及如何使用其功能。 它还使您可以与用户汇报,并在与产品交互时了解用户的体验。
观察的主要缺点是它们很耗时,尤其是当您要观察多个用户时。 用户在观看者时的行为也可能有所不同(监督效果),并且您自己的偏见可能会干扰您清晰看到的能力。
穗
尖峰是用于测试体系结构或与技术相关的假设的原型,例如,Enterprise JavaBeans将能够提供所需的性能。 创建它们通常很便宜,可以快速生成相关知识,并让您查看是否可以满足关键的非功能性要求 。
如果您过多地使用尖峰,如果您更担心如何构建产品,而不是为什么以及如何构建,则会成为问题。 如果发生这种情况,那么结果就是设计过度的产品和以解决方案为中心的思维方式,而不是以用户为中心。 我曾经遇到一个团队,该团队已经建立了将近两年的峰值,而不必显示任何可移植的代码。 告诉他们停下来思考用户,这对他们来说是非常震惊的。
选择正确的技术
讨论的所有技术都有其优点和缺点。 虽然您应该始终选择能够帮助您达到冲刺目标并有效验证增量的技术,但我发现在早期冲刺中使用产品演示,可用性测试和峰值以及在后期冲刺中进行发布和观察是一个有用的经验法则。 ,如下图所示。
上图试图平衡不同技术的优势和劣势,并且它对应于一种风险驱动的方法,其中在早期冲刺中解决了关键风险和关键假设。 (有关Scrum中的更多信息假设,风险和学习,请参阅我的文章“ 正确掌握焦点:Scrum中的学习和执行 ”。)
无论选择哪种技术,都不要误以为要长时间使用单一技术。 每种技术都有其优点和缺点,没有一种技术是完美的。 结合使用定性和定量技术(例如发布和观察),以利用它们各自的优势并缓解其劣势。 不要害羞地尝试各种技术来找出最适合您产品的技术,并使用冲刺回顾来回顾其有效性。
选择瀑布模型还是scrum