The completed work at the end of a Sprint has to be reviewed by the product owner during the review meeting. If you release mid-way, this may not be the case.
If you feel that the work is complete before the end of the sprint you can:
Add more work by picking highest priority items from the release backlog
Shorten future sprints
Given your work environment description, I would opt for 2.
You may also want to consider another agile methodology that may be more appropriate to your environment.
Having releasable content at the end of a sprint does not preclude mid-sprint releases. In fact, when your team has production support responsibilities, it is required.
I would ask a few questions about these mid-sprint releases though:
1) Does the incremental value of earlier release exceed the cost of deployment? 2) Have you assessed the risk of each of these mini-deployments to ensure they don't backfire and create more work? 3) Can you get customer feedback for these mini-releases to ensure you're releasing what they want? 4) Have you considered shortening your sprints?
"Strict scrum-driven development" (proferred above) is, to me, an oxymoron. The mantra is inspect and adapt. I chaffe at the suggestion that scrum is being wielded as a doctrine against improved responsiveness to your stakeholders.
If you want to perform a strict-scrum driven development - then mid-sprint deployments are heretical. In my opinion is a strict-scrum approach not the best tool to use for scenario. I'd use a more classical approach where you have defined deployment-packages and tasks appointed to them. you develop on a single trunk and if all the tasks for a given deployment-package are done - you deploy it. But be aware of constraints within your code and project.
发布评论
评论（5）
我真的认为在冲刺中期部署到生产听起来是个坏主意。 真正的焦点窃取者。
也许缩短冲刺长度适合您？
I really think deploying to production mid-sprint sounds like a bad idea. A real focus-stealer.
Maybe shortening the sprint length would be something for you ?
Sprint 结束时完成的工作必须由产品负责人在评审会议期间进行评审。 如果中途释放，情况可能并非如此。
如果您认为工作在冲刺结束之前完成，您可以：
根据您的工作环境描述，我会选择 2。
您可能还想考虑另一种可能更适合您的环境的敏捷方法。
我不会在冲刺中期发布。
The completed work at the end of a Sprint has to be reviewed by the product owner during the review meeting. If you release mid-way, this may not be the case.
If you feel that the work is complete before the end of the sprint you can:
Given your work environment description, I would opt for 2.
You may also want to consider another agile methodology that may be more appropriate to your environment.
I would not release mid-sprint.
在冲刺结束时拥有可发布的内容并不排除冲刺中期的发布。 事实上，当您的团队承担生产支持职责时，这是必需的。
不过，我会问一些关于这些冲刺中期版本的问题：
1）早期版本的增量价值是否超过了部署成本？
2) 您是否评估了每个小型部署的风险，以确保它们不会适得其反并创造更多工作？
3) 您能否获得客户对这些迷你版本的反馈，以确保您发布了他们想要的内容？
4）您是否考虑过缩短冲刺时间？
对我来说，“严格的 scrum 驱动开发”（上面提到的）是一个矛盾的说法。 口头禅是检查和适应。 我对 Scrum 被当作一种反对提高对利益相关者响应能力的信条的建议感到愤怒。
Having releasable content at the end of a sprint does not preclude mid-sprint releases. In fact, when your team has production support responsibilities, it is required.
I would ask a few questions about these mid-sprint releases though:
1) Does the incremental value of earlier release exceed the cost of deployment?
2) Have you assessed the risk of each of these mini-deployments to ensure they don't backfire and create more work?
3) Can you get customer feedback for these mini-releases to ensure you're releasing what they want?
4) Have you considered shortening your sprints?
"Strict scrum-driven development" (proferred above) is, to me, an oxymoron. The mantra is inspect and adapt. I chaffe at the suggestion that scrum is being wielded as a doctrine against improved responsiveness to your stakeholders.
如果您想执行严格的 Scrum 驱动开发，那么冲刺中期部署就是异端。 在我看来，严格的 Scrum 方法并不是用于场景的最佳工具。 我会使用更经典的方法，您可以定义部署包和指定给它们的任务。 您在单个主干上进行开发，如果给定部署包的所有任务都已完成，则可以部署它。 但请注意代码和项目中的限制。
If you want to perform a strict-scrum driven development - then mid-sprint deployments are heretical. In my opinion is a strict-scrum approach not the best tool to use for scenario. I'd use a more classical approach where you have defined deployment-packages and tasks appointed to them. you develop on a single trunk and if all the tasks for a given deployment-package are done - you deploy it. But be aware of constraints within your code and project.
你可以看看阿利斯泰尔·科伯恩水晶“橙网”方法。 他根据公共网站的限制调整了敏捷原则。
You could have a look at Alistair Cockburn Crystal "Orange Web" method. He adapted agile principles with the public web site constraints.