At the beginning of the Sprint, the Team needs to come to an agreement with the Product Owner which items they will produce during the Sprint (whatever the length). This happens in the Sprint planning meeting, which is called that for a reason (PLANNING is involved).
During the Sprint, the team delivers the promised items--if they promised to integrate items and put them into prod, that's what they do. There's nothing inherent to Scrum that says when items can or cannot go into prod--it's up to the Team and the Product Owner.
A basic idea in Scrum is that nobody outside the Team (including the Product Owner) is allowed to change which items the Team will work on during a Sprint, once it has started.
Why can the team not plan? They know that shipping is part of the done criteria for any PBI and, as such, the sizing and planning of the Sprint regardless of length should take this into account.
There always exists the chance that management will push for a faster pace at the expense of the team's definition of done, but the team, Scrum Master, and Product Owner (Scrum Team) are obligated to work with management to solve the source of that push.
So here is the result of the discussion on Scrum.org trainer list (so far, I'm sure others will respond). I must say I agree with what was said on the list and find fault in my previous answer as I had forgotten a very important angle on a simple point.
As you might recall though many don't, a Sprint is expected to have an overarching, somewhat fuzzy goal. Many or most, but not all, Product Backlog Items exist in reaching the goal. The easy example I often use is: We want to Increase the Social Networking presence of our application. PBIs may range from showing a Twitter feed, to Liking products, and some Google+ integratione, etc.
The goal gives both a guiding light to why we are building these things, but it also allows the business and team wiggle room in deciding if a sprint was a success if we are unable to complete some of the PBIs. For instance, if we complete the Twitter feed and Facebook Like integration, but unforeseen API stability issues keep us from solving Google+ integration the business may still find success in the sprint because we have in fact "Increased the Social Networking presence" in our app.
This is an easy and natural angle to take as team members, because it gives us an out. Something we are always desperate for by habit in our high pressure environments. The really important angle is from the perspective of the business and I forget this being a coder by trade.
If we ship the Twitter feed when it is done, then ship the Facebook integration when it is done, but then fail on the Google+ integration it may be that the business feels we've missed the mark. Now this is a contrived example, but think of it as something very important like a multi-channel marketing campaign with Sweepstakes, Online games, Text message lottery, etc. Missing one or more of these could mean the business opportunity has passed, because they revolve around the Olympics or something. Businesses do work in this manner.
A continuous flow model might be great, because they see things happening when they never used to, but it's not what Scrum is aiming for which is providing the business with a well oiled machine with a cadence.
Short answer is No. The process model you are describing is more like Kanban than Scrum. With Kanban, the team releases items as soon as they pass through the final stage - in your case this is the Integration stage. With Scrum, the PO has to decide at the end of the sprint whether to release the increment or not. Releasing items mid-sprint is not a best practice in Scrum.
我认为预发布的软件开发或具有自然发布周期的非基于服务器的软件可以敏捷到 CI 完成的程度，并且仍然可以使用 Scrum 进行管理。
那么 Scrum 就介于瀑布式和敏捷式之间。比瀑布法好得多，更接近敏捷，但不是敏捷。
瀑布：一些大的长距离冲刺 Scrum：管理较小的冲刺 敏捷：持续冲刺
I feel I now understand that Scrum is not agile, in the sense that continuous deployment is core to agile, and Scrum is about a cadence of release points about 1 - 4 weeks part with a product owner that decides at the end of the sprint, not in a continuous mid-sprint manner.
In fact, wikipedia states that "Scrum is ... often seen in agile software development", implying not always, and certainly not synonymous.
I suppose pre-released software development, or non server based software that has a natural release cycle could be agile to the point that CI is done, and still be managed with Scrum.
Scrum is just between Waterfall and Agile, then. Much better then Waterfall, and closer to Agile, but not Agile.
Waterfall: few big long sprints Scrum: managed smaller sprints Agile: continuous sprinting
发布评论
评论（5）
在 Sprint 开始时，团队需要与产品负责人达成协议，他们将在 Sprint 期间生产哪些项目（无论长度如何）。这种情况发生在 Sprint 计划会议中，之所以称之为 Sprint 计划会议是有原因的（涉及计划）。
在冲刺期间，团队交付承诺的项目——如果他们承诺集成项目并将其放入产品中，那么他们就会这样做。 Scrum 本身并没有规定项目何时可以或不能进入产品——这取决于团队和产品负责人。
Scrum 的一个基本思想是，一旦 Sprint 开始，团队之外的任何人（包括产品负责人）都不得更改团队将在 Sprint 期间处理的项目。
At the beginning of the Sprint, the Team needs to come to an agreement with the Product Owner which items they will produce during the Sprint (whatever the length). This happens in the Sprint planning meeting, which is called that for a reason (PLANNING is involved).
During the Sprint, the team delivers the promised items--if they promised to integrate items and put them into prod, that's what they do. There's nothing inherent to Scrum that says when items can or cannot go into prod--it's up to the Team and the Product Owner.
A basic idea in Scrum is that nobody outside the Team (including the Product Owner) is allowed to change which items the Team will work on during a Sprint, once it has started.
如果完成意味着正在生产中，则发货。
为什么团队不能计划？他们知道，运输是任何 PBI 既定标准的一部分，因此，无论长度如何，Sprint 的规模和规划都应考虑到这一点。
管理层总是有可能会以牺牲团队对完成的定义为代价来推动更快的进度，但团队、Scrum Master 和产品负责人（Scrum 团队）有义务与管理层合作来解决推动的根源。
If Done means in production, ship it.
Why can the team not plan? They know that shipping is part of the done criteria for any PBI and, as such, the sizing and planning of the Sprint regardless of length should take this into account.
There always exists the chance that management will push for a faster pace at the expense of the team's definition of done, but the team, Scrum Master, and Product Owner (Scrum Team) are obligated to work with management to solve the source of that push.
这是 Scrum.org 培训师名单上讨论的结果（到目前为止，我相信其他人会做出回应）。我必须说我同意清单上所说的内容，并在我之前的回答中找出错误，因为我在一个简单的问题上忘记了一个非常重要的角度。
您可能还记得，尽管很多人不记得，冲刺应该有一个总体的、有些模糊的目标。许多或大多数（但不是全部）产品待办事项列表项存在于实现目标中。我经常使用的简单示例是：我们希望增加应用程序的社交网络存在。 PBI 的范围可能包括显示 Twitter 提要、点赞产品以及一些 Google+ 集成等。
该目标既为我们构建这些东西的原因提供了指导，又为业务和团队在决定是否进行冲刺时提供了回旋余地。如果我们无法完成某些 PBI，那么我们就成功了。例如，如果我们完成了 Twitter feed 和 Facebook Like 集成，但不可预见的 API 稳定性问题使我们无法解决 Google+ 集成，那么业务仍可能在冲刺中取得成功，因为我们实际上已经在我们的应用程序中“增加了社交网络存在”。
作为团队成员，这是一个简单而自然的角度，因为它给了我们一个出路。在高压环境下，我们总是习惯性地渴望得到一些东西。真正重要的角度是从业务的角度来看，我忘记了这是一个以编码为职业的人。
如果我们在完成后发布 Twitter feed，然后在完成后发布 Facebook 集成，但随后在 Google+ 集成上失败，那么企业可能会觉得我们没有达到目标。这是一个人为的例子，但可以将其视为非常重要的事情，例如抽奖、在线游戏、短信抽奖等多渠道营销活动。缺少其中一个或多个可能意味着业务 机会已经过去了，因为他们都围绕着奥运会什么的。企业就是以这种方式运作的。
连续流模型可能很棒，因为他们看到了以前从未见过的事情正在发生，但这并不是 Scrum 的目标，即为企业提供一台运行良好且有节奏的机器。
So here is the result of the discussion on Scrum.org trainer list (so far, I'm sure others will respond). I must say I agree with what was said on the list and find fault in my previous answer as I had forgotten a very important angle on a simple point.
As you might recall though many don't, a Sprint is expected to have an overarching, somewhat fuzzy goal. Many or most, but not all, Product Backlog Items exist in reaching the goal. The easy example I often use is: We want to Increase the Social Networking presence of our application. PBIs may range from showing a Twitter feed, to Liking products, and some Google+ integratione, etc.
The goal gives both a guiding light to why we are building these things, but it also allows the business and team wiggle room in deciding if a sprint was a success if we are unable to complete some of the PBIs. For instance, if we complete the Twitter feed and Facebook Like integration, but unforeseen API stability issues keep us from solving Google+ integration the business may still find success in the sprint because we have in fact "Increased the Social Networking presence" in our app.
This is an easy and natural angle to take as team members, because it gives us an out. Something we are always desperate for by habit in our high pressure environments. The really important angle is from the perspective of the business and I forget this being a coder by trade.
If we ship the Twitter feed when it is done, then ship the Facebook integration when it is done, but then fail on the Google+ integration it may be that the business feels we've missed the mark. Now this is a contrived example, but think of it as something very important like a multi-channel marketing campaign with Sweepstakes, Online games, Text message lottery, etc. Missing one or more of these could mean the business opportunity has passed, because they revolve around the Olympics or something. Businesses do work in this manner.
A continuous flow model might be great, because they see things happening when they never used to, but it's not what Scrum is aiming for which is providing the business with a well oiled machine with a cadence.
简短的回答是否定的。您所描述的流程模型更像看板而不是 Scrum。使用看板，团队在通过最后阶段后立即发布项目 - 在您的情况下，这是集成阶段。使用 Scrum，PO 必须在冲刺结束时决定是否释放增量。在冲刺中发布项目并不是 Scrum 中的最佳实践。
Short answer is No. The process model you are describing is more like Kanban than Scrum. With Kanban, the team releases items as soon as they pass through the final stage - in your case this is the Integration stage. With Scrum, the PO has to decide at the end of the sprint whether to release the increment or not. Releasing items mid-sprint is not a best practice in Scrum.
我觉得我现在明白 Scrum 不是敏捷的，因为持续部署是敏捷的核心，Scrum 是关于发布点的节奏，大约 1 - 4 周，由产品负责人在冲刺结束时决定，不是以连续的冲刺方式。
事实上，维基百科指出“Scrum……经常出现在敏捷软件开发中”，这意味着并不总是，当然也不是同义词。
我认为预发布的软件开发或具有自然发布周期的非基于服务器的软件可以敏捷到 CI 完成的程度，并且仍然可以使用 Scrum 进行管理。
那么 Scrum 就介于瀑布式和敏捷式之间。比瀑布法好得多，更接近敏捷，但不是敏捷。
瀑布：一些大的长距离冲刺
Scrum：管理较小的冲刺
敏捷：持续冲刺
I feel I now understand that Scrum is not agile, in the sense that continuous deployment is core to agile, and Scrum is about a cadence of release points about 1 - 4 weeks part with a product owner that decides at the end of the sprint, not in a continuous mid-sprint manner.
In fact, wikipedia states that "Scrum is ... often seen in agile software development", implying not always, and certainly not synonymous.
I suppose pre-released software development, or non server based software that has a natural release cycle could be agile to the point that CI is done, and still be managed with Scrum.
Scrum is just between Waterfall and Agile, then. Much better then Waterfall, and closer to Agile, but not Agile.
Waterfall: few big long sprints
Scrum: managed smaller sprints
Agile: continuous sprinting