问看板和Scrum JIRA板的常见类别是什么？

EN

假设看板(我认为答案与Scrum过程不太相关)，您应该使用的通道取决于组织方面的关注，也许取决于您对完成的定义。当您开始通过组织或业务方面的关注而不仅仅是开发方面的考虑时，您可能会开始看到对事物的明显需求。

在我当前的组织中，“准备接受”、“准备发布”(也就是接受的)和“发布的”都在其中，因为我们认为产品负责人接受一个故事是一个重要的门，它并不总是一个即时的事情，取决于PO对业务的其他义务。我们还没有一个持续的部署机制，所以我们仍然有一个通道来处理需要成为发布事件一部分的事情，而且我们可能需要做一些与此相关的工作。然后我们“释放”，主要是为了承认进展。

在另一个组织中，看板不是我们的主要流程，但我们需要处理许多通过多个组织门工作的移动部件，因为我们在为一家高度监管的生物技术企业服务。有些项目是“正在进行中”，意思在开发人员手中，但需要通过“技术编写人员评审”、传统软件测试团队的“测试”工作以及质量保证。(这种区别是行业标准的问题；在传统制造中，QA确保流程按文档的方式工作，而“测试”是质量控制的问题；我们的软件必须通过QA过程，因为我们得到FDA的批准，条件是我们遵循我们记录在案的良好制造实践，就像几年前FDA所记录的那样)。因此，换句话说，尽管软件组织实践了敏捷开发的支持机制，如持续集成、自动化单元和集成测试等等，但各种业务约束意味着我们不得不权衡外部组织方面的关切，这些问题更让人想起遗留式的项目管理。当我们的开发团队试图处理多个工作产品(新特性、旧特性的发布、处理有时跨越多个Scrum迭代的组织和技术问题)时，我们基本上放弃了Scrum，这样我们就可以提供可见性，了解我们正在做的不是开发的事情，并确保所有事情都完成了。当我们的工作不那么依赖于外部利益时，我们再次使用了传统的Scrum风格的项目管理。

如果我是一个小团队，很少有外部利益相关者，我可能会保持我的董事会相当简单。“准备好拉”、“正在进行中”、“发布到生产中”会感觉很好，但如果产品负责人在发布到生产前需要一些通道来检查工作，这并不让我感到惊讶。在一些组织中，在收集了一些关于客户对它的反应或它在生产中如何扩展的数据之后，我才能看到像“A/B测试”或“向10%的用户发布”这样的通道，然后是“向所有客户发布”，这并不令我感到惊讶。

我们也有一些非运输车道项目，如“技术债务”，我们有时认识到，一个故事包含了不适当的接受标准，与其他现有的标准相矛盾的早期功能，或有一些不可预见的后果，需要进一步的讨论或审查，然后才开始懦夫和编写可能不相关的代码。在这种情况下，我们有一个盒子，如果一切正常运作，只会被短暂地访问，标签是“暂停”。

所以教训很简单:找出你的团队真正需要的是什么，并画出这些车道。