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

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

• увеличение или сохранение доходов,

• сокращение или устранение расходов,

• улучшение уровня обслуживания,

• соблюдение нормативных и социальных обязательств,

• реализация маркетинговой стратегии и

• повышение квалификации персонала.

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

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

Описание

Баклог продукта, изначально пришедший из Scrum, используется во многих методологиях Agile и вводится в начале проекта. Баклог или журнал незавершенной работы – это постоянно меняющийся документ, который развивается во время выполнения проекта по мере накопления знаний о продукте и клиентах. Владелец продукта (Product Owner) отвечает за упорядочение элементов баклога на основе знаний и пользе бизнесу, важности фич или других соответствующих критериев. При управлении баклогом, элементы должны быть упорядочены так, чтобы наиболее важные элементы находились в верхней части списка и упорядочены по убыванию приоритета. В XP (eXtreme Programming) незавершенная работа по функциональности может управляться как журнал историй пользователя. Бизнес-аналитик может выступать в качестве владельца продукта или помогать ему.

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

Хотите узнать быстрый способ, как за пару минут проверить процесс разработки в вашем проекте?

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

В чем это проявляется? Вот основные моменты:

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

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

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

4. Есть десятки задач, "зависших" в особенном, специально (!) добавленном статусе, например, "Ожидает фидбека". Как правило, подобное ожидание может происходить месяцами, особенно если ждем что-то от заказчиков или архитекторов

Кстати, используя в качестве трекера Devprom, вы никогда не столкнетесь с первыми тремя проблемами, потому что:

• Баклог продукта (список задач и ошибок) по-умолчанию всегда отсортирован по приоритету, если задача действительно важная, она всегда будет на виду и вы непременно либо решите ее, либо смените приоритет на более низкий

• Задачи на отдельных разработчиков создаются только в рамках краткосрочных итераций (как правило, 1-2 недели), с четко определенными датами начала и окончания, поэтому одни и те же задачи просто не могут висеть на разработчике долгое время - ему придется либо отказаться от них, либо наконец выполнить :)

Попробуйте потратить несколько минут, взгляните на ваш трекер, нет ли в нем похожих проблем? Было бы очень интересно увидеть в комментариях, что у вас получилось!

Часто в процессе работы над проектом, особенно когда вы используете Scrum, требуется выгружать из инструмента списки пожеланий (историй пользователей) и задач, например: Отправить product backlog заказчику на согласование (не каждый бизнес-заказчик готов погружаться в ваш инструмент управления проектом). Напечатать баклог для быстрого ревью командой или заказчиком, с которым легко встретиться лично. Напечатать карточки пожеланий и задач для вывешивания на доску задач итерации. Напечатать и просто захватить с собой на совещание список работ команды. Сформировать release notes по завершенной версии для вставки в блог проекта.

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

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

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

Обычно в таком случае используют один общий баклог (Product Backlog), который координируется одним владельцем продукта (Product Owner).

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