6
边缘案例的验收标准
我是敏捷团队的产品负责人。我在进行PO验收测试时，通常会记下一些极端情况的注释。对于我来说，发现一些东西然后将其传回给开发人员并不罕见。当我拒绝他的故事时，我正从一位开发人员那里退缩。他说这是不公平的，因为我没有详细说明极端情况以及程序在接受标准中应如何回应，因为他倾向于仅针对我在故事中描述的内容进行编码。我鼓励他问我，因为他在编写代码时碰到了任何极端情况，但是他认为思考极端情况，我的事不是我的工作，我应该为下一个冲刺创造新的故事。 在我的辩护中，直到故事实现后，我才知道他的故事设计，因此很难遍历所有可能性（配置将存储在数据库还是属性文件中？）。为了简单起见，可以说我们有一个故事要为计算器应用添加除法。在理想的SCRUM世界中，我是否有责任在接受标准上添加“零分手处理”，还是他应该在开发过程中认真研究这些情况，以使应用程序不会在5/0上崩溃？需要明确的是，在这种情况下，如果应用程序在5/0时硬崩溃，我将不接受，但如果它记录日志，打印DIV0或其他任何方式来处理错误，则我将通过。不会崩溃