There's more to this than just source control, but your choice of TFS is going to limit you. When the Burton project was conceived back in 2004, Microsoft wasn't paying attention to Agile, much less Lean. It's going to be your weakest mechanical link for some time. Your hackles should have been raised by CodePlex's own adoption of Mercurial after having been offered to the Microsoft community as the poster child of TFS implementation.
A more salient issue here is Work Design. It encompasses the order that you choose to implement features (work schedule), as well as prioritization and cost of delay, and the shape and size of work items.
Scrum is commonly interpreted to say that non-technical "Product Owners" can determine work schedule based solely on their own concerns. If you follow this path, you're going to incur a lot waste by not taking the opportunities to do work together that belongs together. Work that belongs together can't just be determined by Product Owner wishes. Technical and workforce (skills) opportunities must also be taken into consideration.
For work to be done in the most productive way, the work itself has to be designed that way. This means that in a Lan Product Development team, decisions are made not by a non-technical worker, but by what Toyota calls someone of "Towering Technical Competence" who is close to the product, close to the customers, and close to the team.
This role is a stark contrast to Scrum's proposition. A Chief Engineer on a Lean team is himself (or herself) the voice of the customer, and the role of Product Owner is unnecessary.
Scrum's "Product Owner" is a recognition of an under-developed role in software development organizations, but it's far from a sustainable solution that consistently avoids waste. The role of "Software Architect" is often insufficient as well, as in some developer sub-cultures, the architect has become far too removed from the work.
Your issues of continuous deployment are only partially addressed with technology and tools. Look also to organizational issues, and perhaps give some thought to Scrum's purpose as a transitional approach from waterfall rather than one that can serve your organization indefinitely.
The problem you describe seems more a source control program -- how to separate done features from features in-progress, than about Kanban. You seem to put a heavy penalty on running many branches -- which is the case for source control systems not based around the idea of multiple branches. On Distributed Source Control systems, such as GIT and Mercury, everything is a branch, and having them and working with them is lightweight.
I assume you read this blog about Kanban vs SCRUM, and the associated practical guide?
And, in answer to your question, yes, you can release often with Kanban.
You need to understand pull systems, which is what Kanban is designed to manage.
A customer (or product owner or similar) request for a feature in the running system is what triggers the process.
The request is a signal that goes to deployment. Deployment look for a tested item with properties that match the request. If none is there, you write the tests and look at development if there is a development slot that can be used to implement something that fulfils the test. When development has done its development (maybe looking for a suitable analysis first and so on), the test does its test, and deployment deploys.
The requests going backwards through the system are permissions to start working. As soon as the request has arrived, this triggers a lot of activity, where each activity should be completed as quickly as possible. There you have your turbo deployment.
Just like the request for a car goes to the dealer who looks in the ship who signals to the car factory, who signals to the suppliers.
Kanban is not about pushing requests through a system. It is about pulling functionality out of the system in exchange for a request that enters via the last step.
The team I manage uses Kanban and we release around every two weeks. If you're strict about what gets integrated into your mainline code branch (tests passing, customer approved, etc.), Kanban allows you to release whenever you want. You need to make sure that the stories moving through your system aren't co-dependent in order to do this, but on my team that's usually not a problem - a large part of our work involves maintenance, which consists of several unrelated bug fixes / features per release.
The way we handled weekly releases on a sustained engineering project that used Kanban was to implement a branching strategy. The devs worked in a sandbox branch, and made one checkin per work item. Our testers would test the work item in the sandbox; if it passed the regression tests the checkin would be migrated to our release branch. We locked the release branch from noon Monday until the release went out (usually by Wednesday, occasionally by Thursday, the drop dead date was Friday), and re-ran the regression tests for all migrated checkins as well as integration tests for the product, dropping a release once all of the tests passed.
This strategy let devs continually be working on issues without being frozen out of their branch during the release process. It also let them work on issues that took more than a week to resolve; if it wasn't checked in and tested/approved it didn't get migrated.
If I were running Kanban for a new version of a project, I'd use a similar strategy but group all related checkins as a 'feature', migrating a feature en masse to the release branch once the feature was done and then performing additional unit/integration/acceptance/regression testing in the release branch before dropping a release with that feature. Note that a key concept of Kanban is limiting work in progress, so I might restrict my team to work on one feature at a time (this would probably be several work items/user stories).
For source control I'd highly recommend Perforce. It makes branching and integrating changes from other branches relatively straightforward, and provides the best interface for source control that I've seen so far.
Continuous integration helps as well - i.e. lots of small, more than daily commits, instead of huge and potentially challenging merges. Tools like CruiseControl can help highlight when the source gets broken by a bad commit. Also, if everyone makes many small changes then conflicting changes will be rare.
I'd also advice not to try to follow things like lean, scrum, kanban & co. too closely. Just solve the problems yourself, looking to these ideas for guidance rather than instruction. The specifics of your problems will more than likely require some flexibility for the best management.
Each story is developed as a branch based on the latest version to leave the Deploy stage. They are then integrated as part of preparing the integration test.
QA pulls from the code review stage and can prepare releases at any pace the want. I think we have a pace of roughly one release every week.
By removing the "master" branch from git and not doing any merge before the code review stage we've made sure that there is no possibility to "sneak" code into releases. Which, as an interesting by-product, has forced us to visualize a lot of the work that used to be hidden.
发布评论
评论（7）
这不仅仅是源代码控制，但您对 TFS 的选择将会限制您。 当 2004 年构思 Burton 项目时，微软并没有关注敏捷，更不用说精益了。 在一段时间内，这将是您最薄弱的机械环节。 CodePlex 在将 Mercurial 作为 TFS 实现的典范提供给 Microsoft 社区后，自己采用 Mercurial 应该会引起您的愤怒。
这里一个更突出的问题是工作设计。 它包含您选择实现功能的顺序（工作计划）、优先级和延迟成本以及工作项的形状和大小。
Scrum 通常被解释为非技术“产品负责人”可以仅根据自己的关注点来确定工作时间表。 如果你走这条路，你就会因为不抓住机会一起做属于一起的工作而造成很多浪费。 属于一起的工作不能仅仅由产品负责人的意愿来决定。 还必须考虑技术和劳动力（技能）机会。
为了以最高效的方式完成工作，工作本身就必须这样设计。 这意味着在 LAN 产品开发团队中，决策不是由非技术人员做出的，而是由丰田所说的具有“高超技术能力”的人员做出的，他们贴近产品、贴近客户、贴近团队。
这个角色与Scrum 的主张形成鲜明对比。 精益团队中的首席工程师本人就是客户的声音，产品负责人的角色是不必要的。
Scrum 的“产品负责人”是对软件开发组织中尚未充分发展的角色的认可，但它远非持续避免浪费的可持续解决方案。 “软件架构师”的角色通常也不够充分，因为在某些开发人员亚文化中，架构师已经变得太远离工作了。
技术和工具只能部分解决您的持续部署问题。 还要关注组织问题，也许需要考虑一下 Scrum 的目的是作为瀑布的过渡方法，而不是可以无限期地为您的组织服务的方法。
There's more to this than just source control, but your choice of TFS is going to limit you. When the Burton project was conceived back in 2004, Microsoft wasn't paying attention to Agile, much less Lean. It's going to be your weakest mechanical link for some time. Your hackles should have been raised by CodePlex's own adoption of Mercurial after having been offered to the Microsoft community as the poster child of TFS implementation.
A more salient issue here is Work Design. It encompasses the order that you choose to implement features (work schedule), as well as prioritization and cost of delay, and the shape and size of work items.
Scrum is commonly interpreted to say that non-technical "Product Owners" can determine work schedule based solely on their own concerns. If you follow this path, you're going to incur a lot waste by not taking the opportunities to do work together that belongs together. Work that belongs together can't just be determined by Product Owner wishes. Technical and workforce (skills) opportunities must also be taken into consideration.
For work to be done in the most productive way, the work itself has to be designed that way. This means that in a Lan Product Development team, decisions are made not by a non-technical worker, but by what Toyota calls someone of "Towering Technical Competence" who is close to the product, close to the customers, and close to the team.
This role is a stark contrast to Scrum's proposition. A Chief Engineer on a Lean team is himself (or herself) the voice of the customer, and the role of Product Owner is unnecessary.
Scrum's "Product Owner" is a recognition of an under-developed role in software development organizations, but it's far from a sustainable solution that consistently avoids waste. The role of "Software Architect" is often insufficient as well, as in some developer sub-cultures, the architect has become far too removed from the work.
Your issues of continuous deployment are only partially addressed with technology and tools. Look also to organizational issues, and perhaps give some thought to Scrum's purpose as a transitional approach from waterfall rather than one that can serve your organization indefinitely.
您描述的问题似乎更像是一个源代码控制程序——如何将已完成的功能与正在进行的功能分开，而不是看板。 您似乎对运行许多分支施加了沉重的惩罚——对于不基于多个分支的想法的源控制系统来说就是这种情况。 在分布式源代码控制系统（例如 GIT 和 Mercury）上，一切都是一个分支，拥有它们并使用它们是轻量级的。
我假设您阅读了关于看板与 SCRUM 的这篇博客，并且相关实用指南？
而且，回答你的问题，是的，你可以使用看板经常发布。
The problem you describe seems more a source control program -- how to separate done features from features in-progress, than about Kanban. You seem to put a heavy penalty on running many branches -- which is the case for source control systems not based around the idea of multiple branches. On Distributed Source Control systems, such as GIT and Mercury, everything is a branch, and having them and working with them is lightweight.
I assume you read this blog about Kanban vs SCRUM, and the associated practical guide?
And, in answer to your question, yes, you can release often with Kanban.
您需要了解拉式系统，这就是看板的设计目的。
客户（或产品所有者或类似人员）对正在运行的系统中的某个功能的请求会触发该流程。
该请求是进行部署的信号。 部署会查找具有与请求匹配的属性的已测试项目。 如果没有，则编写测试并查看开发是否有可用于实现满足测试的开发插槽。 当开发完成其开发（可能首先寻找合适的分析等等）时，测试将进行测试，然后进行部署。
通过系统向后发送的请求是开始工作的权限。 一旦请求到达，就会触发大量活动，每个活动都应该尽快完成。 在那里你已经部署了涡轮增压。
就像对汽车的请求发送给经销商，经销商在船上查看，然后向汽车工厂发出信号，汽车工厂向供应商发出信号。
看板并不是通过系统推送请求。 它是将功能从系统中提取出来，以换取通过最后一步进入的请求。
You need to understand pull systems, which is what Kanban is designed to manage.
A customer (or product owner or similar) request for a feature in the running system is what triggers the process.
The request is a signal that goes to deployment. Deployment look for a tested item with properties that match the request. If none is there, you write the tests and look at development if there is a development slot that can be used to implement something that fulfils the test. When development has done its development (maybe looking for a suitable analysis first and so on), the test does its test, and deployment deploys.
The requests going backwards through the system are permissions to start working. As soon as the request has arrived, this triggers a lot of activity, where each activity should be completed as quickly as possible. There you have your turbo deployment.
Just like the request for a car goes to the dealer who looks in the ship who signals to the car factory, who signals to the suppliers.
Kanban is not about pushing requests through a system. It is about pulling functionality out of the system in exchange for a request that enters via the last step.
我管理的团队使用看板，我们大约每两周发布一次。 如果您对集成到主线代码分支中的内容很严格（测试通过、客户批准等），看板允许您随时发布。 为了做到这一点，你需要确保通过你的系统的故事不是相互依赖的，但在我的团队中，这通常不是问题 - 我们工作的很大一部分涉及维护，其中包括几个不相关的错误修复/ 每个版本的功能。
The team I manage uses Kanban and we release around every two weeks. If you're strict about what gets integrated into your mainline code branch (tests passing, customer approved, etc.), Kanban allows you to release whenever you want. You need to make sure that the stories moving through your system aren't co-dependent in order to do this, but on my team that's usually not a problem - a large part of our work involves maintenance, which consists of several unrelated bug fixes / features per release.
我们处理使用看板的持续工程项目的每周发布的方式是实施分支策略。 开发人员在沙盒分支中工作，并对每个工作项进行一次签入。 我们的测试人员会在沙箱中测试工作项； 如果它通过了回归测试，签入将被迁移到我们的发布分支。 我们从周一中午锁定发布分支，直到发布结束（通常是周三，偶尔是周四，截止日期是周五），并重新运行所有迁移签入的回归测试以及产品的集成测试，一旦所有测试通过，就放弃发布。
这种策略让开发人员能够持续解决问题，而不会在发布过程中被冻结在他们的分支之外。 它还让他们能够解决需要一周多时间才能解决的问题； 如果未签入并测试/批准，则不会迁移。
如果我为项目的新版本运行看板，我会使用类似的策略，但将所有相关的签入分组为“功能”，一旦该功能将功能全部迁移到发布分支已完成，然后在发布分支中执行额外的单元/集成/验收/回归测试，然后再删除具有该功能的版本。 请注意，看板的一个关键概念是限制正在进行的工作，因此我可能会限制我的团队一次只处理一项功能（这可能是多个工作项/用户故事）。
The way we handled weekly releases on a sustained engineering project that used Kanban was to implement a branching strategy. The devs worked in a sandbox branch, and made one checkin per work item. Our testers would test the work item in the sandbox; if it passed the regression tests the checkin would be migrated to our release branch. We locked the release branch from noon Monday until the release went out (usually by Wednesday, occasionally by Thursday, the drop dead date was Friday), and re-ran the regression tests for all migrated checkins as well as integration tests for the product, dropping a release once all of the tests passed.
This strategy let devs continually be working on issues without being frozen out of their branch during the release process. It also let them work on issues that took more than a week to resolve; if it wasn't checked in and tested/approved it didn't get migrated.
If I were running Kanban for a new version of a project, I'd use a similar strategy but group all related checkins as a 'feature', migrating a feature en masse to the release branch once the feature was done and then performing additional unit/integration/acceptance/regression testing in the release branch before dropping a release with that feature. Note that a key concept of Kanban is limiting work in progress, so I might restrict my team to work on one feature at a time (this would probably be several work items/user stories).
对于源代码控制，我强烈推荐 Perforce。 它使得分支和集成来自其他分支的更改相对简单，并提供了迄今为止我所见过的最佳源代码控制界面。
持续集成也有帮助——即大量小型的、超过每日的提交，而不是巨大且可能具有挑战性的合并。 CruiseControl 等工具可以帮助突出显示来源何时因错误的提交而中断。 此外，如果每个人都做出许多小的改变，那么冲突的改变就会很少见。
我还建议不要尝试遵循精益、Scrum、看板和管理等方式。 公司 太近了。 只需自己解决问题，向这些想法寻求指导而不是指导。 您的问题的具体情况很可能需要一定的灵活性才能实现最佳管理。
For source control I'd highly recommend Perforce. It makes branching and integrating changes from other branches relatively straightforward, and provides the best interface for source control that I've seen so far.
Continuous integration helps as well - i.e. lots of small, more than daily commits, instead of huge and potentially challenging merges. Tools like CruiseControl can help highlight when the source gets broken by a bad commit. Also, if everyone makes many small changes then conflicting changes will be rare.
I'd also advice not to try to follow things like lean, scrum, kanban & co. too closely. Just solve the problems yourself, looking to these ideas for guidance rather than instruction. The specifics of your problems will more than likely require some flexibility for the best management.
我们是如何做到的：
我们有一个包含以下阶段的管道
每个故事都作为基于最新版本的分支开发离开部署阶段。 然后将它们作为准备集成测试的一部分进行集成。
QA 从代码审查阶段退出，可以按照需要的任何速度准备发布。 我认为我们的节奏大约是每周发布一次。
通过从 git 中删除“master”分支并且在代码审查阶段之前不进行任何合并，我们确保了不可能将代码“潜入”版本中。 作为一个有趣的副产品，这迫使我们将许多过去隐藏的工作可视化。
How we do it:
We have a pipeline with the following stages
Each story is developed as a branch based on the latest version to leave the Deploy stage. They are then integrated as part of preparing the integration test.
QA pulls from the code review stage and can prepare releases at any pace the want. I think we have a pace of roughly one release every week.
By removing the "master" branch from git and not doing any merge before the code review stage we've made sure that there is no possibility to "sneak" code into releases. Which, as an interesting by-product, has forced us to visualize a lot of the work that used to be hidden.