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