учет трудозатрат по задачам в jira
Как автоматизировать процесс оценки задач в JIRA
Планирование во имя порядка
Управление IT проектами нельзя представить без планирования. Планирование синхронизирует работу разных проектных отделов (разработки софта, маркетинга, продаж и прочих). Наличие плана позволяет бизнесу четко видеть вектор развития продукта. Планирование немыслимо без оценки задач по времени их выполнения. Но выработать привычку дробить задачи на более мелкие и оценивать их — не просто. Порой этим грешат не только Junior-разработчики, но и более опытные специалисты. В данной статье я расскажу о том, как мы принудили наших разработчиков оценивать задачи с помощью хитрой конфигурации Atlassian Jira.
Истоки проблемы
Часто для быстрого старта нового проекта ПМы нашей компании используют дефолтные настройки JIRA для воркфлоу (workflow), полей (fields), экранов (screens) и т.д. Эти настройки ориентированы на самый широкий спектр ведения проектов, и это здорово! Но для организации более эффективной работы в данном инструменте придется немного посидеть с книжками и выставить узкие, специфичные настройки под конкретный проект.
На стадии планирования спринтов наши менеджеры просят разработчиков раздробить и оценить их задачи. Это помогает нам понять, как не перегрузить спринт и пообещать заказчику только то, что мы реально можем поставить в срок.
Но порой разработчики закапываются в ещё не оцененной задаче, и тем самым подводят всю команду. Причина в том, что человек не осознает полный объём (scope) работ, который ему необходимо выполнить.
Оценка задачи разработчиком (estimate) — это его персональное обязательство (commitment) на выполнение поставленной задачи в срок.
Менеджер и сам может контролировать добавление оценок, проверяя каждый тикет, но это не наш метод. Надо экономить время.
Как организовать ресурсное планирование в Jira для больших и маленьких компаний
Чтобы IT продукт вышел качественным, вам, разумеется, нужно контролировать процесс его создания. В этом помогают системы управления IT-задачами, значительно упрощающие жизнь как рядовых разработчиков и тестировщиков, так и «проверяющих».
Важно, чтобы систему контроля можно было настроить по всем важным для вас параметрам, и в этом плане отлично подходит Jira. Не зря же она фактически стала стандартом в сфере IT. В Jira пользователь может настроить всё под себя, а это дает возможность использовать самые разные методики ведения задач. Если при этом пользоваться другими продуктами компании Atlassian, то можно бесшовно расширить управление задачами до реализации CI/CD и ведения документации, это тоже облегчает жизнь.
Но нам ведь важно не только удобство. В определенный момент компании приходится контролировать реальную стоимость решений, и проблема управления ресурсами и бюджетами выходит на первый план.
Малым и средним компаниям вполне хватит стандартных инструментов Jira для управления ресурсами: контроль трудозатрат «из коробки», решения Tempo для гибкого планирования и контроля, а также Big Picture и бюджетирование. Но, когда дело касается Enterprise сегмента, всё резко усложняется. Появляются дополнительные разрезы отчетности, группы проектов, различные бюджеты. Давайте постараемся найти лучшие варианты реализации ресурсного планирования в Jira, исходя из опыта, полученного нами ранее в реальных проектах.
Для начала сформулируем бизнес-проблемы и вытекающие из них требования к решению.
Бизнес-проблемы
Требования
· Невозможность реализовать единую методику управления крупными проектами с широким технологическим стеком;
· Сложность долгосрочного планирования;
· Сложность обоснования дополнительных ставок и непрозрачная загрузка текущих;
· Сложность оценки бэклога продукта;
· Затрудненный поиск ИТ-специалистов с необходимыми навыками для решения конкретных задач внутри компании.
· Наличие справочника навыков;
· Контроль фактических трудозатрат;
· Возможность календарного планирования бэклога спринта или релиза;
· Возможность прогнозировать точность планирования;
· Оценка загрузки команд:
· В разрезе компетенций;
· В разрезе продуктов и бюджетов бизнеса.
Рассмотрим эти требования более детально.
Кто есть кто и что он умеет? Справочник навыков
Чтобы грамотно распределить ресурсы, надо понимать, какой сотрудник справится с задачей лучше всего. Для этого пригодится справочник навыков. Причем недостаточно знать, что сотрудник является разработчиком, нужно понимать, на чём он пишет, с какими фреймворками знаком. То есть в идеале справочник должен быть многоуровневым. Пригодится и возможность масштабирования.
Справочник есть в Advanced Roadmaps (formerly Portfolio), хотя для больших компаний решение не подойдет – рассчитано всего на 25 команд. Или, например, облачное решение Align, но оно позволяет управлять только Scrum командами.
Также справочник есть в Tempo Planner и многих других плагинах. Но там нет возможности сделать справочник многоуровневым, и масштабироваться они тоже не могут.
Контроль трудозатрат
На первый взгляд, весьма простая задача – оценка трудозатрат – доступна в Jira «из коробки». Но есть нюансы. Нам нужна (как минимум) возможность агрегации плановых и фактических трудозатрат разных команд. И нужно учитывать, что подходы к учету трудозатрат у команд могут различаться. Кто-то использует классические Jira worklog; кому-то удобнее отслеживать время нахождения в «рабочем» статусе; а кто-то предпочитает контролировать не время, а исполнение задач с помощью, к примеру, story point.
При этом информация по трудозатратам должна быть хорошо интегрирована с другим требованием – реализацией в системе календарного планирования.
Календарное планирование
Плагинов, позволяющих планировать сроки исполнения задач на календаре, весьма много: от Gantt Chart до Team Calendar. Последний, к слову, хорошо визуализирует задачи Jira, хотя и является плагином Confluence.
Для разных методик ведения проектов оптимальными могут оказаться разные подходы к планированию и реализации различных разрезов не только ролей, но и команд/проектов. Так что нам нужно такое решение, которое позволит использовать не только краткосрочное планирование на конкретных исполнителей, но и долгосрочное планирование сотрудников с определенными навыками.
Нужно также учитывать реальную производительность сотрудников с учетом плановых отпусков.
Вывод – нам нужен планировщик-конструктор, который позволит планировать как конкретных сотрудников в краткосрочной перспективе (релиз/спринт), так и загрузку команд на длинной дистанции (бэклог продукта).
Оценка загрузки команд
Для максимально точной оценки загрузки нужна гибкая отчетность по данным в системе ресурсного планирования. Важно, чтобы можно было:
агрегировать краткосрочные данные для представления загрузки в различных разрезах для тимлидов и менеджеров;
визуализировать оценку бэклога продукта для топ-менеджмента и представителей бизнеса,
визуализировать оценку потенциальной скорости развития продукта,
визуализировать обоснования решений о привлечении дополнительного бюджета при необходимости.
С этими задачами могут справиться построители отчетов или BI решения из стека компании. Например, можно использовать easyBI, если все необходимые данные будут вестись в Jira, нет необходимости в хранилище из разных систем, и логика системы не полностью переписана.
После детализации требований можно построить логическую модель системы:
А также вариант ее имплементации:
Попробуем обосновать этот вариант.
Каталог пользователей
Тут вариантов немного. Для вычисления согласующего лица в различных процессах может потребоваться информация о линейном руководителе сотрудника. При использовании LDAP для этих целей подойдет User Profile.
Справочник навыков
Основной объект Jira – issue (задача). Insight расширяет модель данных справочными объектами. Будет это CMDB, список клиентов CRM или иерархия организации – неважно. В итоге получаем встроенный механизм визуализации связей, отдельный механизм учета связанных задач и отдельный набор системных полей. Внедрять Insight исключительно ради справочника навыков я бы не стал, тем более что степень кастомизации карточки объекта Insight ниже, чем issue Jira. В целом оба варианта хороши.
Управление отпусками
Отпуска завязаны на отпускные выплаты и, как следствие – бухгалтерскую систему и ЗУП. Поэтому в Jira, как минимум, остается справочник отпусков, а как максимум – фронт заявки на отпуск. Отметим, что Jira не является мастер-системой отпусков, заявка на отпуск может делаться как типовой запрос проекта ServiceManagement или просто как задача Jira Work Management. Справочную информацию по отпускам можно получать из КХД, или же можно сделать прямую интеграцию с ЗУП.
Календарное планирование продукта
В рамках календарного планирования продукта происходит:
первичная оценка необходимого количества рабочих часов в разрезе навыков,
приоритизация бэклога продукта,
итоговое определение дедлайна.
Для фиксации оценки можно использовать плагин iDalko Table grid – он позволяет фиксировать необходимый набор компетенций в разрезе команд и навыков, при этом учитывая часы.
Приоритизация может быть сделана через сортировку требований на доске продукта по Rank (выше-раньше) или через вычисление какой-то частной формулы. В моей практике было и такое, что приоритет был f(ROI, влияние, ФИО автора) :-).
После приоритизации можно определить дедлайн (если он изначально не зафиксирован) и визуализовать сроки исполнения на диаграмме Гантта с использованием Structure.Gantt. В дальнейшем сроки могут корректироваться автоматически снизу вверх по факту планирования декомпозированных задач.
Планирование релиза
Выбор задач в релиз или спринт носит скорее методологический характер, как и нарезка детализованных задач. В работе нам более интересен вопрос детализации первичной оценки.
Во-первых, можно реализовать «вычерпывание» первичной оценки, когда при оценке конкретной задачи конкретным исполнителем учитывается первичная оценка и роль исполнителя. При этом выстраивается классическая цепочка: прогноз→план→факт. С точки зрения пользователя, это выглядит как обычный процесс эстимейта задачи. При этом мы можем не только сразу же визуализировать агрегированные затраты в разрезе команд и навыков в бизнес-задаче, но еще и зафиксировать данные для построения отчётности по точности прогнозирования. Переиспользование первичной оценки и немного Jira API c Groovy, никакой магии.
После оценки детализированных задач можно выстраивать календарные сроки задач в рамках релиза. Загрузка ресурсов подсвечивается, можно использовать авто корректировку ресурсов (с учетом связей Start-Start, End-Start и т.д.).
Ведение проектных задач
Тут нет ничего сложного. Нам нужен простой набор проектов с задачами, на которые декомпозируются бизнес-требования. Поля, процессы и типы задач в соответствии с потребностями команд. Кто-то живет по Scrum c User Story, кто-то хочет разделить задачи для разработки и задачи для аналитики. Методологически очень желательно обеспечить:
ведение бэклога продукта и релиза/спринта в Jira,
управление календарными сроками,
наличие практики оценки трудоемкости в часах,
управление справочниками компетенций,
интеграция с системой управления отпусками.
Отчетность
В начале статьи мы говорили о «дополнительных разрезах отчетности». Что же мы можем получить для наших топ-менеджеров и PO?
1)Долгосрочное прогнозирование загрузки команды по ролям в горизонте оцененного бэклога продукта с учетом отпусков. Можно, к примеру, заранее прогнозировать рост потребностей или вовремя подкидывать новые задачи команде.
2)Точность оценки прогнозирования загрузки команды и плановая загрузка команды в горизонте релиза.
3)Точность оценки прогноз/план/факт.
4)Прозрачный Time to Market для бизнеса с детализацией до конкретных задач разработчика при необходимости.
К чему мы в итоге пришли?
Серебряную пулю мы не нашли, хотя на самом деле и не особо искали – ее просто нет. Также мы не стремились описать архитектуры конкретных решений. В этой статье мы пытались показать, что решения на платформе Atlassin (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.
Синхронизируем время по задачам с Jira заказчика
Одним из наших приоритетных направлений является работа с серьезными проектами, состоящими из потока крупных задач.
Чтобы совершенно не утонуть в скоплении работ разного приоритета в серьезных проектах всегда используют системы управления задачами. Это нужно как для самого процесса разработки, так и для дальнейшего анализа проблем.
Рынок инструментов управления проектами и задачами предлагает обширный функционал и поддержку популярных методологий разработки. У каждой компании свой способ считать время сотрудников.
Обычно у заказчика и подрядчика разные системы и разный способ считать время. Каждый из них желает видеть потраченное время на выполнение задач у себя.
Как правило, над проектом работают от одного до пяти исполнителей (аналитиков, дизайнеров, верстальщиков, разработчиков, тестировщиков) одновременно, выполняющих по несколько задач в день. Это сотни человеко-часов. Можно, связать системы управления задачами заказчика и подрядчика посредством ручного переноса данных из одной в другую, но это очень долго и больно.
А если над проектом работает не один подрядчик? И каждый из них пользуется разными инструментами учета времени?
YouTrack и Jira
Подобную проблему решает интеграция системы заказчика с системой подрядчика. Про такую интеграцию подробно расскажем в статье на конкретном примере взаимодействия.
Особенности используемых систем
Для одного из наших проектов стояла задача разработать сервис, синхронизирующий потраченное время по задачам между нами и заказчиком.
У каждой траты времени есть автор, дата, потраченное время и комментарий. Комментарий к каждой такой записи состоит из описания проделанной работы, XML_ID (уникальный номер записи о трате времени в нашей внутренней системе «Потрачено») и версия этой записи для последующей оптимизации изменений.
Пример записей о трате времени в YouTrack
Со стороны заказчика используется система управления задачами и проектами Jira компании Atlassian. Аналогично с YouTrack создаются задачи, относящиеся к конкретному проекту, к которым относится потраченное время.
Вести учет времени в Jira можно с помощью стандартных средств, а также и с помощью приложений, расположенных в Atlassian Marketplace. Лидер среди приложений для учета времени — Tempo Timesheets. Умеет считать потраченное и оставшееся время с помощью внесения отдельных записей о трате времени к задаче.
Пример записей о трате времени в Tempo
При любой интеграции актуален вопрос наличия API. Желательно документированного. Хотя бы рабочего… У YouTrack и Tempo есть REST API для решения текущей задачи. API Jira не использовалось, т.к. учет и работа с потраченным временем организована с помощью Tempo.
Получить нужную нам информацию из двух систем мы можем. Но как теперь все это связать?
Возможные схемы реализации обмена данными о тратах времени
Для учета времени не нужно переносить данные из системы заказчика подрядчику. Записи о трате времени должны браться из YouTrack и передаваться в Jira через систему синхронизации.
Дальше стоит определиться с частотой актуализации данных. Если важен обмен в режиме реального времени, то сначала стоит проверить, поддерживает ли такую возможность сервис из которого эти данные берутся. Например, в Trello такое можно реализуется помощью вебхуков. Для текущей задачи моментальное обновление данных не сильно важно, поэтому время синхронизируется один раз в сутки ночью.
Связь между задачами в двух системах реализована на стороне YouTrack с помощью кастомного поля для проекта, где вручную проставлялся id задачи из Jira.
Информация о задаче
Во время синхронизации сначала выбираются доступные к синхронизации задачи из Youtrack, а потом для каждой из них записи о тратах времени за последний месяц. Для полученных задач ищутся аналоги в Jira. Затем записи о трате времени для каждой из задач сопоставляются с теми, которые есть в Jira.
Данные поддерживаются в актуальном состоянии за счет использования версионирования записей с помощью Потрачено. Если данные расходятся, то сравниваются версии записей и добавляются новые, либо удаляются лишние из Jira.
Диаграмма взаимодействия нашего сервера, YouTrack и Jira
Как это работает сейчас?
Обмен выполняется каждую ночь по расписанию. Также была разработана отдельная страница с ограниченным доступом, на которой можно запустить процесс обмена и посмотреть отчет о его результатах.
Интерфейс страницы с результатами синхронизации
В процессе каждого обмена логируются все операции изменения данных в системе заказчика и возникающие ошибки. Логи хранятся структурировано с привязкой к дате и времени, что дает легко отследить историю изменений.
В отдельные настройки вынесены проекты и задачи, доступные для обмена и те, которые исключены из него.
В результате время синхронизируется для двух наших проектов, обрабатывая потраченное время для сотни задач каждый день. Заказчик получает информацию по потраченном времени в автоматическом режиме, а менеджер проекта избавлен от ручного переноса этой информации из одной системы в другую.
Подобная система поможет облегчить и работу с подрядчиками над крупными проектами и процесс анализа потраченного времени для заказчика.
Разработчики будут продолжать вести учет времени в своей системе, а заказчик видеть результаты в другой, что поможет сосредоточиться на проекте и эффективнее решать задачи.
Мы как опытный веб-интегратор поможет связать используемые вами инструменты управления проектами в единое целое. Если есть вопросы либо возникнут проблемы при настройке, то задавайте вопросы в комментариях.
У нас большой опыт работы с нагруженными, масштабными, проблемными и просто растянутыми по времени проектами, и мы готовы поделиться им с вами!
Регистрация времени работы над задачей
Об отслеживании времени работы над задачами
Примечание. Любой пользователь JIRA, имеющий разрешение «Обзор проекта», может просматривать информацию об отслеживании времени работы над задачами.
Если задача (или ее подзадачи) была зарегистрирована в рабочем журнале и / или задано исходное оценочное значение времени (Original Estimate), то будут отображены три цветные полосы, представляющие следующие интервалы времени:
Если у вашей задачи есть одна или несколько подзадач, то:
Для того, чтобы зарегистрировать работу над задачей, выполните следующие шаги:
1. Запишите время, которое вы потратили, в неделях / днях / часах / минутах (вы можете использовать дроби, если хотите, например, «5.5h»).
Это время будет добавлено к общей сумме времени, потраченной (Time Spent) на задачу.
2. Введите описание выполненной работы.
3. Отрегулируйте значение оставшейся оценки (Remaining Estimate) (т.е. оставшееся время, которое, по вашему мнению, потребуется, чтобы решить задачу).
Зарегистрированная работа над задачей, отображена в диалоговом окне «Рабочий журнал» (Log Work), как показано ниже:
Кроме того, как только работа над задачей была зарегистрирована, становятся доступны различные отчеты, основанные на информации отслеживания времени.
Задание временных оценок
Перед записью работы над задачей вы можете указать исходную оценку (Original Estimate) для задачи (т. е. общее количество времени, которое, по вашему мнению, потребуется для решения задачи).
Если работа сначала регистрируется в связи с задачей, то «Потраченное время» (Time Spent) вычитается из «Исходной оценки (Original Estimate)», и полученное значение автоматически отображается в оставшейся оценке (Remaining Estimate). Когда последующая работа регистрируется, любое потраченное время (Time Spent) вычитается из оставшейся оценки (Remaining Estimate).
Однако на протяжении всего жизненного цикла задачи вы можете вручную изменить значения исходной оценки (Original Estimate) и / или оставшейся оценки (Remaining Estimate). Для того, чтобы сделать это:
1. Перейдите к существующей задаче, просмотрите ее и нажмите кнопку «Изменить»(Edit) в верхней части экрана, чтобы отредактировать эту задачу.
Создайте новую задачу, нажав кнопку «Создать задачу» (Create Issue) в верхней части экрана и заполните необходимые поля.
2. Отредактируйте следующие поля «Отслеживания времени» (Time Tracking):
Если функция отслеживания времени JIRA находится в режиме Legacy (наследование), и работа над задачей еще не была зарегистрирована, вы увидите поле «Исходная оценка» (Original Estimate). Однако, как только работа была зарегистрирована, вы увидите только поле «Оставшаяся оценка» (Remaining Estimate).
Если оба этих поля доступны и являются обязательными (обозначены красными звездочками), вы можете просто ввести одно значение и оставить другое значение пустым. Когда вы отправите форму, поле со значением будет скопировано в поле, которое осталось пустым.
4. Нажмите кнопку «Обновить» (Update) в нижней части экрана.
Если ваш администратор JIRA добавил возможность указывать / изменять оценки времени на других экранах перехода рабочего процесса в рабочем процессе JIRA по умолчанию (default workflow), вы также сможете указать / изменить оценки времени во время этих переходов рабочего процесса.
Кроме того, если ваш администратор JIRA добавил эту возможность на экраны JIRA, используемые другими типами задач, вы также можете указать оценки времени при создании или редактировании этих типов задач.
Ведение рабочего журнала
Работа с журналом при просмотре задачи
Для того, чтобы вести рабочий журнал при просмотре задачи, выполните следующие шаги :
1. Перейдите к задаче и просмотрите ее детали.
2. Выберите «Дополнительно» (More)> «Рабочий журнал» (Log Work).
3. Откроется диалоговое окно «Рабочий журнал» (Log Work).
Диалоговое окно «Рабочий журнал»
4. В поле «Потраченное время» (Time Spent) введите количество времени для регистрации. Используйте «w», «d», «h» и «m», чтобы указать недели, дни, часы или минуты. Например, чтобы записать два часа работы, введите «2h».
Если вы вводите число без указания единицы времени (например, если вы наберете «2» вместо «2h»), будет применяться единица времени по умолчанию, указанная вашим администратором JIRA.
5. В поле «Дата начала» (Date Started) нажмите значок календаря, чтобы выбрать дату / время, когда вы начали работать. Отобразится всплывающее окно календаря, где вы можете:
Если вы нажмете и удерживаете один из этих значков прокрутки, появится раскрывающееся меню, позволяющее выбрать месяц или год из списка предоставленных опций.
6. Поле «Оставшаяся оценка» (Remaining Estimate) влияет на значение остаточной оценки задачи. Выберите один из следующих вариантов:
Эта опция отображается только в том случае, если не были указаны оценки времени.
Этот параметр отображается, если задана временная оценка.
7. В поле «Описание работы» (Work Description) введите описание или комментарий о выполненной работе.
8. Нажмите значок навесного замка для того, чтобы можно было настроить этот рабочий журнал на просмотр только членами определенной роли или группы проекта. Либо вы можете разрешить просматривать его всем пользователям.
Чтобы пользователи могли просматривать рабочий журнал, они должны иметь разрешение «Обзор проекта» (Browse Project) для просмотра задачи и быть членом роли или группы проекта, выбранной на этом этапе.
9. Нажмите кнопку «Регистрация работы» (Log) в нижней части диалогового окна, чтобы отправить форму и закрыть это окно.
Работа с журналом при решении или закрытии задачи
В дополнение к работе с журналом при просмотре задачи вы также можете регистрировать работу при решении или закрытии задачи.
Для того, чтобы вести рабочий журнал при решении или закрытии задачи, выполните следующие шаги:
1. Перейдите к задаче и просмотрите ее детали.
2. Выберите «Рабочий процесс»> «Решить задачу или рабочий процесс»> «Закрыть задачу »(Workflow > Resolve Issue or Workflow > Close Issue).
Если этого не происходит, и вы хотите, чтобы комментарии были скопированы в описания рабочих процессов, попросите администратора JIRA включить параметр «Копировать комментарии JIRA» в установке «Описание рабочих потоков».
Если эта установка заблокирована:
4. Нажмите кнопку «Решить» (Resolve) (или кнопку с соответствующим названием для перехода или действия рабочего процесса), чтобы вернуться к задаче, и убедитесь, что:
Для редактирования записи в рабочем журнале выполните следующие шаги:
1. Перейдите к задаче и просмотрите ее детали.
2. Найдите раздел «Активность» (Activity) и выберите вкладку «Рабочий журнал» (Work Log).
3. Найдите запись в рабочем журнале, которую вы хотите отредактировать.
4. Нажмите значок «Редактировать»(Edit) (карандаш), расположенный справа от записи в рабочем журнале.
5. Отобразится экран «Редактировать рабочий журнал» (Edit Work Log). Отредактируйте поля окна «Рабочий журнал», как описано выше в разделе «Работа с журналом при просмотре задачи».
6. Нажмите «Журнал» (Log), чтобы вернуться к задаче, и убедитесь в следующем:
Для удаления записи в рабочем журнале выполните следующие шаги:
1. Перейдите к задаче и просмотрите ее детали.
2. Найдите раздел «Активность» (Activity) и выберите вкладку «Рабочий журнал» (Work Log).
3. Найдите запись в рабочем журнале, которую вы хотите удалить.
4. Нажмите значок «Удалить» (Delete), расположенный справа от записи в рабочем журнале.
5. Отобразится экран «Удалить рабочий журнал»(Delete Worklog). Поле «Настройка оценки» (Adjust Estimate) влияет на значение «Оставшаяся оценка» (Remaining Estimate) задачи. Выберите один из следующих вариантов:
6. Нажмите «Удалить» (Delete), чтобы подтвердить удаление и вернуться к задаче. Убедитесь что:
Индивидуальные установки JIRA
Ведение журнала и / или определение временных оценок на одном экране JIRA
Как описано выше, вы можете регистрировать работу при просмотре, решении или закрытии задачи или указывать оценки времени при создании или редактировании задачи.
Однако, JIRA может быть настроена для ведения рабочего журнала и определения временных оценок на одном и том же экране JIRA при выполнении любой операции JIRA, например, при редактировании или создании задачи или при переходе задачи в другой статус. Для этого администратор JIRA должен добавить поля «Рабочий журнал» (Log Work) и «Отслеживание времени» (Time Tracking) на соответствующий экран, используемый этой операцией.
Для того, чтобы зарегистрировать работу и / или указать оценки времени на одном экране JIRA, выполните следующие шаги:
1. Перейдите к задаче и просмотрите ее детали.
3. Если работа по ведению журнала является необязательной (поскольку администратор JIRA настроил поля «Рабочий журнал» как необязательные), вы можете выбрать, следует ли регистрировать работу в журнале во время вашей операции JIRA, используя флажок «Рабочий журнал» (Log Work).
Для получения дополнительной информации о том, как изменить эти поля, см. Раздел «Работа с журналом при просмотре задачи».
Если вы не создаете задачу или подзадачу или явно не используете действие «Работа с журналом» (см. выше), для ввода описания регистрируемой работы будет доступно только поле «Комментарий» (Comment), а не поле «Описание работы» (Work Description).
По умолчанию JIRA должна автоматически копировать содержимое вашего комментария (Comment) в описание рабочего процесса (Workflow Description). При этом рабочий журнал будет видимым для членов роли или группы проекта, выбранных в раскрывающемся списке значка висячего замка.
Если этого не происходит, и вы хотите, чтобы комментарии были скопированы в описания рабочих процессов, попросите администратора JIRA включить параметр «Копировать комментарии JIRA» в «Описания рабочих процессов».
Если этот параметр отключен: