问题标签 [kanban]

是否有人将看板（或 scrumban）用于敏捷管理实践？您对看板的体验如何？它如何在依赖瀑布项目的大型复杂环境中工作？

我们有一个四人开发团队，需要一个正式的项目管理系统。我对 Scrum 和看板有一个大致的了解，但在尝试之前很难真正理解。我们没有奢侈的尝试几个星期然后切换到另一个，所以我希望有类似情况的人可能会思考哪个对他们更有效以及为什么。此外，任何其他有效的开发管理系统都会很高兴听到。

另一个注意事项：当然，团队有增长的可能性，所以我们需要一个可扩展的系统。

另一个注意事项：我们在 Windows 中开发三个独立的软件应用程序，所有这些应用程序都基于我们也编写的中央库（所以我猜你可以说四个项目）

我的团队一直在逐步采用越来越多的轻量级方法，从 Scrum 转向精益/看板，那里的正式流程越来越少。在某个时候，我们将回到 Cowboy Coding；事实上，我担心我们可能已经在边界线上。

在非常轻量级的精益和敏捷流程与无政府状态之间可以划清界限吗？我们怎么知道我们什么时候越界了？我们如何防止自己越界？

这个问题也可以表述为，“在精益消除浪费的努力中，哪些流程不能安全地消除”？

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

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

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

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

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

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

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

您会推荐哪些管理看板的工具？

在调查了一点 scrum 和看板之后，我终于阅读了这个答案并决定开始使用看板，从 scrum 中挑选一些东西（请注意，我主要是自己工作，我确实已经阅读了这个问题及其答案）。

现在，我的问题是：哪种工具最适合入门？

1. 白板和便利贴
2. 敏捷网站
3. JIRA 与 greenhopper
4. 电子表格（可能在 Google Docs 上）
5. Brightgreenprojects.com
6. 阿吉洛
7. 目标进程
8. 其他（请注明）

关于每个的注释：

1. 我会倾向于使用白板，但有几个缺点（例如，无法制作自动图表、时间测量、指标，有时我在家工作——我最需要它——而且携带不方便 :-)

2. 我不想记住另一个用户名/密码（我答应自己只注册支持 OpenID 的服务）

3. 我的雇主有 JIRA，但我的团队不使用它——我可能会要求一个帐户（它不应该需要另一个密码），然后可能会涉及到团队的其他成员。但我不知道他们是否在使用 greenhopper，以及安装它是否很重要。

4. 我通常讨厌电子表格

5. 也许矫枉过正？

6. 我很高兴拥有一个 localhost 实例，但授予对整个组的访问权限（每个网络/防火墙）可能会出现问题 - 这不是一个交易破坏者，但肯定是一个问题

我想从中得到什么？

• 更有生产力
• 跟踪我在任何给定任务上花费了多少时间，可能与我的主管讨论这个问题
• 跟踪最常“阻止”我的东西
• 立即查看我与我的日程安排相比的位置
• 以更好的方式管理我长长的待办事项列表（例如更快地回答“我接下来应该做什么？”问题）

你有什么建议吗？

注意 scrumish 标签：阅读Henrik Kniberg 的 PDF。他首先在第 9 页介绍了 scrumish 的定义。

我刚刚在我的团队中实施了看板，并开始跨时间跟踪项目的状态。我们已经到了要在这个系统下发布我们的第一个版本的地步，我有一个关于如何处理完成的工作项的问题。

我们有一个“已完成”状态，它表示已被客户接受并准备发货的工作项目。这个想法是在发货时将项目从板上完全删除，或者当它们被认为“完成”时（对于基础设施任务等）。但是，如果我们从完成中删除项目，CFD 会大幅下降（例如，我们现在有 11 个已完成的项目，而处于“活动”状态的项目有 14 个，例如没有积压）。我可以这样做，因为它很清楚地显示了何时发布，但我还没有看到任何已发布的 CFD 这样做。我见过的每一个差价合约似乎都永远呈上升趋势。

是否有任何共识或“最佳实践”（包含该术语所暗示的所有警告）支持或反对从 CFD 中删除项目？值得注意的是，出于工程和端到端周期时间的目的，我正在跟踪已发货/已关闭的项目，但这些指标是单独跟踪的。

是否有任何插件/应用程序可以在看板板上展示/管理来自 Trac 错误跟踪系统的工单？例如，我希望能够通过在板上拖放它们来更改 Trac 票的状态。我尝试了一些独立工具，例如 AgileZen，但我找不到将它们与 Trac 集成的方法。

我很好奇其他人在他们的公司中将什么用于物理看板/Scrum 板。我很感激由于敏感的商业信息，您可能无法提供董事会的照片。我正在寻找您的董事会是什么样的，以及您如何组织用户故事和任务，因为他们通过一个典型的冲刺/迭代？

通常，我曾在一个组织董事会的地方工作过

所以总结一下：

• UC-001 的一项任务正在由团队的一名成员 (Bob) 进行。待办事项列中正在等待其他人完成的任务列表，但可以由与 Bob 协调完成工作的团队中的其他成员提取。
• 对于 UC-002，支付服务任务已完成，并为 QA 完成了自动化测试工具，允许他们在没有 UI 的情况下测试服务。如果测试失败，则会引发错误并与支付服务任务一起移回 QA 阶段
• UC-003 的所有任务都已完成并移至准备好进行 QA。
• UC-004 和 UC-005 的所有任务都已完成，因此用户故事已移至完成。

这就像一个有形的白板，涉及人们与每个任务/用户故事（表示为便笺）进行交互。电子版本在冲刺/迭代之前创建，并且仅在与当前情况相对应的冲刺/迭代结束时更新。欢迎评论和批评：）

有没有人使用看板方法进行软件开发管理？

我正在评估看板作为一种技术，并且很想听听任何在实践中实际应用它的人关于它的有效性。我见过这样的问题：is-anyone-using-kanban、kanban-vs-scrum和apply-kanban-in-an-agile-team，但它们并没有解决我的担忧。

我特别感兴趣的是：

1. 它是否真的提供了动态识别瓶颈方面的优势？
2. 它在实践中是否容易执行，或者它是否存在您需要管理的后勤挑战？
3. 它是否可以很好地扩展到具有许多并行工作流和许多开发人员的项目团队？
4. 它与关键路径分析（在 MS Project 中实施）相比如何，有何不同？
5. 应用看板还能获得哪些其他好处？

谢谢。