критерии на всю компанию, если это применимо)
Спринты – это повторяющийся временной интервал для выполнения запланированного объема работы. У спринта должна быть цель. Цель формирует и разъясняет команде владелец продукта, менеджер проекта или старший разработчик (тимлид) или другой сотрудник, выполняющий обязанности руководителя продукта или проекта. Все спринты имеют одинаковую длину. Новый спринт стартует сразу по завершению предыдущего спринта. Все события происходят внутри спринта.
Рекомендуется иметь длину спринтов в две недели. На бо́льшей дистанции у команды может размываться фокус цели спринта и чем дольше спринт, тем сложнее его планировать. Спринты короче чем две недели, приведут к частому повторению всех церемоний спринта. Спринт может быть отменен руководителем команды (РО/РМ/TL или другой сотрудник, выполняющий обязанности руководителя продукта/проекта), но только при существенном изменении планов (к примеру, со стороны бизнеса) или после совещания с командой.
Разработчики – минимальная необходимая роль для старта работы в S-Light. Работа может начаться, даже если в команде будут только одни разработчики. Они сами устанавливают себе приоритеты задач, сами определяют формат разработки, встречи (кроме Daily – они обязательны), артефакты (кроме Списка задач – они обязательны).
Под разработчиками понимается кросс-функциональная команда, которая занимается аналитикой, архитектурой, разработкой, тестированием и выкаткой на продакшен окружение.
Команда может быть, как полностью кросс-функциональной (каждый участник может выполнить весь цикл разработки (от описания до выкатки) самостоятельно), так и полностью распределенной (каждый участник выполняет свою часть работы).
Менеджер проекта – участник команды, который осуществляет координацию ведения продукта. Его задачей является помощь команде в достижении целей и устранении препятствий на пути к ней. Он является входным звеном потока информации извне (требования заказчиков, изменения обстоятельств) к команде разработки. Он может принимать ключевые решения в отсутствии других руководителей. Главная цель работы – выстроить процессы внутри команды разработки, чтобы сотрудники могли работать автономно.
Является ответственным за обеспечение достижения целей продукта. Он приоритезирует список задач и доносит их смысл до команды разработки. Он говорит команде ЧТО делать, но не говорит КАК делать.
Единственная обязательная церемония в S-Light.
Цель – понять что блокирует команду, обновить данные которые появились за вчера.
На ней собирается вся команда (разработчики), PO/PM по возможности (но очень желательно)
Формат – выбрать можно любой который захочет команда, можно начать с нашего примера.
Продолжительность – 15 минут. 2 минуты на выступление.
Изначально каждый участник отвечает на 3 вопроса:
Что сделал за вчера?
Что будет делать сегодня?
Какие есть проблемы?
Если в команде уже настроена доска задач и участники хорошо с ней работают (всегда актуальные статусы и приоритеты), то можно оставить только последний вопрос. Так же данный митинг можно использовать для рассказа о прошедших событиях, которые не отображены на доске:
• встречи и что на них обсудили
• новые договоренности или вводные по продукту которые меняют изначальные задачи
Рекомендации:
1. Митинг всегда в одно и тоже время;
2. Минимум через 30 минут после начала рабочего дня;
3. Если не успеваете в тайминг, то можно проводить стоя;
4. Не перебиваем участников, поднимаем руки;
5. Не дольше 15 минут весь дейлик.
Разделим планирование на 2 части – Груминг и Планирование спринта
Груминг – это собрание представителей команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.
Этот процесс необходим для того, чтобы задачи, представленные в бэклогебыли актуальными, а те, которые представлены в верхней части списка, были готовы к планированию в спринте, реализации и релизу.
Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.
Что мы делаем во время груминга?
• Написание новых пользовательских историй и задач;
• Удаление неактуальных пользовательских историй и задач;
• Переоценка приоритетов для пользовательских историй и задач;
• Добавление новых функций, определение приоритетов;
• Усовершенствование и изменение приоритетов ранее описанных пользовательских историй и задач;
• Разбивка некоторых пользовательских историй и задач на более мелкие;
• Пересмотр критериев тестирования.
Результат хорошего груминга
• Когда задач вверху бэклога достаточно для 2–3 спринтов;
• Пользовательские истории понятны всем членам команды;
• Пользовательские истории и задачи имеют размер, позволяющий реализовать несколько из них за один спринт.
Важно помнить, что груминг должен стать постоянным событием в управлении продуктом, которым не стоит пренебрегать. Этот процесс – норма для качественного развития продукта. Самое главное в нем – оптимизировать задачи бэклога для последующей работы с ними.
Груминг бэклога помогает прояснять релевантность задач, представленных в бэклоге, анализировать существующие вопросы и получать дополнительную информацию о задачах, которые пока не до конца ясны.
Подытоживая, отметим основные преимущества груминга:
• Устраняет неопределенность и неизвестные факты в задачах что несомненно повышают эффективность продукта;
• Помогает избежать “переделок” в разработке и тестировании;
• Идентифицирует зависимости в команде и помогает прогнозировать риски;
• Постоянные проведение экономит время команды разработчиков для дальнейшего обсуждения во время цикла спринта, потому что обеспечивает ясность для разработчиков и тестировщиков;
• Успешный груминг приводит к эффективному планированию спринта.
Планирование инициирует спринт, планируя работу, которую необходимо выполнить в этом спринте. Результатом события становится план, созданный совместными усилиями всей командой.
РО (или другой руководитель) обеспечивает готовность всех участников к обсуждению наиболее важных элементов бэклога и их связи с целью продукта/проекта. Команда может приглашать на планирование для консультаций и других людей.
В ходе планирование спринта рассматриваются следующие темы:
Почему этот спринт ценен? РО (или другой руководитель) предлагает, как можно повысить ценность и практичность продукта в текущем спринте. Затем вся команда совместно определяет цель спринта, которая объясняет, почему спринт ценен. Цель спринта должна быть сформулирована до окончания планирования.
Результат хорошего планирования
• Все задачи в бэклог спринта оценены;
• Поставлена цель спринта и все участники с ней согласны;
• В спринт взяли оптимальное кол-во задач с учетом скорости команды.
Цель Демо – показать стейкхолдерам, реализованный за спринт функционал, собрать обратную связь и свериться с ожиданиями.
Придать команде дополнительную мотивацию, после благодарности от стейкхолдеров или вместе принять доработки.
