S(crum)-Light – Понятный путь управления проектами

За один элемент бэклога ответственный один участник команды разработки.

Оценку элементов бэклога делают сотрудники, которые причастны к его реализации и/или понимают специфику разработки этого элемента. Рекомендуется, что Front-End задачи оценивались Front-End разработчиками, Back-End разработчики оценивали свои задачи, дизайнеры – свои и так далее.

Если команда дошла до стадии, когда работа планируется спринтами, то бэклог разделяется на две части:

• бэклог продукта или проекта

• бэклог спринта

Бэклог спринта

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

Инкремент

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

Инкремент может быть создан после выполнения и доставки на продакшен:

1) Новой Feature;

2) Завершенной User Story;

3) Устранение бага (когда баг блокировал работу какой-то функциональности);

4) Завершение задачи (task), которая не подразумевает создание новой функциональности (например подключение новой библиотеки или новой версии базы данных).

Каждый поставленный Инкремент должен быть шагом к достижению цели продукта или проекта.

Рекомендуется определить командой Definition of Done для инкремента: набор признаков, когда элементы(ы) бэклога превращаются в инкремент доставленный на продакшен.

1. Definition of Ready (DoR) – критерий готовности задачи к тому, чтобы взять ее в работу. DoR будет одинаковым для всех задач. Для этого на старте надо договориться, что именно должно быть в задаче, чтобы ее можно было реализовать. К примеру: задача имеет описание, критерии приемки (АС), ответственного, оценку, связь с другими задачами, ссылка на документацию, макет UI.

2. Definition of Done (DoD) – критерий выполнения задачи. DoR одинаков для всех задач. Для этого нужно договориться, в каком случае мы считаем, что задача полностью выполнена. К примеру: разработка завершена, проведены все виды тестирования, выполнена поставка на продакшен, описание дополнено в документации.

3. Acceptance Criteria (AC)

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

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

Спринты

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

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

Команда

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

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

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

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

РМ

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

РО