Беклоги проекта или где что хранить

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

Беклог продукта

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

Группировка

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

1. Юзабилити. Иногда имеет смысл не делать каждый отдельный запрос по улучшению юзабилити продукта, а накопить некоторое количество и заняться всеми сразу. Более того, большое количество улучшений по юзабилити в соответствующей категории вашего беклога говорит о том, что, скорее всего, вашему проекту требуется некоторая переработка в плане удобства использования.
2. Новые блоки функциональности. Если у вас в беклоге имеется несколько новых глобальных фич (например, социализация всего сервиса), есть смысл выделить их всех в отдельную категорию. Такие крупные фичи отличаются от более конкретных мелких заданий. С увеличением размера фичи растет время на ее реализацию, возникает необходимость глубокого анализа, обширных исследований и более-менее скрупулезного планирования. Хранение подобных новых фич в одном месте позволяет легче расставлять приоритеты при планировании новой фазы проекта, заранее организовывать создание набросков дизайна, технические и бизнес исследования.
3. Маркетинг. В этой категории стоит хранить те задания и новые фичи, которые так или иначе связаны с маркетингом. В частности, сюда можно отнести поддержку распродаж или специальных предложений, создание тематического блога в рамках проекта, внедрение поддержки партнерских программ.

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

Эстимирование

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

Теги

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

1. Needs analysis - заданию требуется отдельное исследование на бизнес- или маркетинг- тематику
2. Needs technical research - заданию требуется исследование технической стороны реализации задания
3. Needs specification - заданию требуется проработка деталей, которые должны быть собраны в функциональной спецификации
4. Needs prototype - заданию необходим прототип для UX тестирования или просто - посмотреть.
5. Needs design - задание жаждет внимания дизайнера и очень хочет из простых скетчей стать чем-то красивым и стильным

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

Приоритеты

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

1. High (лучше всего сделать)
2. Medium (было бы хорошо сделать)
3. Low (подумайте, стоит ли это делать)

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

Технический беклог

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

Назначение

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

Наполнение технического беклога

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

1. Четко определите проблему
2. Определите плюсы и минусы от решения данной проблемы
3. При необходимости определите некие гайдлайны, которых следует придерживаться всей команде для устранения проблемы в будущем
4. Определите необходимость проведения дополнительных технических исследований
5. Определите модули проекта, которые будут затронуты при решении проблемы - по сути, шпаргалка для QA отдела

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

Отложенные проблемы и баги

Часто отведенного на фазу времени не хватает для решения всех существующих проблем и поэтому клиенту приходится поставлять продукт с некоторым количеством известных проблем (known issues). Большинство известных проблем обычно не очень серьезны, некоторые очень сложно воспроизвести, но их объединяет одно: закрыть и забыть их вам не позволит профессиональная совесть :). Перекидывание таких багов с одной фазы проекта на другую ничего хорошего в себе не несет, гораздо лучше вынести эти баги и проблемы в отдельный беклог. При планировании следующей фазы проекта можно просмотреть этот беклог и определить те проблемы, которые необходимо решать прямо здесь и сейчас. Как с любыми кладовками, следует иногда проверять: не испортились ли продукты. Периодический осмотр беклога поможет выявить и закрыть баги, которые были в старой версии модуля ХХХ, при том что новой версии этого же модуля уже полгода в обед.

Исследования и анализ

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

Итого

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

Место солидарности беларусского ИТ-комьюнити

Далучайся!