Как купить Jira и не потратить деньги зря. Эффективная настройка Atlassian

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

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

Необходимые рекомендации

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

• сокращение расходов на управление и поддержание;
• стандартизация проектных процессов;
• демонстрация всего того, что именно происходит с проектом.

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

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

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

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

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

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

Что используется в Jira для управления бэклогом

В данном случае для облегчения понимания процесса работы и его нюансов, следует привести конкретные примеры.

1. Доска (board). Используется чтобы отобразить issues в конкретном виде. В распоряжении администратора имеются две доски – Scrum и Kanban. Описываемый концепт может работать для варианта Scrum, а потому для реализации проекта необходимо выбрать данную доску, предлагающую удобное предоставление информации.
2. Версии (versions). Предоставление возможность делать временные отметки в проекте. Все требования клиента, которые возникают в ходе взаимодействия, должны фиксироваться, чтобы в дальнейшем не затеряться, а быть учтенными. Используя данный вариант, можно сохранить нужные отметки, не включая их в текущий релиз.
3. Эпик (epic). Значительный объем работ должен быть разделен на небольшие части. Эпик можно создать, к примеру, если проект подразумевает более трех дней активной разработки. Но на каждый отдельный случай эпик создавать не следует – достаточно просто запутаться в хаотичном множестве. Нужно продумать оптимальное количество, просмотрев весь функционал и разделив его на логические блоки. Так легче определить, что именно «достойно» носить «гордое имя» эпик.
4. Теги (labels). Всем известно, что это ключевые слова, по которым легко найти необходимую информацию. И здесь опять же можно столкнуться с необоснованным увеличением числа тегов – это может только запутать сложившуюся ситуацию. До рабочей группы необходимо донести, какие теги уже были созданы и объяснить, что беспорядочное их создание – это верный путь к хаосу.
5. Компоненты (components). Под данным понятием подразумеваются все подразделы. Они могут применяться для разделения его на более мелкие части – такая дробность существенно упрощает работу. Возможно использование компонентов для модулей в приложении – внутри же удобнее применять эпики. В качестве модуля может выступать процесс начисления бонусов, в также ядро, помогающее формировать бизнес-процессы.
6. Фильтр (issues and filters). Его использование позволит упросить поиск информации и ее анализ. Рекомендуется использование быстрых фильтров, которые располагаются сверху доски.
7. Issue worklow. Использование данного инструмента дает возможность настройки статусов (последовательность и варианты изменения) для тех или иных целей. В решении присутствуют стандартные варианты решения тех или иных проблем – для конкретных задач вполне можно подобрать оптимальный, не затратив много времени. Уже после этого необходимо согласовать данное решение с рабочей группой и представителем заказчика.

Возможны следующие варианты:

• для пользовательской истории;

• для решения текущих задач.

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

1. Пользовательская история (story). Это отдельный подраздел, который необходимо создать на проекте, чтобы никто не запутался с терминологией. Его создание обусловлено тем, что часто рабочая команда проекта пополняется людьми со стороны. Вводить их в курс дела и знакомить с терминологией – занятие неоправданно утомительное. «Сторонним» лицам будет легче привыкнуть к терминологии и предлагаемым условиям, ознакомившись с ними самостоятельно. Это означает, что существенно сэкономится время и силы, снизится количество допускаемых ошибок.
2. Задача или подзадача (task/sub task). Применяется для четкого разделения пользовательских историй. Детализация всех поставленных задач – это вообще предмет постоянных споров и ссор в коллективе. У каждого присутствует собственный подход – также как и при создании пользовательской истории. Но закономерность тут одна – чем больше опыта у разработчика, тем больше деталей появится у описываемой задачи. Прежде всего это полезно ему самому - через какой-то период будет легче понять, что нужно делать в том или ином случае.

10. Баг (bug). Используется для контроля проблем в ходе работы. Время его «жизни» и степень критичности, а также особенности управления заслуживают еще одной статьи.

Структурные особенности Jira для управления бэклогом.

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

Преимуществами работы со story прямо на доске являются:

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

Оптимальным набором используемых инструментов становятся:

• Ready for Devtlopment;
• Current Sprint №N;
• Ready for Development;
• бэклог;
• BA in Progress.

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

Как это выглядит на самом деле

Многим покажется, что все так просто и удобно лишь в бумажном варианте – на деле с внедрением такого подхода возникнет масса сложностей. Так ли это?

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

Для чего?

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

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

Если вы заинтересованы в покупке, развёртывании, настройке или доработке Jira ли других продуктов советуем обратиться к платинум партнеру Atlassian Софтлист с сертифицированными специалистами, а используя промокод «Rus-Linux» вы получите дополнительную скидку.

---

---