如何平衡Sprints的速度和客户保守的采用计划？
我更希望短跑持续3-4周，但客户不希望每3-4周采用新功能/功能。现有的客户是保守的，一旦我们满足了他们对功能和功能的最低要求，他们就喜欢在一个稳定的版本上停留超过4周。即使是三个月的周期也会为他们带来压力。
另一方面，较新的客户倾向于有更多的特性请求，并愿意遵循sprint。但这种意愿在我们达到他们的标准后就消失了。
如何平衡对快速冲刺的需求与客户对应用程序更改的保守看法？
我对SaaS场景特别感兴趣。
回答 4
Software Engineering用户
发布于 2012-06-26 16:59:19
在客户准备好之前，把你的短版本保存在内部。然后，在你的四周周期中的一个周期内向客户发布。
如果可能的话，让客户在发布日期之间参与软件评审，这样您就可以将您的sprint保持在正轨上。
Software Engineering用户
发布于 2012-06-26 17:12:36
Sprints与部署
无关
Sprint是针对开发人员的，它们是对交付物的承诺，而不是关于客户的部署。
斯普林特的目标是有一个可交付的。没有实际交付的要求，更不用说部署它了。
我所在的每个团队都会产生更多可交付的构建，超出了运营团队可能部署并提升到生产中的能力。
软件即服务
SaaS是一种特殊的情况，您可以在想要的时候交付您想要的东西，但是不要在没有大量通知的情况下破坏向后兼容性。没有什么可以阻止您在旧API特性的同时部署新API功能，并对旧的API特性进行标记。
有一个非常公开的生命/支持政策，这样每个人都知道该期待什么，什么时候该期待支持结束。
Software Engineering用户
发布于 2012-06-26 17:17:11
如何平衡对快速冲刺的需求与客户对应用程序更改的保守看法？
在我看来，如果客户在3-4周内不需要/不想再次送货，就没有必要进行快速冲刺。
这里的平衡将是改变您的开发周期，以满足他们的期望。
https://softwareengineering.stackexchange.com/questions/154348
复制相似问题
腾讯云开发者
