2020年7月16日星期四08:00

通过启动和桌面检查正确确定需求

撰写者

您曾经去过一家餐馆,收到过与订购的食物不同的东西吗? 

我在玉米饼和瑞士奶酪的煎蛋卷中放了多余的酸奶油,而不是普罗卧酮。 即使很接近我的要求,我也经常把食物退回厨房修理。 对我和厨师来说都是浪费时间,更不用说我一吃饱就饿了。

我在软件开发方面也经历了类似的经历。 作为敏捷组织,我们定期举行潜在客户评论和故事梳理会议。 尽管召开了无数次会议,但有时我还是处于开发人员编写的代码与我所要求的不完全相同的情况。 经过数小时的讨论,这怎么可能? 答案很简单。  Human nature. 别人听到的声音可能有所不同。对于几天或几周前审阅的故事,记忆并不总是可靠的。 同样,除非一个人正在讲故事,否则他/她在团队活动中可能不会100%收听。 

正如任何开发人员和质量检查工程师可以告诉您的那样,构建不符合要求的产品需要重新工作和重新测试,这会影响团队满足冲刺承诺的能力。 那么如何才能减少浪费的时间呢?我部门采取了以下措施,大大减少了不良订单综合症:

  • 故事开始
  • 故事台检查

故事开始

在编码之前先进行故事启动,以确保开发人员,质量检查人员和BA /产品所有者在期望方面保持一致。 提出以下问题有助于确保成功启动。

  • 要求明确吗? 

作为广管局,我会再次审查所有假设,验收标准和任何支持文档,例如用户界面和报告模型。 每个人的记忆都得到了刷新,并且有机会回答问题并确保每个人都在同一页面上。 另外,可以修改故事中的措词或添加其他注释以提供清晰度。

  • 我们是否具备完成此故事所需的所有技术工具和信息? 

我们的开发人员在启动之前进行初步调查,从技术角度确定需要什么。 当确定影响故事完成的问题时,围绕需求的谈判开始。 例如,我们可能会发现一个新功能无法像最初预期的那样利用现有代码。 我经常问,是否可以在当前故事中吸收额外的精力而不影响时间表。 结果可能涉及将接受标准转换为自己的故事,或者将故事从冲刺中完全拉出以进行其他改进。


广告

  • 有阻滞剂吗?

我们通常会提前确定故事的依赖性,并相应地计划冲刺。 由于资源的限制,有时我们发现自己在同一冲刺中正在玩阻塞性或相关任务。 如果在开赛期间被召唤,它会提醒我们协调整个团队的活动,以帮助确保及时完成。

  • 是否需要其他部门的协助才能完成编码或测试?

如果是,我们希望在启动时通知这些小组,因此他们有几天的时间进行相应的计划。  例如,我们可能需要DevOps断开连接以测试失败情况。

故事台检查

完成编码但尚未推送到测试环境时,将执行故事台检查。 参与者包括参与初始启动的同一个人。 活动包括以下内容:

  • 开发人员演示了他/她在根据故事的要求进行交叉检查时构建的功能。

是否满足所有验收标准? 输出(例如UI屏幕或报告)是否与模型匹配? 演示期间是否遇到任何错误? 如果在那时确定,开发人员甚至可以在进行质量检查之前更轻松地在其本地环境中解决问题。 尽早发现问题有助于减少测试期间的错误发现,这等于节省了时间。

  • 提供调整需求的机会。 

演示有时会确定在理论上听起来不错但在现实中效果不佳的需求。 例如,我们可能发现很难看到我所请求的错误消息。 我可以要求将错误移到更突出的位置或以红色突出显示。 如果对冲刺的影响很小,则开发人员和质量检查人员可以同意修改并更新故事。 为了做出更大的努力,我创建了一个新故事,将其放置在待办事项中并确定优先级。

  • 帮助质量检查人员准备测试执行。

开发人员提供有关如何测试故事的输入。 是否有可用的工具来帮助他们验证数据? 测试之前需要什么配置或设置?  还呼吁对现有功能的影响,以便可以对其进行重新测试以确保新代码不会破坏任何功能。

  • 其他参加案头检查的小组(例如DevOPs)知道何时需要他们的协助,并可以安排他们进行质量检查的时间。

最初实施两年后,启动和检查工作仍然是我们开发过程中的重要组成部分。 看到预先投入的几分钟如何使我们免于以后的返工时间,这真是令人非常满意。 总是有改进的空间,但是与此同时,我很高兴地说,现在的发展状况通常就是我所订购的! 

 玛丽亚·里奥斯(Maria Rios)

在财务和质量管理领域中超过25年的业务分析,系统分析和项目管理经验。目前,我在Sparta Systems工作,该公司开发质量管理软件。

©BA Times.com 2020

麦格雷戈徽标白色网站