Любая команда разработчиков при уходе от модели «waterfall» или любого другого традиционного стиля управления проектами сталкивается с одним и тем же вопросом «как мне структурировать свою работу?». К счастью метод разработки по методологии Agile использует четыре четких механизма для того, чтобы структурировать любой проект:n
- Epic – массивный объем работ, который разделяется на задачи
- Story -наименьшая единица работы, еще называемая задачей
- Version – выпуск готового продукта
- Sprint – цикл, в котором работает команда
Работая с такими механизмами команды разработчиков могут организовать свою работу разбив ее на небольшие части, достаточные для того, чтобы отдавать предпочтение обратной связи с клиентом и отойти от привычного стиля управления проектами.nnСпособность изменять и адаптировать план разработки, на основании текущей информации является признаком гибкости. Мы определили 4 механизма, которые помогут сделать проект гибким, и покажем, как они применяются в аджайл на практике. Но сначала поговорим о разнице самих механизмов.n
Epic vs Story
Эпики – наиболее крупные объекты, представляющие собой множества задач. Эпики могут охватывать несколько спринтов и версий. В отличие от эпиков версии исчисляются релизами программного обеспечения, и при необходимости могут включать в себя несколько эпиков. Эпики помогают команде создавать иерархию и структуру, в то время как истории – отслеживать конкретные детали задачи, и могут быть разбиты на подзадачи.
nnЭпики обычно сводятся к более стратегическим целям или инициативам. Эти инициативы обычно разрабатываются в процессе долгосрочного планирования и формирования стратегии развития.n
Что такое эпик?
Эпик — это большой объем работы, который можно разбить на несколько небольших задач. Например, исследование производительности релиза. Эпик может охватывать более одного проекта, если несколько проектов включены в доску, к которой принадлежит эпик.nnПриведем пример.nnВ зависимости от того какую структуру agile Вы используете (scrum, kanban или Ваш собственный выбор) эпики могут использоваться по разному. Для канбана эпики могут использоваться в качестве направляющих для сегментации различных потоков работ. Если вы используете скрум, эпики могут помочь обозначить работу в Ваших спринтах, как в примере ниже.nnМиссия на Марс — это эпик в этом спринте. TIS 1, TIS 2 и т.д.. — все задачи в спринте (TIS Sprint 1). Вы должны заметить, что в спринте есть как задачи (истории) так и эпики.
n
Оценка эпиков.
Диаграммы Burndown также используются для визуализации эпиков, которые поддерживают мотивацию команды и информируют о продвижении работ все заинтересованные стороны.nnТакая диаграмма наглядно показывает характер развития agile. На ней можно наблюдать как идет процесс работы команды, а также когда заказчик добавил или удалил задачи. Такое прозрачное отображение данных позволяет любому участнику проекта оценить прогнозы развития, упрощает диалог с заказчиком и доверительные отношения на всех уровнях.
n
Что такое задача?
Задача (история или рассказ пользователя)– наименьшая единица работы в agile структуре. Это требование к программному обеспечению, которое выражается в нескольких коротких предложениях, в идеале использующих нетехнический язык.nnЦель пользовательской истории — вернуть конкретное состояние заказчику. Обратите внимание, что «заказчик» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними заказчиками или коллегами в Вашей компании, которые зависят от Вашей команды.nnИстории пользователей (задачи) — это несколько предложений на простом языке, которые описывают желаемый результат. Они не вникают в подробные требования.nnПример задачи – рассказа пользователя.nnИстории пользователей нарисованы владельцем продукта, а затем команда разработчиков коллективно решает более подробные требования. Задачи — это гранулированные работы, которые помогают определить элементы реализации и предстоящего спринта.nnИспользуя тот же пример, что и выше, задачи в этом спринте имеют оценку, приоритет, правопреемник, эпичность и описание, поэтому каждый может получить быстрый обзор выполняемой работы.
n
Что такое версия?
Версии — это фактические выпуски программного обеспечения для потребителя. Помните, что в конце каждого спринта команда должна иметь возможность отправлять программное обеспечение заказчику. Версии — это контролируемые изменения, которые владелец продукта действительно получает.nnВерсии часто развиваются по множеству спринтов, как эпики. Эпик также не должен полностью «дублировать» версию. Продуманные владельцы продуктов могут растягивать эпик на несколько версий. Представляя эпик в нескольких версиях, владелец продукта может узнать, как рынок реагирует на этот эпик и принимает решения о дальнейшем развитии продукта, а не делает один гигантский релиз.nnПример использования версийnnВладелец продукта может структурировать стратегию выпуска версий ПО следующим образом:n
- Версия 1: логин, выход из системы, управление паролями
- Версия 2: история покупок
- Версия 3: сохранение настроек
- и т.д.
Область изменения версии также является естественной частью развития проекта по методу agile. Графики Burndown наглядно показывают, как версия эволюционирует с течением времени. Изменения в версии должны обсуждаться со всей командой, чтобы держать всех в курсе дела.n
Что такое спринт?
Спринт — это короткий период, в течение которого команда разработчиков реализует и обеспечивает дискретное и потенциально увеличиваемое приращение приложения, например. рабочая версия. Если Вы еще не имели практики работы со спринтами, мы рекомендуем использовать фиксированную двухнедельную продолжительность для каждого спринта. Этого промежутка времени достаточно для того, чтобы добиться чего-то, но не так много, чтобы испытывать нехватку отзывов потребителей.nnСпринты являются частью структуры scrum. Команды kanban, напротив, работают над следующей задачей по мере возможности ее решения. В этом случае прогнозирование не требуется.nnScrum команды фиксируют набор задач в течение фиксированного периода времени. Теоретически, спринты могут длиться одну, две или четыре недели. Длина спринта определяется командой, которая работает над проектом. После определения частоты спринтов команда постоянно работает в этом ритме. Спринты с фиксированной длиной увеличивают точность оценки сроков работы и позволяют прогнозировать будущую скорость для команды в аджайл проекте. Делать выводы можно, как только будут получены данные из нескольких завершенных спринтов.nnПример спринта Вы уже видели на скриншотах выше. TIS Sprint 1 – это множество задач.
nnНесколько вещей, которые вы должны знать о спринте:n
- Как только команда фиксирует набор задач для спринта, а спринт запускается, мастер скрум запрещает изменение задач. Это заставляет команду сфокусироваться и не поддаться искушению добавить работу в спринт после его запуска. Добавление работы в середине спринта компрометирует способность команды точно прогнозировать и оценивать.
- В конце каждого спринта команда должна предоставить рабочую часть программного обеспечения. В scrum это называется потенциально прибыльным приращением (PSI). Владелец продукта в итоге решает, когда PSI перейдет в релиз. Но работа должна быть достаточно полной, чтобы быть подходящей для выпуска в конце спринта.
Оценка спринтов.nnОтличным инструментом для любой команды scrum являются графики burndown. Они четко отслеживают прогресс на протяжении всего спринта с «оставшейся работой» по оси Y и «временем» на оси X. Диаграммы и графики Burndown являются мощным мотиватором для команды, и фокусируют каждого ее члена на работе над спринтом.
n
Масштабирование.
У более крупных организаций часто есть несколько команд agile, работающих над общим проектом, а планирование портфолио — ключевая часть работы agile в масштабе. Эпики и версии закладывают основу для надежного управления портфолио на уровне команды. Управление портфолио охватывает программы отслеживания в нескольких командах, сохраняя при этом тот же уровень гибкости на более высоких уровнях организации. Узнайте больше о гибкости в масштабе большой организации в разделе agile portfolio.n
Наша компания предоставляет различные услуги по внедрению, оптимизации, переносу, обучению работы с продуктами jira, обращайтесь [email protected]