Jira - функциональность

Привет, сегодня поговорим про jira, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое jira , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

• Основная функциональность
• Workflows, statuses, resolutions
• Плагины
• Роли и проекты
• Стандартные типы Issue
• Agile инструменты в Jira
• Роль и задачи QA в Jira
• Работа с фильтрами
• Работа с Personal Dashboard
• Трегинг времени
• Интегрированные репорты

Jira — коммерческая система отслеживания ошибок, предназначена для организации взаимодействия с пользователями, хотя в некоторых случаях используется и для управления проектами. Разработана компанией Atlassian, является одним из двух ее основных продуктов (наряду с вики-системой Confluence). Имеет веб-интерфейс.

Название системы получено путем усечения слова «Gojira» — японского имени монстра Годзилла, что, в свою очередь, является отсылкой к названию конкурирующего продукта — Bugzilla ; создавалась в качестве замены Bugzilla и во многом повторяет ее архитектуру. Система позволяет работать с несколькими проектами. Для каждого из проектов создает и ведет схемы безопасности и схемы оповещения.

Первый выпуск — в 2002 году. Изначально применялась в процессах разработки программного обеспечения, впоследствии нашла применение в качестве инструмента управления проблемами, задачами, проектами в различных отраслях. Процесс универсализации ускорился после запуска Atlassian Marketplace в 2012 году, который позволил сторонним разработчикам предлагать плагины для Jira BigPicture, Portfolio for Jira, Structure и Tempo Planner — основные плагины для управления проектами для Jira. . До версии 3.13.5 (включительно) различались редакции Enterprise, Professional и Standard, после — осталась только редакция Enterprise (для крупных организаций).

Функционанльность Jira

Agile Scrum в команде

Ретроспектива

Собственно, тут ничего нового нет и не придумано. Раз в две недели у нас есть день на то, чтобы сделать ретроспективу, на которой мы все по очереди рассказываем о том, что сделано, какие возникли проблемы по ходу разработки и что порадовало, о достижениях прошедшей итерации. Тут же попутно выписываются проблемы и задачи на планирование, но внимание на них не заостряется, они будут обсуждаться позже. Мы пока что не устраиваем больших демонстраций с артом и прочим (заказчик обычно не присутствует, так что смысла особого на текущем этапе нет). Для чего нужна ретроспектива: чтобы все были в курсе о том, что сделано в проекте по факту, не по задачам, закрытым в Джире, могли задать вопросы, уточнить те или иные моменты. Вербально можно передать гораздо больше и оперативнее, чем при помощи трекера. Таким образом, все видят прогресс (если он есть). Если же возникнут проблемы, сложности, то они тоже будут выявлены и о них будет знать вся команда, иметь в виду и может быть коллективно будет предложено наилучшее решение. После ретроспективы, которая занимает от часа до двух, перерыв 10-15 минут. Затем начинается планирование.

Планирование

Основной инструмент на планировании — бэклог, составленный ранее. Если кто-то не знает, то в бэклог включаются все основные задачи верхнего уровня. В идеале, он составляется сперва заказчиком, когда он описывает что хочет видеть в проекте. Далее он детализируется продюсером или другим ответственным человеком, или командой на планировании. Об этом говорит сайт https://intellect.icu . У нас он достаточно детализированный, на текущий момент в нем 95 задач, большая часть из которых высокоуровневые фичи. Высокоуровневые фичи — это те, которые потребуется еще раскрывать, делить на подзадачи (которых может быть сотни), каждую из них описывать и так далее. То есть эти 95 задач могут превратиться и в 950, и в 9500. Например, на текущий момент со времени написания статьи, количество фич у нас выросло примерно до тысячи. Фичи добавляются в бэклог и по мере разработки или обсуждений (так же, как и баги).

На планировании берется фича и оценивается: кто лучше ее сделает; кто в ней задействован и сколько времени займет ее реализация. Мы оцениваем время не в story points, а пока что в идеальных часах с последующим переходом на поинты (попугаи), но по некоторым внутренним причинам сейчас для нас лучше часы. Если время на выполнение задачи превышает 16 часов (два дня), то задача разбивается на подзадачи. Это позволяет лучше понять, что нужно сделать в рамках этой задачи, на что потребуется время и более точно оценить задачу, не заложив на нее лишнего времени и не пролетев мимо сроков.

На одного человека мы набираем от 70 до 80 идеальных часов — времени, которое ему понадобится, если он верно оценил задачу и его никто не будет отвлекать. Количество часов зависит от предыдущих итераций, от того, как каждый закончил свою итерацию. Например, если человек закрыл свои задачи раньше срока, значит он недооценил свои силы; если он что-то не успел. значит он переоценивает свои силы (или недооценивает сложность задач). Главное, не использовать скорость (velocity) как показатель продуктивности: это порочный путь, который из инструмента повышения точности при планировании превращается в кнут и хоронит саму суть и смысл аджайла. Тут можно дискутировать, что люди будут стараться не закрывать свои задачи вовремя, по мере исполнения. Да, такое может быть; но у нас работают взрослые, ответственные сотрудники, которым нет нужды так делать. На ретроспективах и планировании тоже очень легко выявить завышения, сроков. С занижением сроков сложнее, тут нужно понимать человека, что ему предстоит сделать, иметь в виду его результаты по прошлым итерациям и человеческий фактор.

Agile poker

Аджайл покер — это замечательный инструмент для уточнения сроков и выявления недопонимания. Кроме того, это достаточно весело. Суть аджайл покера в том, что у всех есть карточки с часами: 1, 2, 4, 8, 16, а также ? и «перерыв». Когда оценивается задача, все кто может ее оценить, кладут карточки на стол цифрой вниз и затем вскрываются. Если время овпало, то задача оценивается в это время. Если нет, и тем более если разница большая, то начинается выяснение, почему такие разные оценки. По предыдущему проекту знаю, что это очень хорошо работает и я всем рекомендовал бы использовать это игровой элемент. Иногда вскрываются дополнительные задачи, которые вообще были бы упущены и не включены в итерацию. в этой команде мы не используем покер из-за очень узкой специализации каждого сотрудника, а также из-за того, что у всех очень разные фронты работы: есть некоторая рассинхронизация в задачах. В идеальном мире вся команда берет одну фичу и совместно ее делает. Например, все делают фичу »стрельба»: сервер синхронизацию пуль и передачу пакетов, логика — попадания и поражения, клиент — отображение на клиенте, интерфейс — изменение состояний и баров, художники — огонь выстрела и эффекты попадания. У нас не так: сейчас мы добиваем хвосты (печальное наследие изгнанного исчадия ада) и только приближаемся к синхронной работе. Поэтому покер при таких разноплановых задачах, какие приходится решать нашей команде, не подходит. Кстати покер понравился команде, никогда раньше так не работавшей, когда ради эксперимента мы так провели итерацию.

Стендап митинги, ежедневные митинги

Очень быстрая блиц-летучка, на которой каждый говорит что сделал вчера, что будет делать сегодня и какие (если есть) возникают проблемы. Программисты не любят эти митинги так как им кажется, что это какая-то форма отчета, будто их призывают к доске в школе. Объяснить, что митинги нужны для повышения мотивации, синхронизации работы и выявления проблем достаточно сложно, но со временем понимание этого приходит и, если митинг пропущен, то некоторые сами спрашивают — почему пропустили и будем ли сегодня скрамить. Для команд, которые только начинают работать по аджайлу, я (личное мнение, которое идет вразрез с канонами аджайла) рекомендую делать митинги не чаще раз в 2-3 дня, или даже 3-4 дня и постепенно проводить их все чаще и чаще, без насилия над командой. Основная задача скрам мастера/ПМа сделать так, чтобы команда начала воспринимать дейли митинги как инструмент, а не как кнут. С менталитетом русских разработчиков это, пожалуй, самое сложное в аджайле.

Atlassian Jira

Джира хороша всем, а особенно тем, что она умеет работать в режиме аджайла. У нее есть форма отображения бэклога, она работает с карточками, строит burndown диаграмму, настраивается как угодно и на команду в 10 человек стоит всего $10 ежемесячно. Еще один плюс — OnDemand версия не требует покупки хостинга, домена и установок, в эти $10 ежемесячно все уже включено. Достаточно только зарегистрироваться и создать проект, остальное все сделается само за 5 минут.

Бэклог

В бэклоге Джиры есть такое понятие, как эпик (epic), то есть ключевая фича проекта. В эпики можно включать обычные фичи, баги, стори, задачи и вообще все прочее. Однако сейчас мне удобнее использовать эпики как рубрики разработки: например, архитектура сервера, игровая логика или арт. Почему — потому, что ключевые фичи, над которыми работала бы вся команда одновременно, или все уже реализованы, или до них еще как до Китая. Вероятно, когда определенный этап будет достигнут, появятся эпики командные, которые будут объединять задачи из разных компонентов. Например, это может быть »полет в космосе», и туда будут входить и задачи по серверу, клиенту, арту, логике, геймдизайну, звукам и чему-то еще. Но лучше один раз увидеть чем сто раз перечитать, поэтому наш бэклог выглядит вот так (делась скриншотом, никаких секретов не раскрою):

Что тут видно: слева — эпики (категории задач), по центру — задачи в бэклоге (уже достаточно мелкие и детализированные), справа — детальная информация по задачам и возможность их редактировать. В скриншот не попали задачи из текущего спринта, но это и не сильно важно — там то же самое, только вместо Backlog написано Sprint X и завершенные задачи зачеркнуты.

Вместо карточек, прилепленных к доске, используется борд Джиры. Он настраивается как угодно. Мы используем вид по умолчанию — три колонки: к выполнению, в работе и завершена. Задачи перетаскиваются туда-сюда; завершить можно по-разному: сделана, невозможно сделать, отменена и на тестирование. Можно добавить любые другие статусы или колонки. Выглядит текущий спринт так (картинка тоже естественно кликабельна):

Ну и по ходу пьесы можно смотреть прогресс разработки на burndown чарте (наверное, его можно перевести как »график производительности», но суть его в том, что задачи именно сжигаются в процессе разработки). Серая линия — идеальная разработка, если каждую секунду разработчики отмечают прогресс, но так конечно не бывает. Красная линия — выполнение задач, где каждая точка является успешно завершенной задачей. Идеальный спринт выглядит похоже на скриншот, когда красная линия справа снизу встречается с серой в одной и той же точке. На скриншоте ниже видно, что спринт завершился на несколько часов позже положенного (на самом деле спринт завершили немного раньше времени, но в Джире было выставлено не московское время — если будете работать в Джире, не забудьте поставить сразу же правильный часовой пояс):

Как я уже писал выше, этот чарт строится ежеминутно и любой член команды может мониторить актуальный прогресс в любой момент. На спринте есть лишний пик 23-го октября — это задачи, которые по ошибке не были упущены из спринта в момент его запуска и затем добавлены. Таким образом, добавлять незаметно задачи просто не получится. Все будут это видеть, а спринт все равно волей неволей придется завершать, или будет очень некрасивая картинка: серая линия давно дошла до финиша, а красная идет где-то сильно правее сама по себе. Так что если вы работаете с адским менеджером, подсуньте ему Джиру в режиме аджайла и ему придется завершать спринты (если он не захочет бунта команды). Или если вы владелец бизнеса, то то же самое, но в принудительном порядке, благо мониторить разработку так можно без каких-то особых знаний и программерских навыков. Конечно, это не панацея, но инструмент очень неплохой. В Джире есть множество других инструментов для наглядного отображения прогресса — по скорости, по эпикам, по объемам и так далее, но это уже для тех, кто немного освоился с Джирой и аджайлом.

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

https://jira.atlassian.com/projects/DEMO/

Вау!! 😲 Ты еще не читал? Это зря!

• гибкие методологии разработки по , scrum ,
• гибкая методология разработки , agile-методы ,
• управление проектами ,
• agile scrum ,
• разработка программного обеспечения , водопадная модель ,
• обеспечение качества , качество по ,
• стандарты тестирования , стандарты в тестировании ,
• сравнение методов разработки по , rup ,
• метод разработки динамических систем , dynamic systems development method ,
• методологии разработки , разработка по ,
• agile , бизнес аналитик ,
• scrum , agile ,
• ddd , bdd ,
• виды методологий , разработка программного обеспечения ,
• Библиотека FST
  
• scaled agile framework , safe ,
• управление зависимостями ,
• Диаграмма Ганта

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.