问题标签 [kanban]

我试图想出一种简单（本质上是敏捷）的方法来可视化大型部门的工作和瓶颈，一旦我们有了必要的数据，就会逐渐改进流程。

问题是我们有多个开发人员组在多个项目上工作。有些开发人员是跨项目的，有些项目是跨团队的。开发人员的方式非常固定（我们不想强迫 C# 或 Java 开发人员在结对编程期间学习 Delphi 6）。

另一个问题是所有开发人员/项目之间共享一个非常小的 QA 团队。

我需要有关如何组织看板（或类似）任务板的想法，以便故事按项目（或团队？）分类，但 WIP 限制仍然适用于全面。

另外，站立会议将如何进行？将每个人都包含在一个会议中会占用太多时间并导致信息过载，但拆分会议会使我们失去敏捷强制执行的许多透明度。

因此，欢迎任何与任务板和站立会议相关的想法。此外，非常欢迎具有与看板相同水平（换句话说不多）的看板替代品。

我一直试图让我们的软件部门采用某种开发过程方法。我们只有 9 名开发人员，项目数量也差不多。目前，我们只能用混乱来形容。或者也许是“危机驱动的发展”，正如我看到另一个 SO 用户所说的那样。

使用看板似乎很适合我们。所以我和其他人讨论过，每个人都认为这听起来不错。但是当我们讨论应该如何安排董事会时，每个人都想每人做一个董事会。

现在，我从未真正尝试过看板或任何方法，但感觉就像让每个人都在自己的板上管理会否定看板流程应该提供的好处。这个想法让我很难过，我想说“哼哼，让我们放弃这整个想法吧。”

您认为为每个开发人员实施看板是否值得？

鉴于看板上的基本流程：

在阅读书籍/文章/演示文稿后，它大致变成了

所以我无法弄清楚的问题：

1. Backlog & Input Queue & Dev Queue 关系。PM 优先考虑该版本的待办事项中的 MMF 并将它们移动到输入队列中，dev（基于 WIP 限制）取一个并开始处理它（WIP 列）。开发队列是做什么用的？应该是 PM 将内容从 Backlog 移动到 Dev Queue，然后 dev 将它们移动到 Dev WIP，还是应该 PM 将内容从 Backlog 移动到 Input Queue，然后 dev 取一个并将其移动到 Dev WIP？我不明白为什么看板示例谈论有积压、输入队列和开发子队列，每个都有自己的目的吗？

2. 开发人员将已完成/已解决的工作项移动到哪里以及完成和下一个队列列之间的关系是什么？如果不需要质量检查怎么办？例如，当 Dev WIP 完成时，您可以将其移至 Dev Done，然后 QA 会将其从那里拉入 QA WIP。或者从 Dev WIP 到 QA 队列或部署队列（当不需要 QA 时）。在第一种情况下，即使描述过于技术性或过于模糊，QAer 也需要了解并检查 Dev Done 列中的每一张票。在第二个 Dev Done 被绕过，QA 失去了对部署内容的控制/监督。此外，是否应该有部署队列或已关闭？多亏了 CI，部署是一键式的，但是通过每个开发任务并将修订号与刚刚部署的版本匹配，然后再将其移动到 Closed 听起来像是一种负担......

有任何想法吗？或者，也许您知道真实世界的看板及其流程设置的详细示例？我知道我应该绘制出真实的现有流程并随着时间的推移发展/改进它（改善作为对出现的瓶颈/问题的反应），但是对于一个新的团队/项目来说，完美的流程是什么？

我基本上熟悉敏捷方法和 Scrum。

但什么是“精益软件开发”和“看板”？

可以肯定地说 Scrum、精益和看板是敏捷方法的实现吗？还是精益和看板是不同的方法？

精益和看板是否提供了框架/指南（如敏捷）并将实施留给相邻的一组实践，如 XP 和 Scrum？

在 Scrum 中，很明显我们可以在每个 sprint 之后制作一个演示。

我不知道如何在看板中制作演示，因为它没有 sprint 概念（我可能错了）。

你能告诉我如何在看板中发布吗？

感谢您的帮助和时间。

我正在考虑为看板构建一个 TFS 流程模板。我只是想衡量一下兴趣....

我们正在考虑从 Scrum 转向更多看板风格的开发，但是我不清楚的一件事是如何在看板下监控进度。

我读过可以通过监控每个故事的周期时间来衡量进度，然后大概将这个时间应用于未完成故事的数量。但在我看来，这取决于故事的规模和复杂性，这些故事都可能不同。

我还看到使用燃尽图，那么整个版本会有图表吗？由于积压不​​是固定的（与冲刺期间不同），您是否会允许它在 PO 修改待处理的积压时烧毁/关闭？我想随着你越来越接近释放积压工作应该不那么不稳定，让你可以完成工作。

经过进一步思考，我认为我的问题是我们的经理喜欢燃尽图带来的控制“错觉”。他们倾向于将其（在我看来是错误的）视为时间表，因此能够做出诸如项目“按计划”或“落后于计划”之类的判断。我不太明白这是如何在看板中复制的。也许那是件好事。

我在一个开发团队中作为 .NET 开发人员工作，我们在软件开发过程中使用看板。我们目前正在使用团队基础服务器进行源代码控制，并采用按功能分支的策略来确保我们始终拥有可发布的代码。

由于 Team Foundation Server 中存在一些“限制”，我们即将迁移到 github 以获得更灵活的工具。

我想知道当您有一个应该从多个解决方案/应用程序中使用的公共项目时，设置 git 的最佳方法是什么？它应该是它自己的存储库吗？

设计如何融入看板方法。是否应该有一个专门的设计专栏来放置，或者故事的高层和低层设计甚至在它从故事队列进入 WIP 之前就完成了？

您将如何在软件集成中使用看板？

团队的基本组成可能是：

• 构建和发布团队，
• 两个专家团队，
• 测试组。

构建团队从外部接收构建，构建团队尝试构建它们并运行自动化测试。专家团队处理问题（构建问题、集成问题、测试中发现的问题），例如他们确定问题的原因。

那么最初的任务是否会被称为“发布 X”，然后我们为专家团队生成额外的任务（他们还将承担一些其他职责）？问题是“发布”对于专业团队来说是一项太大的任务，必须分解。但是如果我们没有“发布 X”任务（而只有子任务），我们如何确定发布的状态？

您是否应该为 b&r 团队和专家团队设置单独的任务板？