Создание и управление ими список невыполненных работ по продукту

Статья
04/10/2013

Автор Митч Лейси.Владелец, Mitch Lacey & Associates, Inc, консультационная фирма, специализирующаяся на принятии и усовершенствовании гибкого подхода и Scrum.

Январь 2012 г.

В этой статье Митч Лейси объясняет важность ведения объема незавершенной работы по продукту, описывает эффективную регистрацию незавершенной работы и дает рекомендации по созданию и ведению соответствующей документации.

Применение

Управление жизненным циклом приложений; Team Foundation Server.

Содержание этой статьи

Введение
Невыполненная работа продукта
- Пользовательские описания функциональности
- Оценка
- Определение приоритетов
Текущий журнал отставания продукта
- Очистка
Заключение

Список невыполненных работ по продукту представляет собой приоритетный список всех функций и возможностей, необходимых для завершения проекта.Хороший список невыполненных работ по продукту лежит в основе хорошей работы гибкой команды и имеет следующие характеристики:

Приоритетом является гарантия того, что команда создает наиболее важные функции в первую очередь.
Оно оценивается командой, чтобы дать ясность владельцу продукта и ответить на вопросы, такие как "Когда будут внесены эти описания функциональности?"
Оно включает всю работу, необходимую для завершения проекта.
Это "живой" документ, постоянно изменяющийся и развивающийся, отражающий текущее состояние проекта.

Хороший список невыполненных работ по продукту не гарантирует автоматически хорошее программное обеспечение.Однако отсутствие хорошего списка невыполненной работы по продукту часто приводит к неполному программному обеспечению, не соответствующему требованиям клиентов и заинтересованных лиц.

Управление списком невыполненных работ по продукту - работа на полный рабочий день.Простые методы могут помочь превратить длительный и сложный процесс в процесс интерактивный и итеративный, в который эффективно вовлекаются члены команды, клиенты и другие заинтересованные лица.Поэтому необходимо изучить надежные методы, помогающие создавать список невыполненных работ по продукту, устанавливать приоритет и поддерживать его.

Невыполненная работа продукта

Список невыполненных работ по продукту представляет собой приоритетный, постоянно обновляемый список всех функций и возможностей, необходимых для завершения проекта.Невыполненные работы по продукту обычно включают пользовательские истории (например, требования), ошибки, задачи исследования (пики) и инженерные улучшения.Эти элементы оцениваются в абстрактных единицах, которые часто называются Баллы описания.

Невыполненная работа по продукту содержит все работы, которых потребует проект, и со временем эволюционирует.Поэтому они содержат не только новые функции для продукта, но и исправления ошибок и исследования — все, что займет время команды.Вся работа, которую команда выполнит, должна поступать из списка невыполненных работ по продукту: парадный вход в проект.Если список невыполненных работ по продукту включает всю работу, владелец продукта, команда и руководство обладают лучшей картиной оставшейся работы, что снижает вероятность появления неожиданностей в последний момент.

В начале любого проекта, маловероятно, что у вас будет чистый, четко определенный список невыполненных работ по продукту, который необходимо оценить назначить приоритет.Вместо этого, скорее всего, у вас будет стопка заметок по описанию функциональности и, возможно, пара функциональных спецификаций.Как владелец продукта, вы должны привести эту путаницу в определенный порядок, чтобы команда могла начать оценку невыполненных работ.

Пользовательские описания функциональности

Первым шагом является преобразование всех идей и заметок в пользовательские описания функциональности, которые выражают требуемую конечным пользователям функциональность (что должно делать ПО), но не подробности ее реализации (как создать ПО, которое соответствует этим требованиям).Имя каждого описания функциональности пользователя должно соответствовать формату "Как (пользователь), я хочу (функция), чтобы (причина)".

Пример карточки описания функциональности

Как и Список невыполненных работ по продукту, каждое Пользовательское описание функциональности будет эволюционировать со временем.На протяжении работы над проектом члены команды приоритизируют и оценивают эти описания функциональности, добавляют в них подробные сведения, разбивают их на более мелкие описания или вообще их удаляют.Те, которые привносятся в спринты, реализованы и доставляются клиентам.

Чтобы узнать больше о Пользовательских описаниях функциональности см. в разделе Создание или невыполненной работы по продукту или добавление в нее элементов и Раскадровка элемент невыполненной работы с помощью PowerPoint.

После преобразования всех идей и примечаний в описания функциональности пользователей, пора оценить и назначить приоритет.

Оценка

По определению, оценка неточная.Однако можно стать значительно лучше в создании относительно точных оценок со временем, благодаря практике и участию всей команды. Первым шагом будет сбор команды для предоставления оценок по элементам задела работы продукта.Когда команда оценивает каждое описание функциональности, она присваивает ему относительное оценку размера в абстрактных единицах измерения, которые называется баллами описаний функциональности.

Оценки необходимы по двум причинам:

Они помогают ответить на следующий вопрос «Когда мы закончим?»
Они помогают владельцу продукта определить приоритет каждого элемента.

Оценки предоставляют владельцу продукта и команде понимание стоимости определенного описания, что, в свою очередь, помогает владельцу продукта назначить приоритет описаний по отношению друг к другу.Чем больше оценка элемента, тем более дорогостоящей в плане времени и ресурсов будет его реализация.Поэтому элемент, который может быть высоко в списке пожеланий владельца продукта, может снизить приоритет, если его производство обойдется дорого.

Команда может использовать покер планирования, большую стену или другие методы для оценки работы в терминах баллов описаний.Дополнительные сведения о методах оценки и быстрый урок о баллах описания см. в разделах Оценка и Оптимизация и оценка невыполненной работы.

После того как команда оценила все описания функциональности, пола назначить приоритеты.

Определение приоритетов

Всем невыполненным работам по продукту назначается приоритет с точки зрения ценности бизнеса и риска.Владелец продукта сравнивает каждый элемент невыполненную работы с другими, чтобы определить его относительный приоритет.Для этого владелец продукта проверяет размер каждого элемента, его значение для компании и любые связанные риски.Элементы затем сортируются по убыванию приоритета.Высокоприоритетные элементы появляются в верхней части списка невыполненной работы по продукту или рядом с ней, а низкоприоритетные элементы находятся в нижней части или рядом с ней.Команды выбирают работу на ближайший спринт из элементов с наивысшим приоритетом, чтобы самые важные элементы были завершены в первую очередь.

Не все элементы невыполненной работы имеют одинаковый размер.Некоторые могут быть завершены в одном спринте, тогда как другие настолько велики, что команда не может с уверенностью сказать, что они за собой влекут или сколько времени займет их реализация.Это нормально.По мере того, как элементы переходят ближе к верхней части списка невыполненной работы, команда делает их более мелкими и сфокусированными, чтобы каждый лучше понимал работу, с которой придется столкнуться в предстоящих спринтах.

Как и в случае с оценкой, назначение приоритетов для первоначального списка невыполненных работ по продукту может быть ошеломительным.Как эффективно достигается баланс конкурирующих между собой требований заинтересованного лица при одновременном учете конечного продукта, рисков и затрат?Удачливо, существуют несколько методов, которые выполняют задачи проще, например игры нововведения и относительные весовой коэффициент.Дополнительные сведения об этих и других методах см. в разделах Определения приоритетов и Оптимизация и оценка невыполненной работы.

Какой бы метод определения приоритетов вы ни выбрали, необходимо упорядочить работы, чтобы убедиться, что команда создает функции, которые предоставляют наибольшую ценность для бизнеса, заинтересованных лиц и клиентов.Если в работе не определяются приоритеты, возрастает риск доставки описаний функциональности пользователей с более низким приоритетом вместо описаний с более высоким приоритетом и неполных описания функциональности пользователей, когда ресурсы и расписания меняются.

(Дополнительные сведения о характере элементов невыполненной работы см. в разделах Создание или невыполненной работы по продукту или добавление в нее элементов и Гибкое планирование и итерации).

Текущий журнал отставания продукта

То Что я описывал до сих пор фокусируется на переходе от ничего к оцененной и приоритизированной невыполненной работе по продукту.В отличие от документа требований, невыполненные работы по продукту не создаются в начале проекта, а затем кладутся на полку.Вместо этого список невыполненных работ по продукту разворачивается, связываясь с реальными событиями проекта.Некоторые элементы невыполненной работы по продукту станут нерелевантными, и их нужно будет удалить.Другие всплывут на поверхность, и их понадобится разложить на более мелкие описания функциональности.По мере появления дополнительных требований будут добавляться, оцениваться и приоритизироваться новые пользовательские описания функциональности.

Команда и заинтересованные лица участвуют в создании и управлении списка невыполненных работ по продукту, однако владелец продукта несет за него окончательную ответственность.Владелец продукта должен следить за тем, чтобы список невыполненных работ был чистым, с расставленными приоритетами и актуальным, чтобы и клиенты, и команда имели четкое представление о плане работ, необходимых для выпуска проекта.Даже после полного запуска проекта у владельцев продукта все еще много работы, которую необходимо выполнить для сохранения списка невыполненных работ по продукту в форме:

Добавление и назначение приоритетов новым описаниям функциональности
Запрос, чтобы команда оценила новые описания функциональности и переоценила старые по мере того, как они лучше понимаются
Изучение предстоящих описаний функциональности пользователей вместе с командной для разбития элементов на более мелкие
Встреча с клиентами и заинтересованными лицами для проверки и добавления требований

Любой пользователь может добавлять элементы в невыполненную работу по продукту в любое время, но только владелец продукта может назначить приоритет.Владелец продукта также является единственным, кто может назначить описанию функциональности приоритет.Все другие участники команды и заинтересованные лица должны оставить пустым поле приоритета при добавлении описания функциональности, даже если они используют электронное средство, которое предлагает им эти данные.

При добавлении описания функциональности, владелец продукта выполняет его предварительную оценку приоритета, основываясь на своем понимании его.Он будет обсуждать историю функциональности с ее создателем, чтобы лучше понять ее суметь в свою очередь ответить на вопросы команды.В заданное время во время каждого спринта, владелец продукта встречается с командой для обсуждения новых описаний функциональности и совместной оценки их таким образом, чтобы он мог более точно назначить приоритеты по сравнению с другими описаниями функциональности в списке невыполненных работ.Этот процесс называется очисткой невыполненной работы.

Очистка

Чистка невыполненной работы по продукту, как уже говорилось, должна осуществляться регулярно.

В Scrum рабочая группа должна тратить во время каждого спринта не более 5–15 % рабочего времени на обработку.Команда должна понимать, что появляется и изменяется таким образом, чтобы они могли разбить всех новые большие описания функциональности, по приоритету, оценить все созданные описания функциональности, и выполнить некоторое производное разработку и планирование предстоящих описаний функциональности.Чтобы Убедиться в том, что это происходит, владелец продукта и команда должны, во время каждого собрания по планированию спринта, оставить некоторое время во время этого спринта для приведения Невыполненной работы в порядок.Чтобы узнать больше о планировании спринта, см. в разделе Планирование спринта и Планирование итерации.

Во время двухнедельного спринта мне нравится проводить это собрание на второй неделе.Это дает Владельцу продукта достаточное время, чтобы иметь осмысленные диалоги с клиентами и заинтересованными лицами, понять изменения в бизнесе и прояснить описания функциональности пользователей и описания функциональности, которые новые или приобретают больший приоритет.Это также логично во время спринта начать участвовать в наступающих спринтах.Можно решить, когда созвать собрание.Важно отвести в течение спринта достаточно времени на выполнение мероприятий по чистке.

В ходе типичного собрания по учету работы владелец продукта представляет новые возможности, изменения и свой план на несколько следующих спринтов.Помимо оценки новых описаний функциональности и детализации тех, которые вскоре будут полностью реализованы, во время совещания рабочая группа анализирует текущую архитектуру системы и планирует или разрабатывает функции, которые вскоре будут реализованы.Во время этого процесса оценки описания часто изменяются, и часто появляются новые описания, когда более крупные описания разбиваются на меньшие описания.

Данный процесс кажется простым, но может вызвать затруднения.Для обеспечения гладкости процесса владелец продукта должен быть готов отвечать на вопросы.Если, например, владелец продукта планирует, чтобы в следующем спринте было создано описание функциональности, но не может предоставить четкие сведения, которые требуются команде, чтобы дать хорошую оценку, может произойти конфликт.Если это происходит во время собраний по планированию спринта, координатору Scrum следует обучить владельца продукта тому, какие сведения ему необходимо приносить команде от клиентов и заинтересованных лиц.

В конце каждого собрания по учету работы владелец продукта должен публиковать изменения для заинтересованных лиц и клиентов, чтобы каждый мог просмотреть новые возможности, что планируется выпустить и обновленный план выпуска.

Хороший список невыполненных работ по продукту гарантирует, что создаваемое программное обеспечение содержит наиболее важные функции, определенные в диалогах с клиентами и другими заинтересованными лицами и указанные в пользовательских описаниях функциональности.Чтобы создать и поддерживать эффективную систему учета невыполненной работы по продуктам, необходимо активно и регулярно (во время каждого скрипта) взаимодействовать как с заинтересованными лицами и клиентами, так и с рабочей группой.

Построение хорошего списка невыполненных работ не обеспечивает хорошую систему, но отсутствие хорошего писка невыполненных работ почти наверняка гарантирует, что в конечном счете получится система, не выполняющая то, что просили клиенты.Иначе говоря, если сведения о невыполненной работе не обновляются, очень велика вероятность неудачного завершения проекта.

Владелец продукта — это работа с полной занятостью, и за список невыполненных работ по продукту отвечает именно он.К этой роли необходимо относиться серьезно.Держите список невыполненных работ в порядке и клиенты поблагодарит вас.