10

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

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

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

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

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

总结一下，我的问题是：当你使用精益/看板时，你能经常发布而不引入浪费吗？或者发布通常不是精益/看板的一部分？

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

4

7 回答 7

5

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

我假设您阅读了有关看板与 SCRUM 的博客以及相关的实用指南？

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

于 2009-08-07T15:19:59.210 回答
4

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

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

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

通过系统返回的请求是开始工作的权限。一旦请求到达，就会触发大量活动，其中每个活动都应尽快完成。在那里你有你的涡轮部署。

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

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

于 2011-01-24T11:55:40.050 回答
1

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

于 2009-08-23T23:49:20.713 回答
1

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

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

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

于 2009-11-25T10:59:20.010 回答
1

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

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

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

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

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

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

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

于 2010-07-12T00:28:04.630 回答
0

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

持续集成也有帮助 - 即大量小的，超过每日提交，而不是巨大的和潜在的具有挑战性的合并。CruiseControl之类的工具可以帮助突出显示源何时因错误提交而中断。此外，如果每个人都进行了许多小的更改，那么冲突的更改将很少见。

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

于 2009-11-19T20:51:33.023 回答
0

我们是如何做到的：

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

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

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

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

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

于 2011-03-07T22:27:42.290 回答