Grooming agile: Для чего и как проводят backlog grooming в продуктовых командах? / Блог компании Hygger / Хабр

Для чего и как проводят backlog grooming в продуктовых командах? / Блог компании Hygger / Хабр

Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?

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

Еще один тип встреч в Scrum

Backlog grooming — это собрание представителей Scrum-команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.

Наверняка, большинство менеджеров и собственников продуктов благодаря опыту и практике знают, как превратить рутинное управление бэклогом в приятный процесс. Чтобы достичь этого, необходимо тщательно ухаживать за бэклогом, “чистить” и оптимизировать его. Это то, что называется grooming или product backlog refinement.

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

Стратегический смысл груминга в управлении продуктом

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

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

Уход за бэклогом — это активность с участием менеджера проекта (менеджера продукта/ собственника продукта) и представителя клиента, направленная на то, чтобы разбить бэклог на истории пользователей, переориентировать их и задать новые приоритеты. Backlog grooming в управлении продуктом должен стать постоянным событием, основанном на глубоком анализе и четких действиях.

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

Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.

Процесс не считается формальный частью Scrum. Тем не менее, рекомендуется, чтобы владелец продукта и представители команды выделяли до 15% каждого спринта для такой активности.

Главные цели процесса backlog grooming

Иногда собрание по backlog grooming называют story time session. В любом случае, цель этого мероприятия — обсудить текущий бэклог, определить и предложить действия по его оптимизации. Это может включать следующее:

• Написание новых пользовательских историй
• Удаление неактуальных пользовательских историй
• Переоценка приоритетов для задач
• Добавление новых функций, определение приоритетов и их оценка
• Усовершенствование и изменение приоритетов ранее описанных пользовательских историй
• Разбивка некоторых user stories на более мелкие
• Пересмотр критериев тестирования
• Анализ времени и индивидуальных оценок по отдельным вопросам бэклога
• Корректировка оценок в свете новых данных и т. д.

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

Результат хорошего груминга

Результатам grooming является здоровый вид бэклога:

• Когда задач вверху бэклога достаточно для 2-3 спринтов
• Пользовательские истории понятны всем членам команды
• Истории оценены командой
• User stories имеют размер, позволяющий реализовать несколько из них за один спринт

Какие инструменты использовать для backlog grooming?

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

• Оценка Value показывает, какую бизнес-ценность может принести продукт.
• Efforts измеряет ресурсы, необходимые для выполнения задачи.

В Hygger.io для визуализации задач бэклога и определения их приоритетов применяется график Backlog Priority Chart. С его помощью легко понять, когда бэклог становится слишком большим.

В качестве заключения

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

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

Подытоживая, отметим основные преимущества backlog grooming:

• Устраняет неопределенность и неизвестные факты в пользовательских историях, что несомненно повышают эффективность продукта.
• Помогает избежать “переделок” в разработке и тестировании.
• Идентифицирует зависимости в команде и помогает прогнозировать риски.
• Постоянные проведение grooming экономит время команды разработчиков для дальнейшего обсуждения во время цикла спринта, потому что обеспечивает ясность для разработчиков и тестировщиков.
• Успешный grooming приводит к эффективному планированию спринта.

Agile in IT: Backlog Grooming

Один из основных и обязательных артефактов в Scrum, это бэклог задач. Фактически это список требований полученных от бизнеса и сформулированных в виде задач на разработку. Однако, сам по себе список всех задач еще не несет большой ценности, если он не привносит какой-то системы и структуры. Очень важным будет грамотная работа с бэклогом с тем, чтобы задачи в нем были актуальными, можно было провести их сравнения с точки зрения размеров и важности. Именно для этого и необходим Backlog Grooming, далее в статье разберемся как его организовать и провести.

Что такое Backlog Grooming? 

Дословно, это «ухаживание» за продуктовым бэклогом. Grooming, это регулярное мероприятие, в рамках которого Product Owner совместно с командой проводят анализ и «перетряхивание» бэклога. Grooming проводиться, чтобы убедиться в том, что представленные в бэклоге задачи актуальны, имеют приоритет, а представленные в верхней части списка задачи, готовы к планированию в Sprint, реализации и выпуску.

Основные цели Backlog Grooming:

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

2. Уточнить актуальность задач, представленных в бэклоге с точки зрения развития продукта. В том числе пройти по отложенным задачам с низким приоритетом – возможно они стали более важными, либо их напротив можно окончательно исключить из списка;

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

Организация встречи для проведения Grooming. 

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

Важно не совмещать проработку бэклога с планированием спринта. В рамках Sprint Planning мы уже должны иметь список подготовленных задач, чтобы сосредоточиться только на вопросах реализации историй и формировании скоупа (состава задач) для ближайшей итерации. Задача Grooming выполнить этот необходимый предварительный шаг и подготовить набор задач для планирования в работу.

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

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

На встречу по Grooming должны быть приглашены все члены Scrum команды, т.к. их вклад ценен для реализации задач. Если сессия обработки бэклога приводит к какому-либо изменению приоритетов важно, чтобы команда была согласна с этими изменениями.

Этапы и активности в рамках Backlog Grooming:

1. Удаление существующих задач:

• Исключение из бэклога пользовательских историй, которые больше не актуальны

2. Добавление новых задач:

• Создание новых пользовательских историй для новых потребностей бизнеса

3. Декомпозиция задач:

• Разбиение крупных задач (Epics) на пользовательские истории, которые могут быть реализованы и выпущены независимо от остальных задач. При этом каждая такая история содержит в себе бизнес ценность.
• Поводами для декомпозиции могут быть: 
  • Крупный размер задачи, который не позволяет реализовать ее в рамках одной итерации;
  • Epic содержит в себе несколько подзадач, каждая из которых имеет различный приоритет с точки зрения развития продукта.

• Техники декомпозиции задач: Agile: 8 методов декомпозиции задач

4. Приоритезация задач: 

• Определение приоритетов для пользовательских историй в бэклоге, в том числе уточнение приоритетов выставленных ранее;
• Методы приоритезации задач: Agile: методы приоритезации задач

5. Оценка задач:

• Присвоение оценок историям, которые не были оценены ранее;
• При необходимости выполняется переоценка тех задач, по которым появились новые вводные, уточнились требования;
• Методы оценки User Stories: Agile: 7 техник оценки задач

6. Применение результатов\уроков предыдущих итераций разработки:

• В рамках Grooming суммируется и используется полученный во время предыдущих спринтов опыт, чтобы максимально оптимизировать развитие продукта и технической точки зрения и в плане ожиданий пользователей.

В целом, Grooming помогает гарантировать, что требования будут уточнены, а пользовательские истории будут подготовлены к работе заранее до планирования в Sprint. В этом случае команда во время планирования очередной итерации имеет хорошо проанализированный и четко определенный набор историй, которые разбиты атомарные и независимые составляющие, оценены и приоритезированы. Основываясь на результатах выполненной итерации (прошлый Sprint), могут быть скорректированы требования или выполнена переориентация направления развития продукта, которые будут учтены в последующих спринтах. Таким образом Grooming поддерживает и повышает гибкость Scrum процесса за анализа полученных знаний и фидбэков и включения соответствующих изменений (например, новый функционал и\или технические задачи) в будущие спринты.

Уход за беклогом (груминг), или Как сделать планирование спринтов легкой задачей — Алексей Кривицкий

Довольно давно, когда я запускал свой первый Скрам-проект (Ciklum, проект Encode, 2004 год) мы не знали, что такое груминг.

Заказчик созванивался с нами для планирования спринта… и тут начиналось: мы задавали глупые вопросы; заказчик куда-то убегал за ответами, с кем-то советовался и менял приоритеты; мы воевали с
картами за истории, били истории на задачи… и так бесконечно. Планирование спринта у нас редко занимало меньше 8 часов.

Хуже всего то, что через две недели этот кошмар нужно было повторить. Сильная закалка для Скрам-мастера! 🙂

Сегодня практика “причесывания беклога” (по-английски: “grooming”) является одной из тех активностей, без которых не обходятся продуктивные agile-команды.

Эта практика описана в “Скрам-гайде” от Швабра и Сазерленд, формальном
описании Скрама.

Груминг – это не ещё один тип встреч в Скраме. Это активность, которая делается на протяжении спринта для подготовки беклога к следующему спринт-планированию.

Груминг стоит проводить:

• активно в начале проекта или релиза;
• затем регулярно (или по необходимости) в течение всего проекта, выделяя на эту активность время в каждом спринте.

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

Когда у вас появится достаточно нагрумленных историй на 2-3 спринта вперёд, стоит чуть сбавить темп и дальше грумить регулярно, но понемногу. Так вы будете поддерживать в
постоянном здоровом состоянии верхушку беклога.

Здоровое состояние беклога или Definition of Ready:

• верхушки беклога достаточно на 2-3 спринта;
• эти истории понятны всем членам команды;
• истории имеют такой размер, что несколько из них могут быть сделаны за спринт;
• истории оценены командой;
• записаны критерии приёмки или “how to demo”.

Печать истории из треккинга:

Пригласить Владельца Продукта приехать и поучаствовать вживую:

Создать непринужденную атмосферу и погрумить в свое удовольствие: 

что такое бэклог продукта и как им управлять? / Блог компании Hygger / Хабр

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

Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.

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

Бэклог продукта vs бэклог спринта

Эти два компонента Scrum несут разный смысл, но их часто путают.

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

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

Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.

В чем смысл бэклога продукта?

Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.

Обычный бэклог продукта включает следующие пункты:

• Функции продукта (например, формы пользовательских историй — описания желаемой функциональности)
• Разные баги
• Получение новых знаний (например, обновление рабочих мест)
• Технические работы (например, любые полезные исследования)

Бэклог продукта не может быть завершенным, поскольку он динамически меняется и постоянно улучшается.

Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.

Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.

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

Для чего нужен backlog refinement?

Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.

Чем бэклог продукта в Agile отличается от простого списка дел?

У бэклога продукта есть определенные свойства:

• Любая отметка в backlog продукта добавляет ценности для клиентов.
• Все записи в бэклоге продукта оцениваются.
• Все отметки получают свой приоритет и порядок.
• Уровень детализации зависит от позиции отметки в Scrum backlog.
• Бэклог продукта — это живой документ без каких-либо бездействий или задач низкого уровня приоритета.

Что делать, если бэклог неустанно растет?

Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?

Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:

• Структурирование бэклога на основе Kanban-досок, лейблов и горизонтальных Swimlanes.
• Оценка идей (с помощью удобных критериев Value and Effort).
• Визуализация и приоритезация важных идей на основе диаграммы Backlog Priority Chart.

Структурирование бэклога

В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:

• Collect Ideas — для сбора всех идей.
• Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
• Score Ideas — для оценивания идеи.
• Approval — для проверки идеи Scrum-мастером или менеджером проекта.
• Developing — для отправления идеи в разработку.
• Done — для реализованных идей. Это означает, что функция «залита» на продакшн.

Swimlanes в Hygger можно использовать для организации идей. Эти горизонтальные столбцы на Kanban-доске используются для разделения различных видов проблем, которыми заняты члены команды. Они помогают командам легче определить, над каким вопросом им работать дальше.

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

Оценка идей

В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.

• Value показывает, какую бизнес-ценность может принести ваш продукт или бизнес.
• Efforts измеряют ресурсы, необходимые для выполнения задачи.

Backlog Priority Chart

Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:

• Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
• Big Bets для идей, имеющих большие ценность и усилия.
• Maybes для идей с низкими ценностью и усилиями.
• Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.

Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.

Grooming scrum. Backlog grooming (Уточнение Бэклога)

Уточнение бэклога, или Product backlog grooming (Backlog Refinement), пока не считается официальной встречей в Скраме, но очень многим помогает продуктивнее провести Планирование Спринта. А как лучше всего провести сессию уточнения Бэклога (backlog или scrum grooming session)? Рассказывает Майк Кон.

Кому стоит присутствовать?

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

Хотя в целом я очень верю в вовлечение всей команды, для этой встречи собирать всех непрактично. И вот почему:

1. Уточнение бэклога часто происходит за два-три дня до окончания спринта. В каждой команде почти всегда найдется человек, который будет лихорадочно занят именно в это время. Заставляя этого человека приходить на еще одну встречу, вы рискуете поставкой того элемента бэклога, над которым идет работа.
2. По моим наблюдениям, лучше всего уделять sprint backlog grooming 5-10% усилий в каждом спринте. Хотя было бы здорово подключить к этому всю команду, на практике это для нее большая нагрузка, и не все смогут участвовать.

Как максимизировать ценность?

Увеличение ценности встречи по Scrum backlog grooming в реальности мало чем отличается от простых приемов улучшения любой встречи:  

• Встреча должна занимать минимальное время.
• К ней нужно готовиться.
• Мотивируйте всех участвовать.

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

Когда уточняете бэклог, помните, что не все его элементы (обычно в форме пользовательских историй, user stories) должны быть понятны до наименьших деталей в начале спринта. Команде стоит выработать всего лишь достаточное понимание фич, чтобы иметь серьезные шансы выполнить работу за спринт.

 

 

Можно ли сделать уточнение бэклога нескучным?

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

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

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

Сравнение Agile, Scrum, Kanban в качестве эффективных методов управления проектами

Вопросы, рассмотренные в материале:

• Какие существуют популярные системы управления проектами
• В чем преимущества и недостатки классического метода управления
• В чем плюсы и минусы Agile, Scrum, Kanban
• В чем различия между Agile, Scrum, Kanban

Определение терминов управления проектами: Agile, Scrum, Kanban

В проектном управлении существует множество методов, призванных удовлетворить любые потребности управленцев, в том числе уже упомянутые Agile, Scrum, Kanban. Если вы не запускаете космический спутник и лишены столь объемных ресурсов, вы сможете выбрать инструмент, который будет для вас самым подходящим. Нужно понять, какой из факторов играет ключевую роль в вашем случае: дедлайны, ресурсы, соблюдение процесса, ряд других характеристик. Далее вы будете отталкиваться от этого показателя при выборе одного из методов управления, созданных на основе Agile.

Нужно составить представление о некоторых терминах, перед тем как заняться сравнением Agile, Scrum, Kanban как самых популярных из существующих подходов к проектному менеджменту.

Базовые термины проектного управления:

1. Agile: гибкий итеративно-инкрементальный метод проектного менеджмента с динамическим формулированием требований, выполнение которого ведется за счет непрерывного взаимодействия рабочих групп. В последние входят специалисты разных профилей. Если проводить сравнение Agile с другими методами, становится ясно, что его идеи стали основой для множества методик, например, Scrum, Kanban.
2. Критический путь: непрерывный цикл действий, требующий самого продолжительного срока на его осуществление.
3. Событийная цепочка процессов (EPC-диаграмма): диаграмма, в которой отображается ход проектов в соответствии с доступностью ресурсов.
4. Резерв времени: промежуток времени, на который можно задержать старт работ, не влияя на срок сдачи проекта. У критического пути такого резерва нет.
5. Веха (контрольная точка, milestone): ключевое событие, которое на диаграмме Гантта выглядит как задача, не имеющая продолжительности. Вехой может считаться конец этапа.
6. Менеджер проекта (руководитель проекта, project manager, PM): управленец группы проекта, он отвечает за планирование, реализацию, закрытие проекта.
7. Ресурсы: это время, оборудование, материалы, специалисты, пр. – то есть все составляющие, без которых успешная работа не представляется возможной.
8. Содержание проекта (Scope): описание всех работ, запланированных на время осуществления проекта.
9. Спринт (Sprint): итерация (рабочий цикл) в Scrum, на которую дается неделя – месяц. За него создается рабочая версия продукта/его элемент, который можно передать заказчику.
10. «Классическое» или «традиционное» проектное управление: самый распространенный вариант управления проектами, в основе которого лежит «водопадный» (Waterfall)/каскадный цикл, где задача последовательно движется по фазам.

Далее рассмотрим ряд подходов к проектному управлению. Начнем с классического вида – Agile, после чего перейдем к сравнению Scrum и Kanban.

Топ-3 статей, которые будут полезны каждому руководителю:

Немного о классическом проектном управлении

Проще всего повысить управляемость проекта, представив его в виде последовательности этапов. Именно такая линейная структура лежит в основе традиционного проектного управления. Говоря об используемом в этом случае принципе, можно провести сравнение с игрой: вы не перейдете на новый уровень, пока не одержите победу на уже начатом.

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

5 этапов традиционного менеджмента:

Этап 1. Инициация. На совещаниях, собраниях все участники устанавливают требования к проекту. Именно на этом этапе составляется представление о результате работы.

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

Этап 3. Разработка. Во многих случаях этот этап представляет собой часть планирования. Разработка сама по себе обычно свойственна технологической области, так как позволяет выбрать конфигурацию проекта/продукта, способы его создания. Так, если речь идет о сфере информационных технологий, то выбирают язык программирования.

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

Этап 5. Мониторинг и завершение проекта. На этом шаге можно просто передать результат трудов заказчику либо вести длительное взаимодействие с клиентами по улучшению проекта – все зависит от самого проекта. Если он ведется в сфере клиентского сервиса и ПО, допускается поддержка результатов.

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

Поскольку такое проектное управление привязано ко времени исполнения задач, проекты осуществляются с использованием инструментов календарно-сетевого планирования. Обычно в ход идет знаменитая диаграмма Гантта, для ее построения и заполнения могут использоваться простые средства, такие как «Excel» и «Smartsheet», или более серьезные программы «Microsoft Project» и «Primavera».

Преимущества и недостатки классического метода управления

1. Сильные стороны классического проектного менеджмента.


Сегодня принято считать, что водопадный подход устарел, по сравнению с более современными Agile, Scrum, Kanban.Но он продолжает активно использоваться на практике. Сравнение с остальными подходами к управлению проектами позволяет увидеть главный плюс «водопадного» подхода: заказчик и руководство фирмы сразу решают, какой результат нужен в итоге. Раннее включение упрощает работу команды, а реализация проекта становится более стабильной и упорядоченной. Обязательными составляющими «водопадного» метода являются мониторинг показателей, тестирование, что необходимо для реальных проектов различного масштаба.


Теоретически, при классическом подходе, в сравнении с семейством Agile, минимизируются стрессы, ведь у исполнителей на всех этапах есть запас времени на случай осложнений, рисков. Грамотно осуществленный этап планирования позволяет руководителю представлять, каким объемом ресурсов он будет распоряжаться.

2. Слабые стороны классического проектного менеджмента.


Главная слабая черта этого подхода – невозможность реагировать на изменения. Руководство «Toyota», создавшей Lean и Kanban, часто критикуют за разработку софта для своей компании на основе этого недостаточно гибкого метода.

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

Альтернативные методы управления: сравнение Agile, Scrum, Kanban

1. Agile.

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

Избежать подобных трудностей позволяет Agile. Это семейство гибких итеративно-инкрементальных методов проектного управления. Если проводить сравнение с «водопадным» методом, отличие Agile состоит в том, что проект разбивается не на последовательные этапы, а на подпроекты. Именно из последних в дальнейшем складывается ожидаемый результат.

Инициация и планирование в Agile происходят для всего проекта, а следующие шаги, такие как разработка, тестирование, пр., проводятся для подпроектов в частности. Подобный подход Agile дает возможность быстрее поставлять заказчику результаты мини-проектов, то есть инкременты, согласно терминологии Agile. Корректировка итерации происходит без серьезных затрат, не затрагивая остальные части проекта, что является серьезным достоинством Agile по сравнению с классическим подходом.

Agile стал популярен не так давно, однако сама идея итеративной разработки существует уже долгие годы. Современное название семейство гибких методологий получило в 2001 году, после публикации Манифеста Agile («Agile Manifesto») – он зафиксировал базовые ценности и принципы гибкой разработки ПО. Основными в этом подходе стали командная работа, адаптация, готовность к изменениям.

В чистом виде Agile является не методом управления проектами, а набором идей и принципов их реализации. Все они послужили базой для создания гибких методов или фреймворков (frameworks), таких как Scrum, Kanban, Crystal, пр. Хотя сравнение последних позволяет заметить серьезные отличия между ними, подход к работе остается общим.

Сильные стороны Agile:

Специалисты в сфере проектного управления ценят Agile за адаптивность, то есть этот метод подстраивается под любые условия, процессы фирмы. Именно этим свойством объясняется количество систем в семействе Agile.

При работе с Agile нельзя забывать о его основном правиле: «Реакция на перемены важнее следования плану». Быстрая, безболезненная реакция на изменения приводит к тому, что лидеры рынка все чаще делают выбор в пользу более гибких процессов. В отличие от классического подхода, Agile может использоваться для проектов, не имеющих четкого завершения, допустим, для запуска сервиса или блога.

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

Слабые стороны Agile:

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

Работая с Agile, лидер должен проявить знания и упорство, а также от него потребуются серьезные административные ресурсы, вложения. Радует тот факт, что сегодня есть готовые наборы практик, которые упрощают Agile-трансформацию организации. В их число входят Scrum, Kanban и целый ряд других: Crystal, LeSS, SAFe, Nexus.

2. Scrum.

Гибкий фреймворк, появившийся в 1986 году. Считается, что он наиболее структурированный по сравнению со всеми остальными продуктами семейства Agile. Здесь элементы водопадного метода совмещены с гибким подходом к управлению проектами, образуя баланс гибкости и структурированности.

В соответствии с принципами Agile, Scrum делит проект на части, которые заказчик может сразу использовать для получения ценности – они называются заделами продуктов (product backlog). Хотя «задел продукта» является достаточно точным переводом английского термина и используется в профессиональной литературе, на практике его обычно заменяют словом «беклог».

Далее владелец продукта, то есть представитель заказчика в команде, определяет приоритетные составляющие проекта. Самые важные из них должны быть первыми выполнены в спринте – так называют итерации в Scrum, продолжающиеся 2–4 недели. По итогам спринта заказчик получает рабочий инкремент продукта, то есть элементы, которыми уже можно пользоваться. Это может быть сайт с частью функционала или программа, которая уже частично работает.

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

Не секрет, что требования заказчика могут изменяться с течением времени, поэтому чтобы проект точно им соответствовал, перед началом каждого спринта Scrum требует переоценки пока не выполненного содержания проекта, после чего вносятся необходимые поправки. К этому процессу привлекаются команда проекта, Scrum-мастер (Scrum Master, лидер команды) и владелец продукта, поэтому каждый из участников берет на себя часть ответственности.

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

Scrum-мастер помогает участникам разобраться и принять ценности, принципы Scrum. Это лидер, а также посредник между внешним миром и командой, поэтому он отвечает за то, чтобы специалисты могли спокойно работать над своими задачами. Сама же группа должна выполнить все задачи и поставки по итогам спринта.

Структура Scrum состоит из 5 основных встреч:

• Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): в классическом подходе есть похожий этап, но там он называется этапом планирования. В первый день спринта команда обсуждает, что уже сделано в рамках проекта, что еще нужно предпринять, принимается решение о следующем шаге. Отдельная роль отводится владельцу продукта – в Scrum он устанавливает приоритетные задачи. На первом шаге в Scrum определяют, что получит заказчик после итерации, поэтому данная встреча влияет на ее эффективность.
• Планирование спринта: владелец сделал свое дело, поэтому сразу после первой встречи команде нужно понять, как она будет идти к цели, что именно будет делать во время итерации. Выбор специалистов среди технологий планирования и оценки ограничивается только одним правилом: инструменты не могут противоречить идеям Scrum.
• Ежедневные летучки: каждый день, желательно в одно время, команда выделяет четверть часа на то, чтобы обсудить статус задач, состояние проекта. В это время не говорят о вопросах и разногласиях, такие темы прорабатываются лично со Scrum-мастером. Летучка нужна только для обмена информацией, тогда каждый специалист будет в курсе текущего состояния проекта.
• Подведение итогов спринта: теперь проводится адаптация продукта. Команде нужно представить свое детище всем заинтересованным лицам, ведь только так можно понять, выдерживает ли результат ее работы сравнение с ожиданиями участников, поставленными целями.
• Ретроспектива спринта: проходит после подведения итогов, но до планирования нового рабочего цикла. На этом этапе важно понять, насколько четко шла работа, какие были проблемы на разных ее этапах. Команда проводит сравнение, чтобы новый спринт оказался более продуктивным.

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

Сильные стороны Scrum:

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

Онлайн-телеканал «Netflix» – яркий пример быстрых поставок результатов. Каждые две недели сайт ресурса обновляется благодаря Scrum, который позволяет работать с высокой скоростью и аккумулирует пользовательский опыт, давая возможность выявить основное для клиентов. Во время каждой итерации разработчики добавляют, тестируют новые функции сайта, отказываясь от непопулярных среди клиентов.

Как говорят члены команды «Netflix», главное достоинство Scrum состоит в том, что он позволяет «быстро ошибаться». По сравнению с другими подходами к управлению, Scrum не требует долго и с большими затратами готовить крупный релиз – поставки каждые две недели имеют небольшой размер, их легко отслеживать и, при необходимости, оперативно исправлять.

Слабые стороны Scrum:

Scrum, по сравнению с другими методами из семейства Agile и вне его, выдвигает серьезные требования к команде проекта: она должна быть маленькой (5–9 человек), а у каждого члена команды должно быть более одной компетенции, необходимой в процессе выполнения проекта. Так, разработчику ПО нужны знания в тестировании и бизнес-аналитике. Подобный подход позволяет всем участникам быть задействованными на разных этапах проекта, подменять друг друга при необходимости.

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

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

3. Kanban.

Это детище инженера компании «Toyota» Тайичи Оно (Taiichi Ono), которое увидело свет в 1953 году. При сравнении Kanban с другими методами заметна его схожесть со схемой производства – в нее попадает кусочек металла, а выходит полноценная деталь. Инкремент продукта передается с этапа на этап, а в конце мы получаем готовый к поставке элемент.

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

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

Kanban требует установить этапы потока операций (workflow). Здесь их изображают в виде столбцов, задачи пишутся на отдельных карточках. Такой листочек движется по этапам, как деталь по конвейеру, а процент завершения постепенно возрастает. В итоге получается элемент продукта, который можно передать заказчику. Доска со столбцами и карточками в Kanban может быть реальной или виртуальной.

Ваша система Kanban будет настолько гибкой, насколько это вам нужно, ведь Kanban тоже входит в семейство Agile. Однако сравнение Kanban vs Agile показывает, что у первого есть четыре обязательных условия стабильности системы:

• Карточки: каждая задача в Kanban – отдельная карточка со всеми данными о ней. Это позволяет всегда держать все необходимые сведения под рукой.
• Ограничение на количество задач на этапе: число карточек жестко регламентируется, поэтому всегда становится заметен «затор», и он сразу устраняется.
• Непрерывный поток: задачи из беклога попадают в поток в соответствии с их приоритетом, за счет чего работа по Kanban идет непрерывно.
• Постоянное улучшение (кайзен (kaizen)): концепция постоянного улучшения зародилась в Японии в конце XX века. Она требует постоянного анализа процесса, поиска способов увеличения производительности.

Сильные стороны Kanban:

Если проводить сравнение Scrum vs Kanban, оба метода, созданные на основе Agile, подходят для сплоченных команд с налаженной системой взаимодействий. Но Kanban не устанавливает четких сроков завершения работ, что эффективно для опытных групп с высоким уровнем мотивации.

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

Слабые стороны Kanban:

Бытует мнение, что при сравнении Kanban и Scrum как двух представителей семейства Agile, первый выглядит более выигрышно, ведь по Kanban может работать любая команда. Однако это не так: Kanban прекрасен для групп, если их члены имеют сходные навыки, ведь тогда работники могут помогать друг другу в трудных ситуациях. В противном случае эффективность Kanban значительно снижается по сравнению с другими методами семейства Agile. Также он не терпит жестких дедлайнов. Если таковых не избежать, стоит отдать предпочтение классическому подходу либо Scrum.

Как использовать Agile и Scrum для управления проектами — руководства на Skillbox

запись вебинара

 1ч. 40 мин.

статья

 10 мин.

Экономия времени

 1ч. 30 мин.

Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.

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

Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.

Плюсы методологии:

• Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
• Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
• Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

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

Минус водопадной схемы — процессы идут друг за другом. Это замедляет разработку

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

Удобно вести бэклог задач в Trello или Excel.

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

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

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

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

Так выглядит бэклог со спринтами.

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

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

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

Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.

Команда разработки

Люди, которые непосредственно создают и тестируют код. 

К разработчикам есть несколько требований:

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

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

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

• Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
• Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

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

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

• Что сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы и препятствия для выполнения задач?

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.

Попробуйте такой шаблон для ретроспективы.

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

Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.

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

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

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

• Trello — подходит для маленьких проектов, быстро и удобно.
• Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
• Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

• Научиться вести бэклог и расставлять приоритеты.
• Проводить спринты.
• Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
• Контролировать работу с помощью диаграммы сгорания проекта.
• Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
• После каждого спринта демонстрировать проект.
• Изучить инструменты и найти самый удобный.

Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.

Курс «Руководитель digital-проектов»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Grooming in Agile — что это такое и как это происходит?

Grooming — первое из многих событий, которые происходят в методологии Agile. С точки зрения команды также важно понимать реальные требования к продукту. ПО объясняет их на уровне бизнеса, а архитекторы поднимают технические вопросы. Чем лучше и детальнее сеанс груминга, тем меньше шансов для неизвестных.

Его цель — свести требования к высокоуровневому дизайну и реальному решению.Во время подготовки Agile-команды разбивают функции на истории и разбивают их дальше. После этого они проводят оценку в сюжетных точках, и цель — получить разумную оценку. Для ЗП также важно, чтобы он мог предоставить команде достаточно работы, чтобы продолжить в следующих 3-4 спринтах.

Владелец продукта в основном организует эти занятия, поскольку он / она сначала должен рассказать на высоком уровне о функциях. Однако Scrum-мастер также может делать это от имени PO. Он мог даже сделать шаг вперед, если команде нужны внутренние улучшения продукта.Например — рефакторинг кода, исправления статического анализа кода, увеличение покрытия кода и т. Д.

Подготовка в Agile-командах

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

Обработка / корректировка бэклога

Мы также можем называть уход за телом изысканностью. Это один из основных шагов в Agile Scrum. PO делает это, чтобы поддерживать отставание и генерировать работу для следующих спринтов.

Это задание, в ходе которого ЗП и члены команды обсуждают вопросы, лежащие в очереди.

Цель обработки отставания:

• Отфильтруйте отставание, чтобы убедиться, что в нем есть соответствующие элементы.
• Назначьте приоритет присутствующим элементам.
• Обсудите каждый пункт подробно, получите достаточно ясности с точки зрения тестирования / разработки.

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

Приоритет отставания по продукту

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

Refining обеспечивает доступность адекватной информации для разбивки задач на подзадачи. При правильном понимании SM может составить план выпуска и предложить свои обязательства.

Преимущества ухода

Уточнение бэклога продукта

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

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

Заказчик

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

Подробнее

Мы хотим, чтобы в приведенной выше статье у вас была правильная информация для понимания идеи Grooming в Agile Scrum. Если вы планируете работать в Agile-модели, то знать эти термины обязательно.

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

.

Что такое обработка / корректировка бэклога?

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

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

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

Целью уточнения невыполненной работы является обеспечение того, чтобы она оставалась заполненной элементами, которые актуальны, детализированы и оцениваются в степени, соответствующей их приоритету, и в соответствии с текущим пониманием проекта или продукта и его целей.В отличие от более формального «документа требований», отставание понимается как динамический массив информации. Например, не все пользовательские истории должны быть разбиты на детальный уровень в начале проекта или давать подробные оценки; но важно, чтобы в любой момент было готово «достаточное» количество историй для планирования следующих нескольких итераций. Agile-проект не меньше, чем любой другой, подвержен «расширению масштабов» в виде пользовательских историй, которые на самом деле не приносят существенной ценности, но в то время считались «хорошими идеями» и заносились в журнал отставания, чтобы они не были забыли.В отсутствие явных усилий, направленных на управление этой инфляцией, эта инфляция привела бы к слишком хорошо известным патологиям графика и перерасхода бюджета.

.

Бизнес-аналитик | Подготовка к успеху Agile Backlogs

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

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

• Утомительно длинные встречи по планированию спринта
• При разработке дизайна мало что думали
• Плохое планирование и исполнение
• Отсутствие креативности при решении бизнес-задач
• Плохое прогнозирование

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

Бэклог продукта и контрольный список «Качество»

1. Скрам-мастер облегчает встречу по уходу; не Владелец продукта, управляющий всем. Основные роли Scrum прекрасно подходят для игры…

1. 1. Scrum Master в качестве фасилитатора; руководство по процессу; тренер
   2. Product Owner как потребности бизнеса и движущая сила; определение того, что, а НЕ как (дизайн) или как долго (время)

   Команда

   3. участвует в качестве партнера Владельца продукта в эволюции бэклога продукта в реальном времени.

2. Длина бэклога — бэклог должен содержать достаточно подробных элементов, чтобы развлечь вашу команду перед выпуском; используя командную скорость и ваш темп релиза как множитель.И достаточно эпических предметов, чтобы разместить 2 релиза. (однако вы определяете «выпуск» в контексте вашей организации)

1. 1. Еще одно практическое правило — нацелить / ограничить бэклог где-то между 50–100 пользовательскими историями
   2. У каждого элемента невыполненной работы должен быть четкий, продуманный приоритет — заказ

3. Уход — проводите встречи по уходу 2 раза в неделю. Помните о 10% -ном руководстве по инвестициям, предоставленном Schwaber — так что 4 часа на члена команды (индивидуально и на встречах) за спринт-неделю

1. 1. Еще одно правило — проводить итеративное изучение каждой пользовательской истории с командами как минимум 4 раза перед выполнением спринта.

1. 1. 1. Как эпос высокого уровня; как минимум выпуск до исполнения
      2. Как рассказ или набор историй за 3-4 спринта до казни
      3. Как рассказ 1-2 спринта от казни
      4. Как рассказ прямо перед исполнение

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

1. 1. Обсуждение раннего дизайна
   2. Определение рабочего процесса и разбивки истории
   3. Выявление проблем и рисков

и всегда оставляйте достаточно рабочих заметок в рассказе или в вики.Обычно я фиксирую это как ШИП. Помните о шипах две вещи:

1. 1. Вам следует разумно использовать Spike Stories как способ вовлечь вашу команду в переработку сложных эпических произведений в содержательные истории и рабочий процесс. Я бы сказал, что около 20% пользовательских историй являются кандидатами на спайки. Не теряйте их!
   2. Шипы должны запускаться в спринте до спринта, в котором вы нацелены на их выполнение. Это поощряет команду смотреть в будущее.

5. Бэклог продукта должен быть изначально установлен в приоритетном порядке и всегда переупорядочиваться по приоритету владельцем продукта. Порядок может быть изменен, но он также должен быть стабильным — отражать осведомленность Владельца продукта о рынке / потребителях в целях удовлетворения потребностей бизнеса и обеспечения уверенности команды. Так что не взбивайте бэклог постоянно, так как это снижает уверенность команды.

6. Совещания по подготовке сосредоточены на 3 уровнях бэклога

1. 1. Epic-Stories: разбивка более крупных эпосов на части; оценка их размера, сложности и определение приоритета / рабочего процесса; наверное, не более чем за два релиза заранее.
   2. Среднесрочные истории: рассказы о груминге, которые находятся на расстоянии 2-3 спринтов от исполнения. Команда начинает думать о дизайне; эффективность исполнения,
   3. Краткосрочные истории: подготовка историй «прямо перед» их целевым спринтом.

7. Выполните комплексное блиц-планирование как средство получения обратной связи от команды о рабочем процессе. Я считаю, что часто проводить блиц-планирование полезно. Например, несколько раз перед твердо запланированным релизом. Вы также можете сделать это в середине одного выпуска, чтобы заранее оценить возможности содержимого в следующем выпуске.Не бойтесь часто выполнять эти сквозные просмотры вместе со своей командой!

8. Выделяйте время на исправление ошибок в каждом спринте! Даже если вы настроите их как «растянутые истории» для команды … выделите время как пользовательские истории с намерением и критериями приемлемости.

9. Выделите время для периодов упрочнения и тестирования на спринт. Это истории пользователей, которые особенно полезны при планировании блиц. У них должны быть критерии приемки, ориентированные на то, чтобы направлять команду к LOE, необходимому для достижения Готовности.

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

Каковы некоторые «запахи» ухоженного отставания?

1. Планирование спринта невероятно четкое, короткое и легкое; Обычно на двухнедельный спринт уходит 2 часа или меньше.Во время встречи НЕТ обсуждений архитектуры или дизайна — соответствующие части этих обсуждений произошли ранее.

2. Члены команды говорят об эпиках и историях, нацеленных на спринты 2–3–4 спринта в будущем — почти ежедневно в течение каждого спринта и вполне естественно совпадают с видением владельцев продуктов.

3. Команда легко добавляет новые истории в Backlog, чтобы представить работу, не основанную на функциях; например: артефакты тестирования, нефункциональные работы по тестированию, рефакторинг, разработка автоматизации, настройка производительности, SPIKE и т. д.Они рассматривают это как общую ответственность.

4. Команда имеет представление о долгосрочной перспективе продукта и намечает усилия, дизайн, предложения тем и компромиссы для достижения этого видения.

5. Цель каждого спринта легко выводится из бэклога; то есть есть смысл продуманных и значимых тем, которые легко всплывают из Backlog. Иногда их можно представить как «пакеты».

6. Владелец продукта включает отзывы команды (ошибки, рефакторинг, улучшение, тестирование и т. Д.)) в КАЖДОМ спринте — в некотором процентном соотношении. Они ясно демонстрируют веру команды в их отзывы, суждения и технические мнения.

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

8. Блиц-планирование выполняется каждые 2-3 недели не только как инструмент планирования, но и как инструмент риска / корректировки.Для пользователей XP рассмотрите планирование выпуска как аналогичное упражнение. Дело в том, что сквозное планирование следующей вехи выпуска происходит довольно часто.

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

10. Бэклог соотносится с навыками и способностями команд, расширяя их — да, но не прося их делать то, что они не могут сделать ни по навыкам, ни по опыту.

11. В каждом спринте Владелец продукта вносит микро корректировки в объем работ на основе взаимодействия с командой. Всегда — ищу этот минимальный рыночный набор функций!

12. Команда никогда не удивляется планированию спринтов. Ни даже одной историей. Я знаю, перемены должны произойти, но удивлять команду изменениями в последнюю минуту… это не так! Скорее — дождитесь следующего спринта.

13. Команда считает, что у них есть право голоса в том, что находится в очереди, и в распределении функций по сравнению спредметы улучшения. Но они не могут быть ограниченными в своих взглядах. Им необходимо составить экономическое обоснование из точки зрения клиентов на всю нефункциональную работу, введенную в Backlog. И делают это охотно и хорошо!

Надеюсь, вы найдете руководство полезным…

Боб.

Не забудьте оставить свои комментарии ниже.

.

Распределенная Agile: встречи по обработке бэклогов

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

Есть две причины проводить встречи по устранению отставания. Первый — сделать планирование спринта более эффективным и действенным. Вторая причина — убедиться, что вы понимаете свое отставание. Когда команды не тратят время, необходимое для устранения отставания, совещания по планированию могут быть очень напряженными и затянуться на несколько часов.. . и часы. Сеансы обработки бэклога могут быть мероприятиями всей команды (редко) или действиями подгруппы (чаще). Наиболее распространенный метод, используемый для создания подгруппы по уходу, — это «Три амиго» (или какой-то его вариант). Самым высоким препятствием для всех распределенных команд является обеспечение эффективных коммуникаций, за которым следует быстрое сосредоточение внимания на текущей задаче. Многие из тех методов, которые мы обсуждали для планирования спринтов в распределенных командах, будут эффективными, однако обработка бэклога имеет несколько уникальных особенностей.

1. Каждый должен всегда видеть историю. Все участники должны иметь возможность видеть, как обрабатывается история, желательно во время редактирования. Многим людям сложно осмыслить рассказ, прочитав рассказ кому-то на другом конце телефона, а затем изменив прочтение, пока вы пишете высказывание. В большинстве инструментов веб-семинаров теперь есть параметры доски. Вырежьте и вставьте историю и критерии приемки на интерактивную доску, чтобы все могли видеть слова. Одна команда, с которой я недавно работал, использовала программное обеспечение для обмена сообщениями, чтобы приблизиться к процессу (оно работало довольно хорошо).Можно использовать такие инструменты, как веб-камеры и телеприсутствие, однако убедитесь, что история и критерии приемлемости легко читаются всеми сторонами. Когда член команды не может слышать или видеть достаточно хорошо, чтобы оставаться вовлеченным, он теряет концентрацию и, вероятно, начинает писать электронную почту.
2. Необходимо привлечь нужных людей и нужные места. Есть много оттенков распределенных команд, от двух до полностью рассредоточенных (все в разных местах). Цель очистки — убедиться, что элементы невыполненной работы, которые могут быть использованы в следующем спринте, понятны, правильно сформированы и соответствуют критериям приемлемости.Как правило, подготовка наиболее эффективна, когда задействованы три основные группы участников: бизнес, разработчики и тестировщики. Когда команда распределяется, местоположения могут стать группами, которые необходимо вовлечь, чтобы гарантировать, что сеанс груминга достигнет цели — убедиться, что истории понятны. Это аргумент в пользу тренировок всей команды, чтобы ни одно место не оставалось обделенным.
3. Используйте карты-истории, чтобы связать истории в общую картину. Понимание того, как история или группа рассказов вписывается в общую картину, иногда похоже на чтение одной строчки Шекспира и попытку развить сюжет для всей пьесы.Когда команда распределена, участникам становится все труднее вести сторонний разговор, чтобы вернуть вещи в нужное русло или разработать способы оставаться в соответствии с общей картиной проекта без более формальной ссылки. Карта-история представляет собой систему отсчета, чтобы члены команды, участвующие в сеансе подготовки, могли видеть, как истории вписываются в общий проект. Использование карты-истории в процессе подготовки упрощает определение или разработку темы для следующего спринта (тема обеспечивает фокус и направление для команды).

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

Нравится:

Нравится Загрузка…

Связанные

.

No related posts.