Прозрачность — наше всё, или Новые отчеты Jira в помощь менеджеру проекта



    Привет, Мегамозг!

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

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

    И вы с коллегами (а может, даже и не вы, а кто-то до вас, как это было в моем случае) опираясь на богатый опыт, набрасываете план. План выглядит чудесно, и по нему все фичи ровно в срок, и burn rate в пределах клиентских ожиданий. Одним словом, не проект, а сказка, но проходит kick-off — и сказка начинает плавно превращаться в жизнь.

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

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



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

    Стоило мне отчаяться, как на выручку пришли коллеги, подсказавшие, что в Jira Agile появились замечательные отчеты — Release Burndown и Epic Burndown. Они позволяют не только оценить текущую ситуацию в разрезе релиза и эпиков, но и после трех спринтов прогнозировать количество оставшихся итераций на основе средней производительности. Выглядят они замечательно, но есть нюанс: JIRA должна быть в полном порядке, а значит, следует выполнять правила:

    • Все issues должны быть привязаны к Epic и версиям (fix version).
    • Отчет не может оперировать эстимейтами саб-тасок, значит, если вы бьете юзер стори на саб-таски, надо проставлять и эстимейты для каждой, и общий суммарный эстимейт для стори. При этом снимать галочку include subtasks в Time tracking-секции настроек тикета и не забывать при актуализации эстимейта саб-тасок актуализировать эстимейт для стори.
    • Во время завершения спринта переводить все реализованные и проверенные QA тикеты в статус closed. Если что-то зависнет в resolved, время, потраченное на эти тикеты не спишется в отчете текущего спринта и, соответственно, испортит статистику.
    • И, конечно, ежедневно внимательно записывать затраченное время и актуализировать эстимейты. Чтобы картинка была прозрачной, рекомендую установить плагин Tempo Timesheets (спасибо Игорю Масленникову за наводку). Так вы всегда наглядно сможете понять, кто забыл залогать время, или кто главный стахановец в команде :)




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



    Enjoy your projects!
    DataArt
    Технологический консалтинг и разработка ПО

    Похожие публикации

    Комментарии 1

      0
      Лично меня всегда коробят статьи про отчетики ситуации, когда разработчики ПО рассказывают как пользоваться дефолтными отчетами. Это с учетом того, что до этого тратился день на составление подобного отчета. Сразу появляется вопрос: почему еще на том этапе не был создан пользовательский отчет?)
      P.S. Не администрировал Jira, видел только пользовательский интерфейс, но специально погуглил и узнал, что она может работать с MySQL, что уже показывает возможность создания отчетов даже не в самой Jira'e.

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

      Самое читаемое