如何使用精益/看板经常发布？ [关闭]

Question

我对精益/看板很陌生，但在过去几周里我大量使用在线资源并提出了一个我没有找到好的答案的问题。精益/看板似乎非常适合我们公司，他们已经在使用 Scrum，但在该方法中遇到了一些限制。我希望这里有人能给我一个好主意。

在我看来，Scrum 相对于 Waterfall 的最大优势之一是使用了 sprint。通过每 14 天准备好一切，您可以获得较短的反馈周期并且可以经常发布。然而，正如我从阅读有关精益的文章中了解到的那样，有一些与此相关的成本（例如，花费在 sprint 计划会议、团队承诺会议上的时间以及在 sprint 结束时为每个人找到有用的东西的一些问题）。

精益/看板会消除这些浪费，但代价是不能每 14 天释放一次。还是我错过了重要的一点？因为，在看板中，您如何能够同时处理新的开发任务和发布？你如何确保你不会运送只完成一半的东西？以及如何正确测试它？

到目前为止，我最好的“解决方案/想法”是：

• 不要经常发布并允许与用完新开发任务相关的浪费。不过，这并不能真正解决所提出的问题。
• 在分支中发展，然后合并到主干中。使您必须在内部连续支持至少两个分支。
• 使用一些智能自动标记系统仅自动构建某些已完成的任务，而不自动构建其他任务。

总而言之，我的问题是：当您使用精益/看板时，您能否在不引入浪费的情况下经常发布？还是经常发布不是精益/看板的一部分？

特定于我公司的其他信息： 我们使用 Team Foundation System & Source Control，之前在分支和合并方面有过一些不好的经历。可以通过引入该领域的一些专业知识来解决这个问题吗？

Answer 1

我们是如何做到的：

我们有一个包含以下阶段的管道

1. 积压
2. 待办事项
3. 正在进行中（开发和快速测试）
4. 代码审查
5. 测试（严格测试）
6. 集成测试和一般验收测试
7. 部署

每个故事都是基于最新版本开发的一个分支，以离开部署阶段。然后将它们作为准备集成测试的一部分进行集成。

QA 从代码审查阶段开始，可以根据需要以任何速度准备发布。我认为我们的节奏大约是每周发布一个版本。

通过从 git 中删除“master”分支并且在代码审查阶段之前不进行任何合并，我们确保不可能将代码“潜入”到发布中。作为一个有趣的副产品，这迫使我们将许多过去隐藏的工作可视化。

Answer 2

您需要了解拉动系统，这是看板旨在管理的内容。

客户（或产品所有者或类似人员）对正在运行的系统中的某项功能的请求是触发流程的原因。

请求是用于部署的信号。部署查找具有与请求匹配的属性的测试项目。如果没有，您编写测试并查看开发是否有可用于实现满足测试的某些开发槽。当开发完成它的开发（可能首先寻找合适的分析等等），测试进行它的测试，并且部署部署。

通过系统返回的请求是开始工作的权限。一旦请求到达，就会触发大量活动，其中每个活动都应该尽快完成。到此，您的 Turbo 部署就完成了。

就像汽车的请求发给经销商，经销商在船上查看信号，向汽车工厂发出信号，再向供应商发出信号。

看板不是通过系统推送请求。它是关于从系统中提取功能以换取通过最后一步进入的请求。

Answer 3

这不仅仅是源代码控制，但您选择的 TFS 会限制您。早在 2004 年构思 Burton 项目时，微软并没有关注敏捷，更不用说精益。在一段时间内，它将成为你最薄弱的机械环节。 CodePlex 在将 Mercurial 作为 TFS 实施的典型代表提供给 Microsoft 社区之后，应该会引起您的不满。

这里一个更突出的问题是工作设计。它包括您选择实现功能的顺序（工作计划）、优先级和延迟成本，以及工作项的形状和大小。

Scrum 通常被解释为非技术性的“产品负责人”可以仅根据他们自己的关注点来确定工作计划。如果你走这条路，你会因为不抓住机会一起做属于一起的工作而造成很多浪费。属于一起的工作不能仅仅由产品负责人的意愿决定。还必须考虑技术和劳动力（技能）机会。

要以最高效的方式完成工作，工作本身必须以这种方式设计。这意味着在 Lan 产品开发团队中，决策不是由非技术人员做出的，而是由丰田所说的接近产品、接近客户、接近团队的“Towering Technical Competence”人做出的.

这个角色与 Scrum 的主张形成鲜明对比。精益团队中的总工程师自己（或她自己）是客户的声音，产品负责人的角色是不必要的。

Scrum 的“产品负责人”是对软件开发组织中未充分发挥作用的一种认可，但它远非始终如一地避免浪费的可持续解决方案。 “软件架构师”的角色通常也不够充分，因为在一些开发人员亚文化中，架构师与工作的距离太远了。

您的持续部署问题只能通过技术和工具部分解决。还要考虑组织问题，也许考虑一下 Scrum 的目的，即作为一种从瀑布式过渡的方法，而不是一种可以无限期地为您的组织服务的方法。

Answer 4

我们处理使用看板的持续工程项目的每周发布的方式是实施分支策略。开发人员在沙箱分支中工作，每个工作项进行一次签入。我们的测试人员将在沙箱中测试工作项；如果它通过了回归测试，checkin 将被迁移到我们的发布分支。我们从星期一中午锁定发布分支，直到发布发布（通常在星期三，偶尔在星期四，删除截止日期是星期五），并重新运行所有迁移签入的回归测试以及产品的集成测试，一旦所有测试通过，就放弃发布。

这种策略让开发人员可以不断地解决问题，而不会在发布过程中被冻结在他们的分支之外。它还让他们能够解决需要一个多星期才能解决的问题；如果它没有被签入和测试/批准，它就不会被迁移。

如果我为项目的新版本运行看板，我会使用类似的策略，但将所有相关的签入分组为“功能”，将功能en masse迁移到发布分支一旦功能完成，然后在发布分支中执行额外的单元/集成/验收/回归测试，然后再删除具有该功能的发布。请注意，看板的一个关键概念是限制正在进行的工作，因此我可能会限制我的团队一次只处理一个功能（这可能是几个工作项/用户故事）。

Answer 5

对于源代码控制，我强烈推荐Perforce。它使来自其他分支的分支和集成更改相对简单，并提供了迄今为止我所见过的最好的源代码控制界面。

持续集成也有帮助 - 即大量的小提交，而不是每日提交，而不是巨大且可能具有挑战性的合并。 CruiseControl 之类的工具可以帮助突出显示源何时因错误提交而中断。另外，如果每个人都做了很多小的改动，那么冲突的改动就很少见了。

我还建议不要尝试遵循精益、Scrum、看板等方法。太近了。自己解决问题，从这些想法中寻求指导而不是指导。您的问题的具体细节很可能需要一定的灵活性才能实现最佳管理。

Answer 6

我管理的团队使用看板，我们大约每两周发布一次。如果您对集成到主线代码分支中的内容（测试通过、客户批准等）非常严格，看板允许您随时发布。您需要确保在您的系统中移动的故事不相互依赖才能做到这一点，但在我的团队中，这通常不是问题 - 我们的大部分工作都涉及维护，其中包括几个不相关的错误修复/ 每个版本的功能。

Answer 7

您描述的问题似乎更像是一个源代码控制程序——如何将已完成的功能与正在进行的功能分开，而不是看板。您似乎对运行许多分支施加了沉重的惩罚——对于不基于多个分支概念的源代码控制系统来说就是这种情况。在分布式源代码控制系统（例如 GIT 和 Mercury）上，一切都是一个分支，拥有它们并使用它们是轻量级的。

我假设您已阅读 this blog 关于看板与 SCRUM 以及相关的实用指南的内容？

而且，在回答您的问题时，是的，您可以经常使用看板发布。