如何使用Quire管理产品积压

This article was created in partnership with Quire. Thank you for supporting the partners who make SitePoint possible.

本文是与Quire合作创建的。 感谢您支持使SitePoint成为可能的合作伙伴。

The product backlog is probably one of the most controversial and misunderstood artifacts of an agile organization. Everybody seems to have an opinion about what should be on it, how it should be organized, and who should manage it. As a result, creating and managing product backlogs has become more of a dark art than a science. Tools that are optimized for running an agile team sometimes don’t work well for a product owner trying to keep track of stories that the team hasn’t started working on yet.

产品积压可能是敏捷组织中最具争议和误解的工件之一。 似乎每个人都对应包含的内容，应如何组织以及应由谁进行管理有意见。 结果，创建和管理产品积压已不再是一门科学，而是一门黑手艺。 对于负责跟踪团队尚未开始工作的故事的产品负责人而言，为运行敏捷团队而优化的工具有时效果不佳。

One option product owners might want to consider is Quire, an online project management software tool with task and subtask tracking as well as Kanban board features, that can keep pace with an agile team while remaining unopinionated about how a product owner crafts upcoming features and product enhancements. The folks at Quire reached out to me to take a look at their product, and they may have come up with a solution that would work for product owners creating and maintaining a backlog for their teams.

产品所有者可能要考虑的一个选择是Quire ，它是一种具有任务和子任务跟踪以及看板功能的在线项目管理软件工具，可以与敏捷团队保持同步，同时对产品所有者如何设计即将发布的功能和产品保持不受质疑。增强功能。 Quire的人们与我联系来查看他们的产品，他们可能想出了一个解决方案，该解决方案适用于产品所有者创建和维护其团队的积压工作。

什么是产品积压，您如何管理？ (What is a Product Backlog, and How Do You Manage One?)

A product backlog is a collection of potential stories describing features a team may work on eventually that each add value for the customer. In scrum and Kanban, stories are discrete vertically sliced chunks of end-user functionality that are independent, negotiable, valuable, estimable, small, and testable.

产品积压订单是潜在故事的集合，这些故事描述了团队最终可以为客户增加价值的功能。 在Scrum和看板中，故事是最终用户功能的垂直分割的离散块，这些块是独立的，可协商的，有价值的，可估计的，较小的和可测试的 。

That’s quite different from a waterfall organization, where each chunk of work may be a thoroughly thought out task in a much larger plan that should eventually add value for a customer. Gantt chart tasks are usually presented as sequential and interdependent building blocks from a product requirements document represented by a detailed Gantt chart or something similar.

这与瀑布式组织完全不同，瀑布式组织中的每一项工作都是一项更大计划中经过深思熟虑的任务，最终将为客户增加价值。 甘特图任务通常以详细的甘特图或类似形式表示的产品需求文档中的顺序和相互依存的构建块表示。

An agile team doesn’t default to Gantt charts or detailed up-front plans. Before the team sits down to groom it with the product owner, an agile story is usually much less detailed than a typical Gantt chart task, driven by customer objectives that add value, and with acceptance criteria written in readable Gherkin syntax for clarity. An ungroomed potential story should create an opportunity discussion with the rest of the team about what should be developed and how.

敏捷团队不会默认使用甘特图或详细的前期计划。 在团队坐下来与产品负责人进行梳理之前，敏捷的故事通常比典型的甘特图任务要详细得多，这要归功于客户目标的增值作用，以及以清晰的Gherkin语法编写的验收标准。 一个未整理的潜在故事应该与团队的其他成员就如何发展以及如何发展进行一次机会讨论。

As a result, the changes in the product backlog can look however the product owner wants them to look in order to stimulate that discussion. And this makes it challenging to find a consistent way to manage and store ungroomed stories so they can be tracked and organized in the context of an active development team.

结果，可以查看产品积压中的更改，但是产品所有者希望他们查看以激发讨论。 因此，要找到一种一致的方式来管理和存储未整理的故事，以便在活跃的开发团队的情况下对其进行跟踪和组织，将是一项挑战。

产品待办事项应存储在哪里？ (Where Should the Product Backlog Be Stored?)

Unlike many agile artifacts, which thrive in the light of transparency, the product backlog actually benefits from a little bit of secrecy. This is a place where the product owner can fantasize about what the user might want, and keep track of external requirements as well as experiments that are underway during user experience testing. Only once a feature has been groomed and the team start development do these potential stories need to be converted to a format that can be shared with the rest of the team.

不像许多敏捷工件(这些工件因透明性而蓬勃发展)那样，积压的产品实际上受益于一些保密性。 在这里，产品所有者可以幻想用户可能想要的东西，并跟踪外部需求以及用户体验测试期间正在进行的实验。 仅在对功能进行了修饰并且团队开始开发之后，才需要将这些潜在的故事转换为可以与团队其他成员共享的格式。

And that’s the hard part. Often a product owner will default to developing their upcoming features in the same tool that will be used for sharing and tracking them as stories, such as JIRA Agile. Most of these tools expect their stories to be populated with estimates, epics, dependencies, owners, etc.

这就是困难的部分。 通常，产品所有者会默认使用同一工具开发即将发布的功能，该工具将用于将其作为故事进行共享和跟踪，例如JIRA Agile。 这些工具大多数都希望他们的故事充满估计，史诗，依赖性，所有者等。

Full-featured agile tracking tools often need to be configured by a scrum master or someone else in the organization to meet agreed standards that limit how stories can be written and edited. Those settings may not give a product owner the option to keep potential stories private before they are ready to share with the team unless the stories are written on a separate board and then transferred later to the team board. That’s a lot more complexity than a product owner needs to think about at the early product backlog stage.

功能齐全的敏捷跟踪工具通常需要Scrum管理员或组织中的其他人来配置，以达到商定的标准，这些标准限制了故事的编写和编辑方式。 这些设置可能不会给产品所有者提供选择，让他们可以与团队共享之前将潜在故事保密，除非将故事写在单独的板上，然后再转移到团队板上。 这比产品所有者在早期产品积压阶段需要考虑的复杂性高得多。

Some product owners just write up their plans in word processor, copying and pasting the text into the appropriate tool when necessary. While this has the advantages of being a familiar and convenient writing environment, it’s difficult to keep track of multiple developing features with various levels of detail. Word processors also don’t provide an easy way to keep track of what stories the team is actually working on are while you’re developing new functionality.

一些产品所有者只是在文字处理器中编写他们的计划，并在必要时将文本复制并粘贴到适当的工具中。 尽管这样做具有成为熟悉且方便的书写环境的优点，但是很难跟踪具有各种细节级别的多个开发功能。 在开发新功能时，文字处理器也无法提供一种轻松的方式来跟踪团队实际正在处理的故事。

Spreadsheets can make it easier to keep track of relationships and associations, but they also tempt a product owner to go deeper into the weeds of a more waterfall process, thinking about stories as sequential elements rather than individual independent features with their own value. Spreadsheets also don’t support a very convenient editing environment for writing and manipulating stories.

电子表格可以使跟踪关系和关联更容易，但是它们也诱使产品所有者更深入地了解更多瀑布过程，将故事视为顺序元素，而不是具有自己价值的独立要素。 电子表格也不支持用于编写和操作故事的非常方便的编辑环境。

So a best of both worlds solution might be a lightweight and independent agile project tracking system like Quire. Using the task-based interface in Quire, it’s possible to keep a running history of all of the stories the team is working on, and simultaneously develop new ideas to think about how they might fit in and be prioritized once they’re ready for the team to start working on them.

因此，两全其美的解决方案可能是像Quire这样的轻量级且独立的敏捷项目跟踪系统。 使用Quire中基于任务的界面，可以保持团队正在处理的所有故事的运行历史记录，并同时开发新的想法，以考虑它们可能适合并在为准备工作做好准备时得到优先考虑。团队开始研究他们。

产品积压中应包含哪些信息？ (What Information Should Go into a Product Backlog?)

In an agile organization, stories represent possible directions to take the overall product to add value for the customer, not fixed requirements with intermediate deadlines that may or may not be driven by the intrinsic value they deliver. Quire allows the product owner to maintain as deep a list of potential changes and features as they like, in various states of preparedness and with or without documentation, reorganizing and shuffling them as appropriate before presenting them to a team for grooming and development. Quire calls these tasks, which is a useful naming convention since they may or may not become true stories until a team grooms and accepts them and starts working on them.

在敏捷的组织中，故事代表了可能的方向，以使整个产品为客户增加价值，而不是固定的要求，中间期限可能由交付的内在价值驱动，也可能不受驱动。 Quire允许产品所有者在各种准备状态下(无论有无文件记录)，根据需要保留尽可能深的潜在更改和功能列表，在将其提交给团队进行修饰和开发之前，适当地进行重组和改组。 Quire称为这些任务，这是一个有用的命名约定，因为在团队修饰并接受它们并开始进行处理之前，它们可能会或可能不会成为真实的故事。

It’s up to the product owner how much or how little information goes into the product backlog, so having a flexible tool that will get the job done and get out of the way is essential. Each task in Quire needs to capture just enough information that it will convey the vision of the product owner, and stimulate the creativity of the team when it’s presented. Quire even supports tagging and filtering, so tasks can be labeled as in-progress, bug fixes, or whatever makes sense for a particular situation.

产品积压的多少取决于产品所有者，因此拥有一个灵活的工具来完成工作并避免麻烦是至关重要的。 Quire中的每个任务都需要捕获足够的信息，以传达产品所有者的愿景，并在提出产品时激发团队的创造力。 Quire甚至支持标记和过滤，因此可以将任务标记为进行中，错误修复或在特定情况下有意义的标记。

There can be fully fleshed out features…

可以完全充实功能...

…tiny bug fixes, optionally including subtasks…

…微小的错误修复，可选地包括子任务…

…or they can be fanciful one-line aspirations fleshed out with potential subtasks and sub-subtasks, even ones that might not be technically possible.

…或者它们可以是潜在的子任务和子子任务充实的单行愿望，甚至在技术上可能是不可能的。

Sometimes it’s very clear what the acceptance criteria might be, although usually those acceptance criteria need to be fleshed out in conversation with the team. Quire is unopinionated about where you create these, but the logical place is in the description field for the task.

有时，很清楚接受标准可能是什么，尽管通常需要在与团队交谈时充实那些接受标准。 有关创建这些对象的位置，Quire不受限制，但逻辑位置在任务的描述字段中。

Product backlog tasks also may be driven by very specific technical requirements, user experience testing, and other documentation that needs to be associated with them, so is convenient if you’re using a tool like Quire that allows you to attach other documents to an individual task. It even has Google Drive integration.

产品积压任务也可能由非常具体的技术要求，用户体验测试以及需要与之相关联的其他文档驱动，因此如果您使用的是Quire之类的工具，该工具可让您将其他文档附加到个人，则非常方便任务。 它甚至具有Google云端硬盘集成功能。

谁需要查看积压的产品？ (Who Needs to See the Product Backlog?)

Quire tasks can be kept in the product backlog at all stages of planning, but by the time they’re presented to the team they should be ready for a complete discussion. I like to think of the product backlog as a magic bag of secrets a product owner controls. Over time, and with appropriate fanfare, the product owner can reveal plans to the team and engage them with the value that these new features promise to the end user.

在计划的所有阶段，都可以将需求任务保留在产品积压中，但是在将其提交给团队时，他们应该准备进行完整的讨论。 我喜欢将产品积压视为产品所有者控制的不可思议的秘密。 随着时间的流逝，产品所有者可以适当地大声疾呼，向团队透露计划，并以这些新功能对最终用户所承诺的价值与他们进行互动。

Which is not to say that the team must be kept in the dark about where the product is headed. The reason a product owner sits with the development team is so that there can be a constant back and forth dialogue as features are developed and as plans for future features are being created. But one of the benefits of working in an agile way is that the team can productively focus on stories as they are defined and groomed without worrying that they will be interrupted by scope creep from shifting requirements after the work has started.

这并不是说团队必须对产品的发展方向保持黑暗。 产品负责人坐在开发团队中的原因是，可以在开发功能和制定未来功能的计划时进行持续的来回对话。 但是，以敏捷的方式进行工作的好处之一是，团队可以高效地专注于定义和修饰的故事，而不必担心工作开始后因需求变化而引起的范围变化会干扰故事的进行。

So feedback should be sought from the developers as needed to make sure a potential feature is possible, but the discussion needs to be handled carefully, so the team doesn’t misinterpret a potential new feature or enhancement as a mandatory shift to the work currently in progress.

因此，应根据需要从开发人员那里征求反馈意见，以确保可能使用潜在功能，但是讨论必须谨慎进行，因此团队不会将潜在的新功能或增强功能误解为当前工作的强制性转变。进展。

Tools like Quire, that sit outside of the traditional agile storyboard tools, are very useful for maintaining the privacy of a product backlog. There’s no need for setting special permissions on descriptions of features that may never be worked on so the team doesn’t get distracted. That allows a product owner to avoid contaminating the work in progress with possible changes coming down the road. Since the product backlog is being managed with a separate tool, only the product owner needs to have direct access.

位于传统敏捷情节提要板工具之外的Quire之类的工具对于维护产品积压的隐私非常有用。 无需为可能永远无法使用的功能描述设置特殊权限，以免团队分散注意力。 这样一来，产品所有者就可以避免正在进行的更改而污染正在进行的工作。 由于产品积压是使用单独的工具进行管理的，因此仅产品所有者需要直接访问。

您如何使产品积压与团队保持同步？ (How Do You Keep the Product Backlog in Sync with the Team?)

The final challenge for a product backlog solution is how well it can stay in sync with the work the team is doing. One of the main advantages of using a shared tool that everyone on the team can see is that any changes are immediately reflected to everyone using the same board. But that usually comes at the cost of being able to keep potential future features private until it’s time for the team to start grooming real stories.

产品积压解决方案的最终挑战是如何与团队正在进行的工作保持同步。 使用团队中每个人都可以看到的共享工具的主要优势之一是，任何更改都会立即反映给使用同一板的每个人。 但这通常是以能够将潜在的将来功能保密为代价的，直到团队开始整理真实故事的时候。

If the product owner tries to maintain the backlog using a non-agile tool, such as a spreadsheet or a word processor, the difficulty is doubled. Not only does it require manually synchronizing the backlog with the work the team is doing, it also means developing a system of coding the ideas so that it’s clear what state they are in. For example, how would a product owner distinguish in a word processor backlog among features that are in progress, that may never happen, or that are fully developed and deployed?

如果产品负责人试图使用诸如电子表格或文字处理程序之类的非敏捷工具来维护积压工作，那么难度将增加一倍。 它不仅需要手动将积压工作与团队正在做的工作同步，还意味着开发一个对构想进行编码的系统，以便清楚地知道它们处于什么状态。例如，产品所有者如何在文字处理器中进行区分正在进行中，可能永远不会发生或已完全开发和部署的功能之间的积压工作？

An agile-friendly notebook is what’s needed, and Quire serves that purpose admirably. The default Quire interface includes just enough detail to create and track the progress of tasks as they get fleshed out without getting in the way of the creative process for the product owner. But Quire also provides a customizable Kanban board view that product owner can use to track the status of tasks after they have been groomed and transferred to other systems as fully estimated stories, without interfering with the rest of the team.

需要一款敏捷的笔记本电脑，Quire可以出色地实现这一目的。 默认的Quire界面仅包含足够的细节，可以在任务充实时创建和跟踪任务的进度，而不会妨碍产品所有者的创作过程。 但是Quire还提供了可自定义的看板板视图，产品所有者可以在整理任务并将它们作为完全估计的故事转移到其他系统后，用来跟踪任务的状态，而不会干扰团队的其他成员。

By configuring the Kanban board view to match the states the team is using, a product owner has the option of adding Quire tasks to the board and tracking their progress through development and deployment as the team moves forward. It’s as easy as clicking the Board icon in the task detail view…

通过配置看板面板视图以匹配团队使用的状态，产品所有者可以选择向平台添加Quire任务，并在团队前进时跟踪开发和部署过程中的进度。 就像在任务详细信息视图中单击“董事会”图标一样简单...

…and selecting the configured Kanban board, and then switching to the Kanban view to drag tasks around.

…并选择已配置的看板，然后切换到看板视图以拖动任务。

If used this way, Quire can also generate reports on the status of stories in development with integrated tools, using attractive and executive-friendly charts and graphs. These can be referenced in discussions with executives and stakeholders or shared with the team as the product owner sees fit.

如果以这种方式使用，Quire还可以使用吸引人的，易于执行的图表和图形，使用集成工具生成有关开发中故事状态的报告。 这些可以在与主管和利益相关者的讨论中引用，也可以在产品所有者认为合适时与团队共享。

If the team finds them useful, they’re available, but the product owner may decide that some charts, such as Quire’s Gantt chart view of potential planned work, don’t add value or may actually be a distraction to an agile team.

如果团队认为它们有用，则可以使用它们，但是产品负责人可能会决定某些图表(例如Quire的甘特图对潜在计划工作的视图)不会增加价值，或者实际上可能分散敏捷团队的注意力。

Creating and maintaining a product backlog is an essential part of the role of the product owner. The product owner needs to maintain a backlog to facilitate creating and tracking the priority of potential stories for the team to work on. Because of its native integration of Kanban features in a task-oriented interface, and its convenient nested subtask interface, Quire may be a better solution than trying to use the same board the team uses for active stories, or cobbling together a custom solution with spreadsheets and word processors.

创建和维护产品积压工作是产品所有者角色的重要组成部分。 产品负责人需要保持积压，以便于创建和跟踪潜在故事的优先级，以供团队进行工作。 由于将看板功能本地集成在面向任务的界面中，并且具有方便的嵌套子任务界面，因此，与尝试使用团队用于活动故事的同一板子或将自定义解决方案与电子表格整合在一起相比， Quire可能是更好的解决方案和文字处理器。

翻译自: https://www.sitepoint.com/how-to-manage-your-product-backlog-with-quire/