Atlassian *

Вы когда-нибудь задумывались, какие именно задачи учитываются при расчёте velocity - и как на самом деле работают Velocity и Sprint Reports? Если нет, скорее всего ваши репорты не отражают реальную картину.

Вот 4 распространённых нюанса, которые могут серьёзно исказить ваши Velocity и Sprint Reports - и как моё приложение Multi-team Metrics & Retrospective может во многом автоматически устранить их:

1. Вы удаляете задачи из спринта только если они были действительно деприоритизированы?

Если вы вручную убираете незавершённые задачи из спринта (например, чтобы перенести в бэклог или следующий спринт) до его завершения вместо того, чтобы проследовать по workflow, который запускается после нажатия на кнопку 'Complete sprint', то Jira не посчитает их как "незавершённые" в Sprint Report. В результате ваш velocity окажется искусственно завышен. Удалять следует только те задачи, которые действительно деприоритизированны. Все остальные должны остаться и быть перенесены соответствующим образом.

2. Все ли выполненные задачи действительно входят в спринт?

Метрика Issues completed outside of this sprint в Sprint Report учитывает только те задачи, которые были завершены вне спринта И затем вручную добавлены в него. На практике многие команды закрывают задачи, но забывают их класть в спринт. Если вы проанализируете хотя бы квартал, то скорее всего найдёте несколько задач, которые были решены, но так и не вошли ни в один спринт. В результате Velocity и Sprint Reports не учитывают часть задач.

3. А как насчёт дубликатов?

Работа с дубликатами - это каверзная активность. Если не включить их в спринт - они теряются из поля зрения. Если включить - нужно строго следить, чтобы у них не было эстимейта, иначе они искажают метрики. В энтерпрайз компаниях иметь дюжину дубликатов не является чем-то особенным - это незамечаемый, но ощутимый источник искажений.

4. Оцениваете ли вы повторно одну и ту же работу?

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

Бонус: Путаница с Added Scope на ретроспективах

Если вы проводите анализ добавленного скоупа работ в активный спринт, то знаете, насколько сложно отличить действительно новую работу от ожидаемых дополнений - например, багов, выявленных при тестировании задач текущего спринта, или тех же дубликатов. В отчёте Sprint Report такие задачи отмечены звёздочкой (*), но отдельной метрики для них нет - приходится вручную анализировать каждую задачу.

Компания Atlassian была первопроходцем в преобразовании традиционной модели обеспечения качества (Quality Assurance) в модель Поддержки Качества (Quality Assistance). На протяжении многих лет они разрабатывают свою методологию, доступную в различных материалах. 

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

В этой статье я поделюсь результатами исследования, посвященного унификации процессов создания проектов в Jira, используя возможности автоматизации и API. Статья была написана с помощью GPT Deep Research в целях изучения различных подходов к унификации рабочих процессов и настройки проектов в Jira. Основная цель — собрать мнения и комментарии от других экспертов, чтобы понять, как они подошли к созданию стандартов и оптимизации процессов в своей практике. Буду рад услышать ваши истории и советы по унификации в Jira, а также обсудить лучшие методы для повышения эффективности и согласованности в работе команд.

Как вы проводите ретроспективы в своей команде? Используете Confluence или Miro с такими техниками, как ‘start, stop, continue’ или 4L? Как вы количественно оцениваете, стала ли ваша команда лучше за определённый период — будь то год или квартал? Полагаю, что никак, ведь извлекать данные из визуальных инструментов или вики-страниц, которые часто хаотично оформлены за целый год, — задача непростая.

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

Я тоже проходил через это, пока не реализовал решение для JIRA — Multi-team Metrics & Retrospective. Очевидно, что один из самых критически важных этапов ретроспективы — это анализ невыполненных коммитментов, что чаще всего означает незавершённый скоуп задач. Самый эффективный способ прогрессировать во времени я считаю анализ проваленных задач в каждом конкретном случае — согласно соответствующей метрике за конкретный период времени: будь то спринт, месяц, квартал, полугодие, год или релиз в PMIS (трекере задач).

Меня зовут Дина, я занимаюсь аналитикой в одной из команд «Ростелеком Информационные Технологии» (РТК ИТ). В статье хочу осмыслить полученный опыт переноса документации и поделиться своими соображениями. Возможно вы тоже думаете о переходе на базу знаний. Такой переход может занять больше времени, чем ожидается. Я расскажу, как это было у нас. В конце подведу итоги: что получили и что потеряли.

Всем привет, меня зовут Денис, я хотел бы поделиться опытом использования AWX в рамках одной из наших потребностей. Статья может быть полезна ребятам с «инфры», если в компании используется vmware и подобное cloud решение для частого деплоя, а для всяческой бюрократии и запросов вы обращайтесь в Jira.

Недавно @kuksepa выкладывала отличную статью про AWX по этому я не стану много описывать конкретно его, а постараюсь кратко описать процесс. Прошу не обращать внимание на замазанные элементы.

Предлагаю познакомиться с нашим опытом по внедрению метрик по JIRA для измерения продуктивности команды разработки 1С в компании Moex.

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

Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.

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

Привет! Приятно ведь читать хорошо оформленные статьи на уютном хабре? В которых часть текста спрятана под катом, есть подписи к картинкам, красивые и понятные таблицы и все остальные плюшки? Я думаю очень приятно. Поэтому предлагаю рассмотреть немного полезных советов, о том какие макросы в Confluence помогали делать это раньше, а теперь точно также помогают в EvaWiki.

В интернете много полезной информации по использованию Confluence. Например, вот статья с рекомендациями по использованию макросов. В ней всё достаточно круто описано, но хотелось бы внести поправку. Конфлюенс ушел из России, а EvaWiki осталась. И теперь тот функционал, который был в зарубежном решении можно использовать в российском.

Статья может быть полезной для тех, кто активно работал в Confluence и хочет точно также делать это в нашем ПО.

Привет, Хабр! Сегодня хочу поделиться с вами опытом, как мы повышаем качество сервиса вычислительного оборудования наших клиентов и оптимизируем работу команд Центра компетенций по сервису в КРОК. Ранее я уже писала про автоматизацию работы со складом ЗИП. А сегодня будет нестандартная история, когда решение, придуманное для удобства клиентов, затем раскатывается на сотрудников компании.

В новой статье поделюсь, как мы в направлении создали и внедрили клиентский портал для работы с заявками на обслуживание и ремонт оборудования – прозрачный, удобный и быстрый. Расскажу, как выдерживать нужный уровень SLA с максимальным удобством и вовлечением заказчиков, организовывать комфортную и эффективную работу поддержки и еще про разные фишки нового решения.

Всем привет, вас ждет история, разрывающая стереотипы! Многие до сих пор считают, что «девушка в IT — это горе в семье». А у нас в компании есть живое опровержение этой идеи — наша руководитель отдела разработки Ксения Липская.

О том, как «девочка‑девочка» учится на айтишника, уходит и возвращается к IT‑истокам, секретах управления и увеличении скорости разработки — расскажет сама Ксения. А я всего лишь записал этот рассказ и задавал уточняющие вопросы ;)

Привет, Хабр! На связи ведущий аналитик Ульяна. В первой главе я рассказала, что такое Confluence, зачем его используют и как работать с макросами. 

Во второй главе поговорим про шаблоны и метки, которые помогут организовать процессные и проектные рутины, например ведение MN, RFC и другое интересное.

Привет, Хабр! Меня зовут Игнат, в Samokat.tech я пишу плагины, автоматизации и интеграции для Jira. 

Как разработчик-самоучка, который до «вот этого всего» немного писал на Java, но не пользовался ни средствами сборки (привет, Maven!), ни фреймворками (привет, Spring!), и первые шаги делал по мануалам Atlassian, я сталкивался (и продолжаю) с проблемами, решений которых вендорская документация не подскажет, и эти решения приходится открывать самому. 

В этой статье мы вместе с вами напишем свою Spring-аннотацию, которая будет с помощью кастомного бин-постпроцессора (который мы тоже напишем) отключать в нашем плагине для Jira ненужный в проде отладочный функционал.

Эта статья ориентирована на начинающих разработчиков в стеке Atlassian и администраторов, пробующих себя в разработке плагинов для Jira. Те, кто до знакомства с Atlassian SDK уже разрабатывал «под ентерпрайз», не обязательно найдут здесь что-то новое, остальных – приглашаю под кат.

Добрый день! Это Алексей из “ГлоуБайт Софт”. Мы продолжаем рассказывать о функциональности китайской ITSM-платформы ZenTao. Сегодня я кратко расскажу, как устроен модуль “Документы”, который может заменить Confluence от Atlassian. 

Привет! Меня зовут Таня, я куратор в SM Lab. В этом посте я расскажу вам о нашем пути оптимизации тестирования — узнаете, какие на нашем продукте были проблемы в процессах тестирования, как мы их решали, почему не надо отвлекать тестировщиков и в чём польза интуитивного тестирования.

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

Итак, основа. 

У нас есть две доски в Jira. Первая отвечает непосредственно за релизные задачи и хотфиксы, вторая — за задачи сопровождения и инциденты. Рассмотрим подробнее первую доску с задачами и хотфиксами.

На ней есть три колонки, с которыми и работают тестировщики:

Всем привет! Это ламповая история от основателей компании – рассказ о хронологии замены Jira, а также о том, как собственные разработки помогают при создании будущих сервисов. Всё что идёт ниже – расшифровка аудио с небольшой редактурой, которая записана мной. Все совпадения случайны, трюки выполнены профессионалами, за русский язык ногами не пинайте.

В начале описана общая история компании, которая поможет разобраться "что-как", затем про технологии. А на сладкое - как рынок иногда сам подсказывает куда нужно идти.

Привет Хабр! Меня зовут Белков Евгений, я руководитель направления разработки Siebel CRM в Московском кредитном банке.

Сегодня я хочу поделиться своим опытом разграничения содержимого страницы для разных пользователей. 

Приветствую всех, кому интересна тема перехода с Jira на альтернативные решения. 

Совсем недавно мы, GlowByte Soft, рассказывали о том, какие бизнес-процессы компании могут автоматизировать на базе ITSM-платформы ZenTao. По откликам мы поняли, что нужно подробнее остановиться на самой базовой и самой главной функциональности ITSM-платформ – управлении сервисом и работе с заявками.