что такое спринт в jira
Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.
Механизмы Jira, которые позволяют эффективно структурировать работу
Любая команда разработчиков при уходе от модели «waterfall» или любого другого традиционного стиля управления проектами сталкивается с одним и тем же вопросом «как мне структурировать свою работу?». К счастью метод разработки по методологии Agile использует четыре четких механизма для того, чтобы структурировать любой проект:
Работая с такими механизмами команды разработчиков могут организовать свою работу разбив ее на небольшие части, достаточные для того, чтобы отдавать предпочтение обратной связи с клиентом и отойти от привычного стиля управления проектами.
Способность изменять и адаптировать план разработки, на основании текущей информации является признаком гибкости. Мы определили 4 механизма, которые помогут сделать проект гибким, и покажем, как они применяются в аджайл на практике. Но сначала поговорим о разнице самих механизмов.
Epic vs Story
Эпики – наиболее крупные объекты, представляющие собой множества задач. Эпики могут охватывать несколько спринтов и версий. В отличие от эпиков версии исчисляются релизами программного обеспечения, и при необходимости могут включать в себя несколько эпиков. Эпики помогают команде создавать иерархию и структуру, в то время как истории – отслеживать конкретные детали задачи, и могут быть разбиты на подзадачи.
Эпики обычно сводятся к более стратегическим целям или инициативам. Эти инициативы обычно разрабатываются в процессе долгосрочного планирования и формирования стратегии развития.
Что такое эпик?
Эпик — это большой объем работы, который можно разбить на несколько небольших задач. Например, исследование производительности релиза. Эпик может охватывать более одного проекта, если несколько проектов включены в доску, к которой принадлежит эпик.
В зависимости от того какую структуру agile Вы используете (scrum, kanban или Ваш собственный выбор) эпики могут использоваться по разному. Для канбана эпики могут использоваться в качестве направляющих для сегментации различных потоков работ. Если вы используете скрум, эпики могут помочь обозначить работу в Ваших спринтах, как в примере ниже.
Миссия на Марс — это эпик в этом спринте. TIS 1, TIS 2 и т.д.. — все задачи в спринте (TIS Sprint 1). Вы должны заметить, что в спринте есть как задачи (истории) так и эпики.
Оценка эпиков.
Диаграммы Burndown также используются для визуализации эпиков, которые поддерживают мотивацию команды и информируют о продвижении работ все заинтересованные стороны.
Такая диаграмма наглядно показывает характер развития agile. На ней можно наблюдать как идет процесс работы команды, а также когда заказчик добавил или удалил задачи. Такое прозрачное отображение данных позволяет любому участнику проекта оценить прогнозы развития, упрощает диалог с заказчиком и доверительные отношения на всех уровнях.
Что такое задача?
Задача (история или рассказ пользователя)– наименьшая единица работы в agile структуре. Это требование к программному обеспечению, которое выражается в нескольких коротких предложениях, в идеале использующих нетехнический язык.
Цель пользовательской истории — вернуть конкретное состояние заказчику. Обратите внимание, что «заказчик» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними заказчиками или коллегами в Вашей компании, которые зависят от Вашей команды.
Истории пользователей (задачи) — это несколько предложений на простом языке, которые описывают желаемый результат. Они не вникают в подробные требования.
Пример задачи – рассказа пользователя.
Истории пользователей нарисованы владельцем продукта, а затем команда разработчиков коллективно решает более подробные требования. Задачи — это гранулированные работы, которые помогают определить элементы реализации и предстоящего спринта.
Используя тот же пример, что и выше, задачи в этом спринте имеют оценку, приоритет, правопреемник, эпичность и описание, поэтому каждый может получить быстрый обзор выполняемой работы.
Что такое версия?
Версии — это фактические выпуски программного обеспечения для потребителя. Помните, что в конце каждого спринта команда должна иметь возможность отправлять программное обеспечение заказчику. Версии — это контролируемые изменения, которые владелец продукта действительно получает.
Версии часто развиваются по множеству спринтов, как эпики. Эпик также не должен полностью «дублировать» версию. Продуманные владельцы продуктов могут растягивать эпик на несколько версий. Представляя эпик в нескольких версиях, владелец продукта может узнать, как рынок реагирует на этот эпик и принимает решения о дальнейшем развитии продукта, а не делает один гигантский релиз.
Пример использования версий
Владелец продукта может структурировать стратегию выпуска версий ПО следующим образом:
Область изменения версии также является естественной частью развития проекта по методу agile. Графики Burndown наглядно показывают, как версия эволюционирует с течением времени. Изменения в версии должны обсуждаться со всей командой, чтобы держать всех в курсе дела.
Что такое спринт?
Спринт — это короткий период, в течение которого команда разработчиков реализует и обеспечивает дискретное и потенциально увеличиваемое приращение приложения, например. рабочая версия. Если Вы еще не имели практики работы со спринтами, мы рекомендуем использовать фиксированную двухнедельную продолжительность для каждого спринта. Этого промежутка времени достаточно для того, чтобы добиться чего-то, но не так много, чтобы испытывать нехватку отзывов потребителей.
Спринты являются частью структуры scrum. Команды kanban, напротив, работают над следующей задачей по мере возможности ее решения. В этом случае прогнозирование не требуется.
Scrum команды фиксируют набор задач в течение фиксированного периода времени. Теоретически, спринты могут длиться одну, две или четыре недели. Длина спринта определяется командой, которая работает над проектом. После определения частоты спринтов команда постоянно работает в этом ритме. Спринты с фиксированной длиной увеличивают точность оценки сроков работы и позволяют прогнозировать будущую скорость для команды в аджайл проекте. Делать выводы можно, как только будут получены данные из нескольких завершенных спринтов.
Пример спринта Вы уже видели на скриншотах выше. TIS Sprint 1 – это множество задач.
Несколько вещей, которые вы должны знать о спринте:
Отличным инструментом для любой команды scrum являются графики burndown. Они четко отслеживают прогресс на протяжении всего спринта с «оставшейся работой» по оси Y и «временем» на оси X. Диаграммы и графики Burndown являются мощным мотиватором для команды, и фокусируют каждого ее члена на работе над спринтом.
Масштабирование.
У более крупных организаций часто есть несколько команд agile, работающих над общим проектом, а планирование портфолио — ключевая часть работы agile в масштабе. Эпики и версии закладывают основу для надежного управления портфолио на уровне команды. Управление портфолио охватывает программы отслеживания в нескольких командах, сохраняя при этом тот же уровень гибкости на более высоких уровнях организации. Узнайте больше о гибкости в масштабе большой организации в разделе agile portfolio.
Наша компания предоставляет различные услуги по внедрению, оптимизации, переносу, обучению работы с продуктами jira, обращайтесь [email protected]
Как организовать ресурсное планирование в 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 (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.
5 шагов к Agile с инструментами JIRA
Екатерина Базылева, менеджер a1qa, сертифицированный Scrum-мастер и SAFe Agilist, рассказывает об инструментах JIRA, которые позволяют планировать Agile-проекты, управлять ими и отслеживать эффективность работы команды.
Как инструменты JIRA помогают выполнить работу по гибким методологиям?
Под «работой» подразумевается любая рабочая задача: написание тестовой документации, составление плана по тестированию, проведение регрессионного теста или подготовка обучающего мероприятия в центре компетенции.
В первую очередь эта статья будет полезна тем, кто:
Начнём. У каждого менеджера проекта есть to-do list из рабочих задач и, возможно, даже не один. У кого-то список состоит из множества мелких задач одного проекта, у кого-то включает несколько проектов.
Нередко выполнение задач зависает, при этом к ним постоянно добавляются новые. Мы периодически перебираем этот список и верим, что вот завтра, хотя нет, лучше в понедельник начнём разбирать его. Знакомо?
Продуктивно решать все возникающие задачи – это один из постулатов работы по гибким методологиям. Однако не стоит ждать, когда к вам придёт проект, который должен быть выполнен по Agile. Возьмите свой текущий проект и сами реализуйте его с соблюдением Agile-принципов.
Для этого достаточно выполнить 5 шагов.
ШАГ 1 — Создание и настройка Agile Board
Создайте борд (Jira-Agile-Getting Started), на котором вы будете отслеживать ход выполнения задач и управлять ими в бэклоге. Борд можно сделать как для задач конкретного проекта, так и для выборки, в которую будут входить несколько проектов.
Вот так выглядит Agile Board по умолчанию:
Теперь настроим его под себя.
Настраиваем колонки (Columns). Они будут отражать жизненный цикл задач. При этом можно настроить произвольное количество колонок и дать им свои названия.
На борд можно добавить дорожки (Swimlanes), которые помогут структурировать задачи. Среди доступных вариантов можно выбрать дорожки по группе задач (Epics), по исполнителю (Assignee) или по задачам (Stories). Последний вариант особенно удобен, если активно используются подзадачи. Также дорожки можно настроить по собственным фильтрам (или вовсе обойтись без них).
Для того чтобы скрыть или, наоборот, показать специфические задачи, можно добавить быстрые фильтры (Quick Filters) и, например, отфильтровать только задачи на обновление тестовой документации или задачи конкретного QA-инженера. Фильтры задаются через JQL-запросы.
В конце нужно определиться, в каких единицах будут оцениваться задачи. Самые распространённые варианты – это стори-поинты (Story Points) и часы, но могут быть и другие единицы, предлагаемые JIRA.
ШАГ 2 — Упорядочение списка задач в бэклоге
После того как Agile Board создан в режиме «Планирование» или в бэклоге (это зависит от версии JIRA), нам становится доступен удобный интерфейс для превращения хаотичного списка задач в упорядоченный бэклог.
Теперь все задачи находятся в одном месте, их легко оценивать и располагать по приоритету, передвигая вверх и вниз.
Итак, мы создали и настроили Agile Board в JIRA и составили бэклог с задачами. Что же дальше?
ШАГ 3 — Планирование спринтов
Когда список задач большой, лучшее, что можно сделать, – выбрать несколько самых приоритетных и выполнить их. Давайте запланируем первый спринт.
Capacity – объем работы, который команда может сделать в течение спринта. Эта цифра учитывает доступность людей, а также тот факт, что люди будут работать над задачами спринта не всё своё время. Часть времени будет уходить на коммуникацию внутри команды и другие активности.
Например:
Размер команды – 2 специалиста, занятых полный рабочий день.
Продолжительность спринта – 2 недели.
Общее количество рабочих часов – 160. При этом мы знаем, что одному из инженеров нужно пройти тренинг по веб-сервисам (16 часов) и на коммуникацию по задачам у команды уходит 20% рабочего времени.
Итого, capacity на спринтовые задачи получится (160-16)*0,8=115,2 ч.
ШАГ 4 — Выполнение спринта
Настало время выполнить набранные задачи, т. е. завершить спринт.
На шаге 1 мы создавали и настраивали Agile Board. Теперь он поможет нам проследить, на каком этапе находится каждая из задач, кто и какую задачу выполняет.
Можно сразу назначить каждой задаче исполнителя. Если ваша команда достаточно самоорганизованная, то ребята могут сами брать себе задачу из списка свободных. Как только пользователь передвигает задачу в In Progress, он автоматически становится ее исполнителем.
Если вы регулярно логируете время и обновляете Remaining Time, то сможете использовать график сгорания, или график хода выполнения работ (Burndown Chart). Он покажет ваш прогресс по отношению к цели спринта и поможет оценить шансы на его успешное завершение.
Серая линия на графике показывает идеальный ход выполнения проекта.
Красная линия – объём незакрытых задач, зелёная – потраченное время. Если красная линия справа снизу встречается с серой в одной и той же точке – это лучший вариант развития событий.
На примере выше у команды явно есть проблемы: объем выполненной работы заметно меньше запланированного. Если они не ускорятся в последние дни спринта, то не успеют завершить все запланированные задачи в срок.
Эта же команда идет с опережением, и ей стоит подыскать себе дополнительные задачи, если положительный тренд сохранится.
ШАГ 5 — Завершение спринта, ретроспектива
Этот шаг хоть и последний, но не менее важный. Agile — это не только борды, стори и спринты. Это также поиск узких мест и усовершенствование процесса.
Поэтому после нажатия на кнопку End Sprint стоит потратить немного времени, чтобы посмотреть, как всё прошло, т. е. провести ретроспективу.
И не расстраивайтесь, если первый спринт у вас будет «комом».
Ретроспектива: на что обратить внимание?
Velocity – это скорость работы команды, тот объём, который команда может завершить за спринт. Завершить – это значит закрыть задачу и переместить ее в колонку Done.
Вот мы и выполнили последний шаг нашего Agile-проекта.
Как видите, 5 шагов к Agile действительно просты. Давайте ещё раз их перечислим:
На первый взгляд JIRA кажется сложной, но полученная польза однозначно стоит потраченных усилий и времени.
В следующей статье рассмотрим несколько интересных профессиональных «фишек» работы в JIRA.