Эта статья была создана в сотрудничестве с Quire . Спасибо за поддержку партнеров, которые делают возможным использование SitePoint.
Отставание продукта, вероятно, является одним из самых противоречивых и неправильно понятых артефактов гибкой организации. Кажется, что у каждого есть мнение о том, что должно быть на нем, как это должно быть организовано, и кто должен управлять этим. В результате, создание и управление бэклогами продуктов стало скорее темным искусством, чем наукой. Инструменты, которые оптимизированы для работы в гибкой команде, иногда плохо работают для владельца продукта, пытающегося отслеживать истории, над которыми команда еще не начала работать.
Владельцы продуктов могут захотеть рассмотреть один из возможных вариантов — это Quire , программный инструмент для онлайн-управления проектами с отслеживанием задач и подзадач, а также функциями платы Kanban, которые могут идти в ногу с гибкой командой, оставаясь при этом незаметными в отношении того, как владелец продукта создает новые функции и продукт усовершенствования. Люди из Quire обратились ко мне, чтобы посмотреть на их продукт, и, возможно, они нашли решение, которое будет работать для владельцев продуктов, создавая и поддерживая отставание для своих команд.
Что такое продуктовый бэклог и как вы им управляете?
Журнал незавершенного производства — это набор потенциальных историй, описывающих функции, над которыми в конечном итоге может работать команда, каждый из которых повышает ценность для клиента. В Scrum и Kanban-е истории представляют собой отдельные вертикально разделенные на куски функциональные возможности конечного пользователя, которые являются независимыми, предметом переговоров, ценными, оцениваемыми, небольшими и проверяемыми .
Это сильно отличается от организации водопада, где каждая часть работы может быть тщательно продуманной задачей в гораздо более крупном плане, который в конечном итоге должен повысить ценность для клиента. Задачи диаграммы Ганта обычно представляются в виде последовательных и взаимозависимых строительных блоков из документа с требованиями к продукту, представленного в виде подробной диаграммы Ганта или чего-то подобного.
Гибкая команда не по умолчанию использует диаграммы Ганта или подробные предварительные планы. Перед тем, как команда решит связать его с владельцем продукта, гибкая история обычно гораздо менее детализирована, чем типичная задача диаграммы Ганта, основанная на целях клиента, которые увеличивают ценность, и с критериями приемлемости, написанными в читаемом синтаксисе Gherkin для ясности. Неуместная потенциальная история должна создать возможность обсуждения с остальной командой о том, что и как следует разрабатывать.
В результате изменения в списке продуктов могут выглядеть так, как владелец продукта хочет, чтобы они просматривали, чтобы стимулировать это обсуждение. И это затрудняет поиск последовательного способа управления и хранения неумелых историй, чтобы их можно было отслеживать и организовывать в контексте активной команды разработчиков.
Где хранить бэклог продукта?
В отличие от многих гибких артефактов, которые процветают в свете прозрачности, отставание продукта на самом деле выигрывает от небольшой секретности. Это место, где владелец продукта может фантазировать о том, что может пожелать пользователь, и отслеживать внешние требования, а также эксперименты, которые проводятся во время тестирования пользовательского опыта. Только после того, как какая-либо функция была подготовлена, и команда начинает разработку, эти потенциальные истории необходимо преобразовать в формат, которым можно поделиться с остальной командой.
И это самая сложная часть. Часто владелец продукта по умолчанию разрабатывает свои будущие функции в том же инструменте, который будет использоваться для публикации и отслеживания их в виде историй, таких как JIRA Agile. Большинство из этих инструментов ожидают, что их истории будут заполнены оценками, эпопеями, зависимостями, владельцами и т. Д.
Полнофункциональные инструменты гибкого отслеживания часто должны настраиваться мастером схватки или кем-то еще в организации, чтобы соответствовать согласованным стандартам, которые ограничивают возможности написания и редактирования историй. Эти настройки могут не дать владельцу продукта возможность сохранять конфиденциальные истории, прежде чем они будут готовы поделиться с командой, если истории не написаны на отдельной доске, а затем перенесены на доску команды. Это намного сложнее, чем владелец продукта должен думать на ранней стадии отставания продукта.
Некоторые владельцы продуктов просто записывают свои планы в текстовом редакторе, копируя и вставляя текст в соответствующий инструмент, когда это необходимо. Несмотря на то, что в этом есть преимущества знакомой и удобной среды написания, сложно отслеживать несколько функций разработки с различными уровнями детализации. Текстовые процессоры также не позволяют легко отслеживать, над какими историями работает команда, пока вы разрабатываете новую функциональность.
Электронные таблицы могут упростить отслеживание отношений и ассоциаций, но они также побуждают владельца продукта глубже погрузиться в сорняки более водопадного процесса, рассматривая истории как последовательные элементы, а не как отдельные независимые функции со своей собственной ценностью. Электронные таблицы также не поддерживают очень удобную среду редактирования для написания и управления историями.
Таким образом, лучшим решением для обоих миров может быть легкая и независимая система отслеживания гибких проектов, такая как Quire. Используя основанный на задачах интерфейс в Quire, можно вести постоянную историю всех историй, над которыми работает команда, и одновременно разрабатывать новые идеи, чтобы подумать о том, как они могли бы вписаться и расставить приоритеты, как только они будут готовы к команда, чтобы начать работать над ними.
Какая информация должна войти в журнал ожидания продукта?
В гибкой организации истории представляют собой возможные направления использования всего продукта для повышения ценности для клиента, а не фиксированные требования с промежуточными сроками, которые могут или не могут быть обусловлены внутренней ценностью, которую они предоставляют. Quire позволяет владельцу продукта вести настолько глубокий список потенциальных изменений и функций, насколько они захотят, в различных состояниях готовности и с документацией или без нее, реорганизуя и перетасовывая их соответствующим образом, прежде чем представлять их команде для подготовки и разработки. Quire вызывает эти задачи, что является полезным соглашением об именах, поскольку они могут или не могут стать настоящими историями до тех пор, пока команда не выполнит их и не примет их и не начнет их работать.
Владелец продукта зависит от того, сколько или мало информации попадает в журнал ожидания продукта, поэтому очень важно иметь гибкий инструмент, который справится с работой и уйдет с пути. Каждое задание в Quire должно собирать достаточно информации, чтобы передать видение владельца продукта и стимулировать творческий подход команды при ее представлении. Quire даже поддерживает тегирование и фильтрацию, поэтому задачи могут быть помечены как выполняемые, исправления ошибок или все, что имеет смысл для конкретной ситуации.
Там могут быть полностью реализованные функции …
… мелкие исправления ошибок, опционально включая подзадачи …
… или они могут быть причудливыми однострочными стремлениями, наполненными потенциальными подзадачами и подзадачами, даже такими, которые технически невозможны.
Иногда очень ясно, какими могут быть критерии приемлемости, хотя обычно эти критерии принятия необходимо уточнять в беседе с командой. В Quire ничего не сказано о том, где вы их создали, но логическое место в поле описания для задачи.
Задачи с невыполненной работой по продукту также могут быть обусловлены очень специфическими техническими требованиями, тестированием пользовательского опыта и другой документацией, которая должна быть связана с ними, поэтому это удобно, если вы используете такой инструмент, как Quire, который позволяет вам прикреплять другие документы к отдельному человеку. задача. Он даже имеет интеграцию с Google Drive.
Кому нужно видеть бэклог продукта?
Задачи Quire могут быть сохранены в бэклоге продукта на всех этапах планирования, но к тому времени, когда они представлены команде, они должны быть готовы к полному обсуждению. Мне нравится думать о невыполненных продуктах как о волшебной сумке секретов, которые контролирует владелец продукта. Со временем и с соответствующей помпой владелец продукта может сообщать о своих планах команде и привлекать их ценностью, которую эти новые функции обещают конечному пользователю.
Это не означает, что команда должна быть в неведении относительно того, куда направлен продукт. Причина, по которой владелец продукта сидит в команде разработчиков, заключается в том, что может быть постоянный диалог вперед-назад по мере разработки функций и создания планов будущих функций. Но одно из преимуществ гибкой работы заключается в том, что команда может продуктивно сосредоточиться на историях, поскольку они определены и подготовлены, не беспокоясь о том, что они будут прерваны ползучестью из-за изменения требований после начала работы.
Поэтому необходимо запрашивать обратную связь от разработчиков по мере необходимости, чтобы убедиться, что потенциальная функция возможна, но к обсуждению необходимо относиться осторожно, чтобы команда не истолковывала потенциальную новую функцию или усовершенствование как обязательный переход к работе, в настоящее время находящейся в стадии разработки. прогресс.
Такие инструменты, как Quire, которые находятся за пределами традиционных гибких инструментов раскадровки, очень полезны для сохранения конфиденциальности невыполненной работы продукта. Нет необходимости устанавливать специальные разрешения для описания функций, над которыми никогда не будет работать, поэтому команда не отвлекается. Это позволяет владельцу продукта избегать загрязнения незавершенного производства возможными изменениями в будущем. Поскольку работа с продуктом ведется с помощью отдельного инструмента, прямой доступ должен иметь только владелец продукта.
Как вы синхронизируете бэклог продукта с командой?
Последняя проблема, связанная с решением о невыполненной работе продукта, заключается в том, насколько хорошо он может синхронизироваться с работой, которую выполняет команда. Одним из основных преимуществ использования общего инструмента, который могут видеть все в команде, является то, что любые изменения немедленно отражаются для всех, кто использует одну и ту же доску. Но обычно это происходит за счет того, что потенциальные будущие функции остаются в секрете, пока команде не придет время готовить реальные истории.
Если владелец продукта пытается сохранить отставание, используя негибкий инструмент, такой как электронная таблица или текстовый процессор, сложность увеличивается вдвое. Мало того, что требуется ручная синхронизация отставания с работой, которую выполняет команда, это также означает разработку системы кодирования идей, чтобы было ясно, в каком состоянии они находятся. Например, как владелец продукта будет различать текстовый процессор Отставание среди функций, которые находятся в стадии разработки, которые могут никогда не произойти, или которые полностью разработаны и развернуты?
Требуется гибкий ноутбук, и Quire превосходно справляется с этой задачей. Стандартный интерфейс Quire содержит достаточно деталей для создания и отслеживания хода выполнения задач по мере их реализации, не мешая творческому процессу для владельца продукта. Но Quire также предоставляет настраиваемое представление доски Kanban, которое владелец продукта может использовать для отслеживания состояния задач после того, как они были подготовлены и перенесены в другие системы в виде полностью оцененных историй, не мешая остальной части команды.
Конфигурируя представление доски Kanban для соответствия состояниям, которые использует команда, владелец продукта может добавлять задачи Quire на доску и отслеживать их прогресс в процессе разработки и развертывания по мере продвижения команды вперед. Это так же просто, как щелкнуть значок доски в подробном представлении задачи …
… И выберите настроенную доску Канбан, а затем переключитесь на представление Канбан, чтобы перетаскивать задачи.
При использовании этого способа Quire также может создавать отчеты о состоянии историй в разработке с помощью встроенных инструментов, используя привлекательные и удобные для исполнительного руководства диаграммы и графики. На них можно ссылаться в ходе обсуждений с руководителями и заинтересованными сторонами или делиться ими с командой, если владелец продукта считает это целесообразным.
Если команда находит их полезными, они доступны, но владелец продукта может решить, что некоторые диаграммы, такие как представление диаграммы Ганта в Quire о потенциальной запланированной работе, не добавят ценности или могут фактически отвлечь внимание от гибкой команды.
Создание и ведение журнала незавершенного производства является важной частью роли владельца продукта. Владелец продукта должен поддерживать резерв, чтобы облегчить создание и отслеживание приоритетов потенциальных историй для команды, над которой нужно работать. Из-за его собственной интеграции функций Kanban в ориентированном на задачи интерфейсе и удобного вложенного интерфейса подзадач Quire может быть лучшим решением, чем пытаться использовать ту же доску, которую использует команда для активных историй, или объединять пользовательское решение с электронными таблицами и текстовые процессоры.