我是Lean / Kanban的新手，但过去几周已经涌入了在线资源，并提出了一个我没有找到合适答案的问题。精益/看板似乎非常适合我们已经使用Scrum的公司，但在该方法中已经达到了一些限制。我希望这里有人能给我一个好主意。
正如我所看到的，Scrum over Waterfall的最大优势之一就是使用sprint。通过每14天准备好一切，您可以获得较短的反馈周期并且可以经常发布。但是，正如我从阅读Lean中所了解的那样，有一些与此相关的成本（例如，在sprint计划会议上花费的时间，团队承诺会议以及在sprint结束时找到对每个人有用的一些问题）。
精益/看板将删除这些废物，但仅以每14天无法释放为代价。或者我错过了重要的一点？因为，在看板中，您如何处理新的开发任务并同时发布？你怎么确定你不发货的东西只做了一半？你怎么能正确测试它？
到目前为止，我最好的“解决方案/想法”是：
总结一下，我的问题是：当您使用精益/看板时，您是否可以在不引入浪费的情况下经常发布？或经常发布不是精益/看板的一部分？
特定于我公司的其他信息： 我们使用Team Foundation System＆amp;源代码管理，以前在分支和合并方面有一些不好的经验。这可以通过引入这方面的一些专业知识来解决吗？
答案 0 :(得分：5)
您描述的问题似乎更像是一个源控制程序 - 如何将完成的功能与正在进行的功能分开，而不是与看板相关。你似乎在运行许多分支时付出了沉重的代价 - 对于源控制系统来说，这不是基于多个分支的想法。在分布式源代码控制系统上，例如GIT和Mercury，所有都是一个分支，拥有它们并使用它们是轻量级的。
我假设您阅读this blog关于看板与SCRUM以及相关的实用指南？
而且，在回答您的问题时，是的，您可以经常使用看板发布。
答案 1 :(得分：4)
您需要了解拉动系统，这是看板设计要管理的系统。
客户（或产品所有者或类似）对正在运行的系统中的功能的请求是触发该过程的原因。
请求是部署的信号。部署查找具有与请求匹配的属性的测试项。如果没有，那么编写测试并查看开发是否存在可用于实现满足测试的内容的开发槽。当开发完成开发（可能首先寻找合适的分析等）时，测试会进行测试，并进行部署。
通过系统返回的请求是开始工作的权限。一旦请求到达，就会触发大量活动，每个活动都应尽快完成。你有涡轮部署。
就像汽车的要求一样，发往船上的经销商向汽车工厂发出信号，并向供应商发出信号。
看板不是通过系统推送请求。它是关于从系统中提取功能以换取通过最后一步进入的请求。
答案 2 :(得分：1)
我管理的团队使用看板，我们每两周发布一次。如果您严格要求将哪些内容集成到主线代码分支中（测试通过，客户批准等），看板允许您随时发布。您需要确保在您的系统中移动的故事不是共同依赖才能执行此操作，但在我的团队中这通常不是问题 - 我们的大部分工作涉及维护，其中包括几个不相关的错误修复/每个版本的功能。
答案 3 :(得分：1)
我们处理使用看板的持续工程项目的每周发布的方式是实施分支策略。开发人员在沙箱分支中工作，并为每个工作项目制作一个签入。我们的测试人员将测试沙盒中的工作项;如果它通过了回归测试，则checkin将被迁移到我们的发布分支。我们从星期一中午锁定了发布分支，直到发布完毕（通常在星期三，有时在星期四，下降死亡日期是星期五），并重新运行所有迁移的签入的回归测试以及产品的集成测试，所有测试通过后放弃一个版本。
这种策略让开发人员不断处理问题，而不会在发布过程中冻结他们的分支。它还让他们处理需要一个多星期才能解决的问题;如果没有检查并测试/批准它没有迁移。
如果我为一个项目的新版本运行看板，我会使用类似的策略，但将所有相关的签到分组作为“功能”，将功能集体迁移到发布分支完成该功能后，再在发布分支中执行其他单元/集成/接受/回归测试，然后再删除具有该功能的发行版。请注意，看板的一个关键概念是限制正在进行的工作，因此我可能会限制我的团队一次处理一个功能（这可能是几个工作项/用户故事）。
答案 4 :(得分：1)
除了源代码控制之外，还有更多内容，但您选择的TFS将限制您。当Burton项目在2004年被设想时，微软并未关注敏捷，更不用说精益了。一段时间以来，这将成为你最薄弱的机械环节。在作为TFS实施的典型代表提供给Microsoft社区之后，CodePlex自己采用Mercurial应该引起您的困扰。
这里一个更突出的问题是工作设计。它包含您选择实施功能的顺序（工作计划），以及延迟的优先级和成本，以及工作项的形状和大小。
Scrum通常被解释为非技术性“产品所有者”可以仅根据自己的顾虑来确定工作时间表。如果你沿着这条路走下去，你就会因为没有机会一起工作而招致很多浪费。属于一起的工作不能仅由产品所有者的愿望决定。还必须考虑技术和劳动力（技能）机会。
要以最有成效的方式完成工作，工作本身必须以这种方式设计。这意味着在Lan产品开发团队中，决策不是由非技术工人做出的，而是由丰田称之为“高耸技术能力”的人做出的，他们接近产品，靠近客户，靠近团队
这个角色与Scrum的主张形成鲜明对比。精益团队的总工程师本人（或她自己）是客户的声音，产品负责人的角色是不必要的。
Scrum的“产品负责人”是对软件开发组织中发展不足的角色的认可，但它远不是一直避免浪费的可持续解决方案。 “软件架构师”的角色通常也不够，因为在一些开发者亚文化中，架构师已经远离工作。
您的持续部署问题仅通过技术和工具得到部分解决。另请参阅组织问题，或许可以考虑Scrum作为瀑布过渡方法的目的而不是可以无限期地为您的组织服务的方法。
答案 5 :(得分：0)
对于源代码管理，我强烈推荐Perforce。它使得来自其他分支的分支和集成变化相对简单，并且为目前为止我见过的源代码控制提供了最佳接口。
持续集成也有帮助 - 即许多小的，超过每日提交，而不是巨大的和潜在挑战性的合并。像CruiseControl这样的工具可以帮助突出显示源被错误提交破坏的时间。此外，如果每个人都做了很多小改动，那么相互矛盾的变化将是罕见的。
我也建议不要尝试像精益，scrum，看板和＆amp ;;合。太紧密了。只是自己解决问题，寻找这些想法，而不是指导。您的问题的具体细节可能需要一些灵活性来实现最佳管理。
答案 6 :(得分：0)
我们如何做到：
我们有一个包含以下阶段的管道
每个故事都是基于最新版本开发的分支，以离开部署阶段。然后将它们集成为准备集成测试的一部分。
QA从代码审核阶段开始，可以根据需要随时准备版本。我想我们每周大约有一次发布。
通过从git中删除“master”分支并且在代码审查阶段之前没有进行任何合并，我们确保没有可能将代码“偷偷摸摸”到版本中。作为一个有趣的副产品，它迫使我们想象出许多曾经被隐藏的作品。