О моделях управления проектами в багтрекинговых системах

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

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

Разработать «правила игры» — это значит создать определенный фреймворк для управления задачами, багами, требованиями (или эпиками, фичами и пользовательскими историями). В рамках данного фреймворка или модели управления необходимо определить:

— типы запросов, которыми мы будем управлять;

— типы связей, которые мы будем использовать для связывания запросов;

— список атрибутов для каждого типа запросов;

— жизненные циклы с переходами состояний.

Но это только часть задачи, поскольку данные составляющие описывают только статическую модель управления. В зависимости от используемой методологии необходимо также ответить на вопросы «кто?» и «когда?». Например, «кто и когда переводит задачу в состояние In progress?», «кто связывает пользовательскую историю с эпиком?», «кто может утверждать и назначать багу на версию?», «когда отводится tag?». Также, чтобы модель была целостной и устойчивой нужно определить ряд дополнительных правил. Например,

— допускается не более 2 задач в состоянии In progress на одном исполнителе;

— версия и приоритет задачи должны совпадать с версией и приоритетом подзадачи;

— автор оценки задачи должен совпадать с ее исполнителем;

— ворклоги необходимо отмечать день в день (максимум с сегодня на вчера);

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

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

Таким образом? мы определяем систему координат, с помощью которой любой участник понимает «что», «когда» и «зачем» делать.

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

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

Приведу несколько примеров:

  1. Менеджеру необходимо понять «кто какими задачами занимается в данный момент?». Для этого необязательно собирать совещание или подходить персонально к каждому. Кстати, совещания являются очень дорогостоящей активностью. Не зря придумывают всякие способы сокращения длительности совещаний. Достаточно в модели предусмотреть активные статусы типа In progress или In testing. Аналогично, чтобы понять прогресс выполнения задачи или в целом версии не нужны совещания, можно ввести практику оценивания задач, корректировки оценки в JIRA и соевременного внесения ворклогов. Совещания безусловно нужны, но на мой взгляд они эффективны, когда необходимо планирование, анализ рисков, поиск решений и т.п.
  2. Менеджер может спросить у процесса тестирования в каких модулях, компонентах или областях возникает больше всего проблем для оценки проблемных участков. В команде включающей одного тестировщика будет достаточно и «поговорить», но в большой команде собрать такую информацию не получится быстро. Нужно просмотреть все баги и разнести их по категориям. Но ведь это можно сразу предусмотреть. Т.е. заранее продумать список возможных категорий и выбирать одну из них при создании бага. После этого такую статистику можно получить очень быстро и даже мониторить динамику изменения.
  3. Менеджеру нужно понять насколько проект уже отличается от первоначальных договоренностей с заказчиком. Или фактически понять какие трудозатраты потрачены на реализацию требований, которых не было в ТЗ. Кстати, на этом стыке как правило и возникают конфликты с заказчиками. Аналитикам это будет сделать не просто, если при создании требований сразу не указывался соответствующий признак или не велась матрица трассирования требований. В итоге нужно просматривать все требования и сравнивать с ТЗ.
  4. Техническому писателю не придется среди сотни задач, которые вошли в версию, анализировать те, которые повлияли на изменение UI, если разработчики при закрытии задачи будут проставлять специальный признак, сигнализирующий про изменение UI.

Можно привести множество других примеров.

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

Также нельзя забывать, что управление IT-проектами — это не только управление процессами. В первую очередь — это people management (ведь 90% времени менеджера состоит из коммуникации с командой). Использование какой-либо модели – это не панацея. Какой бы эффективной модель ни была — ее использование не является гарантией успешного завершения проекта.