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

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

Январь 2012

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

Применение

Application Lifecycle Management; Team Foundation Server (TFS)

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

  • Введение

  • Список невыполненной работы продукта

    • Пользовательские истории

    • Оценка

    • Расстановка приоритетов

  • Динамичный список невыполненной работы продукта

    • Груминг

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

Хороший список невыполненной работы по продукту лежит в основе хорошей работающей команды Agile и обладает следующими характеристиками.

  • Он приоритизирован, чтобы группа сначала реализовала самые важные возможности.

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

  • Он содержит все задачи, необходимые для завершения проекта.

  • Это динамичный документ, который постоянно меняется и развивается в соответствии с текущими реалиями проекта.

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

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

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

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

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

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

Пользовательские истории

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

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

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

Чтобы узнать больше о пользовательских историях, изучите статьи Создание списка невыполненной работы и Раскадровка идей с использованием PowerPoint.

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

Оценка

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

Оценки очень важны по двум причинам.

  1. Они помогают ответить на вопрос: "Когда мы завершим работу?"

  2. Они помогают владельцу продукта определить приоритет каждого элемента.

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

Группа может использовать покер для планирования (Planning Poker), большую стену (Big Wall) и другие методы для оценки работы в баллах истории. Дополнительные сведения о методах оценки и краткий обзор баллов истории см. в статьях Оценка и Оптимизация и оценка невыполненной работы.

Когда группа оценила все истории, следующий шаг заключается в расстановке приоритетов.

Расстановка приоритетов

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

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

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

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

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

Динамичный список невыполненной работы продукта

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

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

  • добавление новых истории и расстановка приоритетов;

  • обращение к группе для оценки новых историй и повторной оценки старых;

  • анализ предстоящих пользовательских историй с группой для декомпозиции элементов при необходимости;

  • встреча с клиентами и заинтересованными лицами для анализа и добавления требований.

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

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

Груминг

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

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

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

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

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

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

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

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

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

См. также

Основные понятия

Отслеживание работ с помощью Visual Studio ALM и TFS

Отзывы и предложения заинтересованного лица запроса и процессов с помощью Team Web Access

Приступая к работе с установкой TFS на одном сервере

Работа с артефактами командного проекта, выбор шаблона процесса