Litvek - онлайн библиотека >> Юрий Недре и др. >> Справочники и др. >> S(crum)-Light – Понятный путь управления проектами >> страница 2
составляются в виде чек-листа к задаче. АС должны быть прописаны так, чтобы были понятны, как разработчикам, так и тестировщикам и чтобы не было их двойного толкования.

DoR и DoD могут быть свои в каждой команде, (их можно устанавливать единые критерии на всю компанию, если это применимо)

Спринты

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

Рекомендуется иметь длину спринтов в две недели. На бо́льшей дистанции у команды может размываться фокус цели спринта и чем дольше спринт, тем сложнее его планировать. Спринты короче чем две недели, приведут к частому повторению всех церемоний спринта. Спринт может быть отменен руководителем команды (РО/РМ/TL или другой сотрудник, выполняющий обязанности руководителя продукта/проекта), но только при существенном изменении планов (к примеру, со стороны бизнеса) или после совещания с командой.

Команда

S(crum)-Light – Понятный путь управления проектами. Иллюстрация № 3

Разработчики

Разработчики – минимальная необходимая роль для старта работы в S-Light. Работа может начаться, даже если в команде будут только одни разработчики. Они сами устанавливают себе приоритеты задач, сами определяют формат разработки, встречи (кроме Daily – они обязательны), артефакты (кроме Списка задач – они обязательны).

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

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

РМ

Менеджер проекта – участник команды, который осуществляет координацию ведения продукта. Его задачей является помощь команде в достижении целей и устранении препятствий на пути к ней. Он является входным звеном потока информации извне (требования заказчиков, изменения обстоятельств) к команде разработки. Он может принимать ключевые решения в отсутствии других руководителей. Главная цель работы – выстроить процессы внутри команды разработки, чтобы сотрудники могли работать автономно.

РО

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

Церемонии

S(crum)-Light – Понятный путь управления проектами. Иллюстрация № 4

Дейли

Единственная обязательная церемония в S-Light.

Цель – понять что блокирует команду, обновить данные которые появились за вчера.

На ней собирается вся команда (разработчики), PO/PM по возможности (но очень желательно)

Формат – выбрать можно любой который захочет команда, можно начать с нашего примера.

Продолжительность – 15 минут. 2 минуты на выступление.

Изначально каждый участник отвечает на 3 вопроса:

Что сделал за вчера?

Что будет делать сегодня?

Какие есть проблемы?

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

• встречи и что на них обсудили

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

Рекомендации:

1. Митинг всегда в одно и тоже время;

2. Минимум через 30 минут после начала рабочего дня;

3. Если не успеваете в тайминг, то можно проводить стоя;

4. Не перебиваем участников, поднимаем руки;

5. Не дольше 15 минут весь дейлик.

Планирование спринта

Разделим планирование на 2 части – Груминг и Планирование спринта

Груминг бэклога

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

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

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

Что мы делаем во время груминга?

• Написание новых пользовательских историй и задач;

• Удаление неактуальных пользовательских историй и задач;

• Переоценка приоритетов для пользовательских историй и задач;

• Добавление новых функций, определение приоритетов;

• Усовершенствование и изменение приоритетов ранее описанных пользовательских историй и задач;

• Разбивка некоторых пользовательских историй и задач на более мелкие;

• Пересмотр критериев тестирования.

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

• Когда задач вверху бэклога достаточно для 2–3 спринтов;

• Пользовательские истории понятны всем членам команды;

• Пользовательские истории и задачи имеют размер, позволяющий реализовать несколько из них за один спринт.

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

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


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

• Устраняет неопределенность и неизвестные факты в задачах что несомненно повышают эффективность продукта;

• Помогает избежать “переделок” в разработке и тестировании;

• Идентифицирует зависимости в команде и помогает прогнозировать риски;

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

• Успешный груминг приводит к эффективному планированию спринта.

Планирование