How do you make sure that you always have a releasable build?
I think there are 2 aspects to your question. One is version control plus release management strategies, and the other is how to handle 'Undone' work.
As far as the version control part goes, your solution is simpler than you think. With svn each commit creates a tag for the whole project with a tag number. You can do an svn revert on just a particular User Story check in tag. A best practice article suggests that development should always be done on the trunk, and you should only branch for a release. So any unreleasable code should be reverted using svn revert on the tag number on the trunk, and then the release branch should be created. After the branch is created, you can check in the unreleased code back again and continue working on it on the next Sprint. Continue working on bugs or release issues on the branch itself without meddling with the trunk. Offcource do not forget to merge the release branch back to the trunk periodically.
And about the undone work goes, first of all it is a good thing that your organisation recognizes the difference between shippable and non shippable, so that is a good step. Secondly you need to investigate why work is left undone, try to facilitate some questions in the Retrospective which will help your Team avoid such situations, using the inspect and adapt principle.
I think your desire to back out incomplete code is a band-aid on the real problem. The real problem to address is what are you doing wrong that gets you to the end of the sprint with unacceptable stories.
Sounds to me like you have one (or all) of 3 problems.
Incomplete Conditions of Acceptance, you apparently don't understand what the PO expects for your stories to be Done and accepted by him. You need to do more work in sprint planning (or before) to come to an understanding of what Done for each story is.
Not involving the PO enough during the sprint. The demo shouldn't be the first time he has seen the stories completed. It is just a final ceremony to close out the sprint. The PO should have been accepting stories all throughout the sprint.
Overcommitment; if you are coding to the last minute then you don't have time time to fully integrate and test. I'm not sure if you meant "bug" as in broken-not-tested-code or didn't-work-like-PO-wanted-code.
Branch per feature is an expensive thing to do for small teams and is more appropriate when building large systems with many scrum teams building component parts. It's like buying auto insurance because you crash a lot; it doesn't get you there faster it just makes you pay more along the way.
Try this for a sprint or 2: don't start on another story until the PO has approved the current one.
As you suggest, one way to approach this is to consider rejection from the outset. Requiring that every user story can be enabled or disabled through a configuration directive guarantees a releasable build without the rejected stories.
If you are really serious about excluding the rejected stories, a configuration directive is not enough because it can be edited by the client. You may consider compilation constants in that case.
This approach requires some additional code and testing, but saves you the hassle of branching and merging. You can also leave your revision control environment in place.
I agree with @DancesWithBamboo - you're asking about the symptom, not the real problem. The problem is:
Why is the PO rejecting the stories?
Are the stories incomplete? If so, then they shouldn't have been committed to the release and the team needs to be reminded that there should be no "partly done" stories - done is yes/no.
Do the stories not do what the PO expected? Then you need to spend more time in the pre-sprint meeting becoming very clear what the story means before the team commits to it. Also consider using automated acceptance tests with something like FitNesse. If the PO helps write the acceptance criteria then he/she will know what to expect when the story is done. See also "Card, Conversation, Confirmation".
Did the business needs change during the course of the sprint? Then maybe you should shorten your sprint so that the PO can have the team abandon stories that are no longer needed.*
Agile practitioners talk about "Inspect and Adapt" or "Plan-Do-Check-Act". At the end of the sprint, have the Team and the Scrum Master discuss what worked, what didn't, what you'd like to add. There are various styles of retrospectives - the important thing is that your retrospective should result in actionable items that are designed to improve your process. Agile doesn't mean keeping the process the same - there's always room for improvement.
(* Some people recommend that, once a sprint has started, there should not be a change to what stories are worked on. For me, this is too rigidly holding onto process. I don't see any sense in a team finishing a story if the PO has legitimately determined that it no longer provides business value.)
Joel 的 HGInit 教程很好地解释了 Mercurial，并通过一个并行功能添加示例进行了工作。
Take a look at one of the newer classes of distributed source control such as Mercurial. Code commits form a dependency chain making it easier to back out specific functionality without disrupting other parallel work.
Joel's HGInit tutorial explains Mercurial very well and does work through an example of parallel feature addition.
发布评论
评论（5）
我认为你的问题有两个方面。一是版本控制加发布管理策略，二是如何处理“未完成”的工作。
就版本控制部分而言，您的解决方案比您想象的要简单。使用 svn，每次提交都会为整个项目创建一个带有标签号的标签。您可以仅对特定的用户故事签入标记执行 svn 还原。一篇最佳实践文章建议，开发应始终在主干上完成，并且您应该只分支发布。因此，任何不可发布的代码都应该使用 svn revert 对主干上的标记号进行恢复，然后创建发布分支。创建分支后，您可以再次签入未发布的代码，并在下一个 Sprint 中继续处理它。继续处理分支本身的错误或发布问题，而无需干预主干。 Offsource 不要忘记定期将发布分支合并回主干。
关于未完成的工作，首先，您的组织认识到可交付和不可交付之间的区别是一件好事，所以这是一个很好的步骤。其次，您需要调查为什么工作未完成，尝试在回顾中提出一些问题，这将帮助您的团队使用检查和调整原则避免此类情况。
I think there are 2 aspects to your question. One is version control plus release management strategies, and the other is how to handle 'Undone' work.
As far as the version control part goes, your solution is simpler than you think. With svn each commit creates a tag for the whole project with a tag number. You can do an svn revert on just a particular User Story check in tag. A best practice article suggests that development should always be done on the trunk, and you should only branch for a release. So any unreleasable code should be reverted using svn revert on the tag number on the trunk, and then the release branch should be created. After the branch is created, you can check in the unreleased code back again and continue working on it on the next Sprint. Continue working on bugs or release issues on the branch itself without meddling with the trunk. Offcource do not forget to merge the release branch back to the trunk periodically.
And about the undone work goes, first of all it is a good thing that your organisation recognizes the difference between shippable and non shippable, so that is a good step. Secondly you need to investigate why work is left undone, try to facilitate some questions in the Retrospective which will help your Team avoid such situations, using the inspect and adapt principle.
我认为你想要取消不完整的代码的愿望是解决真正问题的创可贴。真正要解决的问题是你做错了什么，导致你在冲刺结束时遇到了不可接受的故事。
在我看来，您遇到了三个问题之一（或全部）。
不完整的接受条件，您显然不明白 PO 对完成您的故事并被他接受的期望。您需要在冲刺计划（或之前）中做更多工作，以了解每个故事的完成情况。
在冲刺期间，采购订单的参与度不够。这个演示不应该是他第一次看到故事完成。这只是结束冲刺的最后仪式。 PO 应该在整个冲刺期间接受故事。
过度承诺；如果您直到最后一刻才编码，那么您就没有时间来完全集成和测试。我不确定您的意思是否是“错误”，如未测试的代码或无法像 PO 想要的代码一样工作。
对于小型团队来说，按功能进行分支是一件昂贵的事情，而在构建由许多 Scrum 团队构建组件的大型系统时更合适。这就像因为你经常发生车祸而购买汽车保险一样；它不会让你更快地到达目的地，只会让你付出更多的代价。
尝试一两次冲刺：在 PO 批准当前故事之前，不要开始另一个故事。
I think your desire to back out incomplete code is a band-aid on the real problem. The real problem to address is what are you doing wrong that gets you to the end of the sprint with unacceptable stories.
Sounds to me like you have one (or all) of 3 problems.
Incomplete Conditions of Acceptance, you apparently don't understand what the PO expects for your stories to be Done and accepted by him. You need to do more work in sprint planning (or before) to come to an understanding of what Done for each story is.
Not involving the PO enough during the sprint. The demo shouldn't be the first time he has seen the stories completed. It is just a final ceremony to close out the sprint. The PO should have been accepting stories all throughout the sprint.
Overcommitment; if you are coding to the last minute then you don't have time time to fully integrate and test. I'm not sure if you meant "bug" as in broken-not-tested-code or didn't-work-like-PO-wanted-code.
Branch per feature is an expensive thing to do for small teams and is more appropriate when building large systems with many scrum teams building component parts. It's like buying auto insurance because you crash a lot; it doesn't get you there faster it just makes you pay more along the way.
Try this for a sprint or 2: don't start on another story until the PO has approved the current one.
正如您所建议的，解决此问题的一种方法是从一开始就考虑拒绝。要求可以通过配置指令启用或禁用每个用户故事可以保证可发布的构建，而不会出现被拒绝的故事。
如果您真的想排除被拒绝的故事，那么配置指令是不够的，因为它可以由客户端编辑。在这种情况下，您可以考虑编译常量。
这种方法需要一些额外的代码和测试，但可以省去分支和合并的麻烦。您还可以保留修订控制环境。
希望这有帮助。
As you suggest, one way to approach this is to consider rejection from the outset. Requiring that every user story can be enabled or disabled through a configuration directive guarantees a releasable build without the rejected stories.
If you are really serious about excluding the rejected stories, a configuration directive is not enough because it can be edited by the client. You may consider compilation constants in that case.
This approach requires some additional code and testing, but saves you the hassle of branching and merging. You can also leave your revision control environment in place.
Hope this helps.
我同意@DancesWithBamboo - 你问的是症状，而不是真正的问题。问题是：
为什么 PO 拒绝这些报道？
您在做什么Sprint 回顾？
敏捷实践者谈论“检查和调整”或“计划-实施-检查-行动”。在冲刺结束时，让团队和 Scrum Master 讨论哪些有效、哪些无效以及您想要添加哪些内容。回顾有多种风格 - 重要的是您的回顾应该产生可操作的项目，旨在改进您的流程。敏捷并不意味着保持流程不变——总是有改进的空间。
（* 有些人建议，一旦冲刺开始，就不应该改变正在处理的故事。对我来说，这过于严格地坚持流程。我认为团队完成一个故事没有任何意义如果采购订单已合法确定其不再提供商业价值。）
I agree with @DancesWithBamboo - you're asking about the symptom, not the real problem. The problem is:
Why is the PO rejecting the stories?
And are you doing Sprint Retrospectives?
Agile practitioners talk about "Inspect and Adapt" or "Plan-Do-Check-Act". At the end of the sprint, have the Team and the Scrum Master discuss what worked, what didn't, what you'd like to add. There are various styles of retrospectives - the important thing is that your retrospective should result in actionable items that are designed to improve your process. Agile doesn't mean keeping the process the same - there's always room for improvement.
(* Some people recommend that, once a sprint has started, there should not be a change to what stories are worked on. For me, this is too rigidly holding onto process. I don't see any sense in a team finishing a story if the PO has legitimately determined that it no longer provides business value.)
看一下较新的分布式源代码控制类别之一，例如 Mercurial。代码提交形成依赖链，使得更容易撤销特定功能而不会中断其他并行工作。
Joel 的 HGInit 教程很好地解释了 Mercurial，并通过一个并行功能添加示例进行了工作。
Take a look at one of the newer classes of distributed source control such as Mercurial. Code commits form a dependency chain making it easier to back out specific functionality without disrupting other parallel work.
Joel's HGInit tutorial explains Mercurial very well and does work through an example of parallel feature addition.