Многие проблемы с экземпляром Jira могут быть связаны с техническим долгом, поскольку конфигурация инструмента растет естественным образом. Вот несколько способов предотвратить это.
Гиперконкретное именование
Jira — это платформа, которую можно настраивать бесконечно. Поля, статусы, решения, типы задач и т. д. могут быть добавлены и иметь собственные имена. Это одно из величайших преимуществ инструментов, но при неправильном управлении оно может стать ловушкой.
Настраиваемые поля
Если возникает вариант использования, который оправдывает добавление настраиваемого поля, важно дать полю общее имя, которое можно использовать для будущих вариантов использования. Со временем Jira будет использоваться для замены все большего количества процессов по мере распространения инструмента.
Это обычное дело, когда речь идет о полях даты. Дата выполнения — это системное поле, но некоторым командам нужны дополнительные поля даты, которые могут иметь такое же значение. При добавлении дополнительных полей даты (или любого типа поля в этом отношении) значение каждого поля должно быть ясным и задокументированным. Например. Дата выполнения, Конечная дата и Дата окончания могут ввести конечного пользователя в заблуждение, если не будет ясно, что каждое поле используется для разных целей. В этом помогут описания полей, отображаемые под полями, но количество подобных полей должно быть сведено к минимуму.
Общепринято иметь запланированные и фактические даты, чтобы отслеживать прогресс в соответствии с планом проекта. В этом случае требуются два поля даты, одно из которых было запланировано в начале проекта, и одно для отслеживания фактической даты, которая будет периодически обновляться.
Резолюции
Абсолютно безумно иметь решения для Готово, Завершено, Завершено, Закрыто, Решено. >, и сколько может быть синонимов для чего-то заканчивающегося. Это кажется здравым смыслом, но я видел варианты этого в ряде компаний, в которых я работал. В этих случаях для запроса всей работы, которая «выполнена», запрос должен включать все перестановки конечных состояний и разрешений «выполнено».
Выберите одно решение, которое означает, что работа была выполнена для решения проблемы. В большинстве случаев необходимо различать выполненную работу или нет. Для этого вам понадобится статус Выполнено и статус Отменено или Не будет выполнено. В управлении дефектами обычно необходимо различать ошибки, которые исправлены или нет, и по какой причине, например, невозможно воспроизвести.
Во всех случаях не должно быть решений с пометкой «Решено» или «Нерешено». Resolution = Resolved является избыточным. Почему это было решено? Потому что работа действительно была сделана или было принято решение не продолжать работу?
Пользователи должны быть обучены поиску проблем с разрешением или без него. Решение = Нерешено или Решение ПУСТО означает, что проблема не имеет решения. Решение не ПУСТОозначает, что проблема имеет решение независимо от того, какое оно. Это уловка, чтобы увидеть все, над чем больше не нужно работать. Многие пользователи не знают этого простого запроса и, если их обучить, смогут решить множество вопросов о том, что такое резолюции и почему они важны.
Статусы
Как и в случае с Резолюциями, не должно быть нескольких статусов, означающих одно и то же. Терминальные состояния встречаются чаще всего. Например. Готово, Закрыто, Завершено.
Это должно относиться и к входящим запросам. Я буду избегать использования Открыть, так как любая проблема, которая не закрыта, является Открытой, поэтому смысл, как правило, теряется.
Отсутствие шаблонных проектов
Каждый раз, когда создается новый проект, схемы создаются для этого проекта. Если 50 проектов создаются с использованием собственного метода создания проектов, для каждой конфигурации будет 50 конкретных схем.
Создайте шаблон проекта, который будет использоваться для создания каждого нового проекта с помощью функции создания проекта с общей конфигурацией. Даже если проект будет изменен, схемы можно копировать и модифицировать, что сэкономит много времени.
Если есть похожие группы команд, которые будут следовать аналогичной конфигурации проекта, все эти проекты должны использовать общие схемы. Это сократит количество конфигурационных схем, которыми нужно управлять, до доли суммы, если бы все они имели индивидуальные схемы.
Что делать, если проект хочет выделиться в свою собственную конфигурацию? Иногда это оправдывает экономическое обоснование, но для принятия такого решения его необходимо проанализировать, и рентабельность инвестиций должна быть положительной. Учитывайте команду, управляющую Jira, и их способность внедрять изменения. Для каждой ветви конфигурации или пользовательского проекта ими нужно будет управлять отдельно.
Надлежащее управление
Управление необходимо для предотвращения органического роста, который необходимо будет ликвидировать в будущем. Усилия по очистке этого со временем усугубляются. Входящие запросы на изменения следует анализировать, чтобы убедиться, что они не конфликтуют с существующими темами.
Заключение
Для поддержания экземпляра Jira важно заранее контролировать технический долг и понимать, что будет способствовать работе по очистке, необходимой в будущем. Это повысит качество инструмента и удобство работы пользователей, а также сократит количество человеко-часов, необходимых для выполнения миграций и других усилий по устранению задолженности.
