我的组织目前正在实施 Scrum。在处理产品积压项目以更改某些业务逻辑的处理方式时，我们意识到某些业务逻辑存在缺陷。PBI 及其验收标准目前面向修改现有业务逻辑的实现。PO 认为对业务逻辑本身的这种改变是一个高度优先的事项，应该以某种方式融入到冲刺中，开发团队也同意这一点，特别是从开发的角度来看，同时做这两件事是很有意义的。
然而，我们不确定修改验收标准或创建新的 PBI 并立即将其纳入冲刺是否更有意义。我个人倾向于新的 PBI，因为我觉得这是一个独立的故事和一套与原始 PBI 不同的验收标准，而且我对在冲刺中期改变验收标准持怀疑态度。PO指出，这项新要求和原PBI将同时实施，如果不满足新要求，原PBI就没有意义。因此，PO 认为调整原始 PBI 的验收标准会更合适，而不是创建两个最终反映相同实施的单独标准。
这些方法中的一种是否比另一种更适合 Scrum？
我有一组简单的代码，我试图在其中实现一个带有异步方法的接口。迄今为止的实现都是利用其异步部分并最终等待事物。然而，这个新的接口实现是一个简单的同步操作——不需要任何等待。
当我实现它时，首先感觉很奇怪。其次，Visual Studio 确认了我的不安，并发出警告，告诉我该方法将同步运行——这正是我所期望的，但警告告诉我它对 VS 来说也很糟糕。我应该遵循更好的模式吗？
public interface IActivity
{
async Task<bool> DoStuff();
}
//...
List<IActivity> activities = new List<IActivity>(){
new SynchronousActivityA(),
new SynchronousActivityB(),
new AsynchronousActivityC()
};
foreach (var activity in activities){
bool stuff = await activity.DoStuff();
//do things with stuff.
}
我可以让我的 DoStuff() 实现执行如下操作：
await Task.Run(() => DoStuffSynchronously());
这将使我的警告消失并感觉更“正确”，但我不确定这比仅仅将 DoStuff() 实现编写为同步签名有什么好处。