Skip to content

Чек-лист на утверждение спринта

Утверждение спринта

После сдачи спринта заказчику, сотрудник должен назначить встречу с head’ом, на которой должен продемонстрировать:

Длительность спринта

Спринт длился не более 14 дней (исключения: праздники, когда вся компания не работает; сдача переносится по вине заказчика) Следующий спринт стартует на следующий день, после сдачи предыдущего

Project Report

  • Лист “Synopsis” должен содержать актуальные данные (номер спринта, даты старта/окончания, ссылки на все материалы, актуальный состав команды)

  • Лист “Roadmap” - заполнен план/факт утверждаемого спринта, расхождение между планом и фактом не более 10-15%. Заполнен план на следующий спринт

  • Лист “Tasks” - проставлены актуальные статусы у задач утверждаемого спринта, расписаны задачи на след. спринт

  • Лист “Pages” - заполнен актуальными данными, на предстоящий спринт, в соответствии с шаблоном

  • Лист “Models’ directory” - заполнен актуальными данными, на предстоящий спринт, в соответствии с шаблоном

  • Лист “Tests” - заполнен тест-кейсами на весь реализованный и планируемый к реализации на ближайший спринт функционал

  • Лист “Roles” - заполнен актуальными ролями, которые реализованы/будут реализованы в продукте

  • Лист “Payments” - проставлены актуальные суммы, итоговая сумма сходится с суммой на листе “Roadmap”, верно проставлены все head’ы, в таблице с историей выплат проставлены суммы и даты

Также, важно обратить внимание на актуальность самого Project Report - состояние инструмента должно быть идентично шаблону

Project Report Out

  • Не нарушено наследование из Project Report

  • Создана копия листа, перед сдачей заказчику, с информацией по утверждаемому спринту. В названии листа обязательно содержится номер спринта и дата закрытия. Наследование отсутствует.

Также, важно обратить внимание на актуальность самого Project Report Out - состояние инструмента должно быть идентично шаблону

FigJam

  • Выбрать любую cjm/sjm, реализованную в утверждаемом спринте, рассмотреть и оценить реализацию в соответствии с регламентом (в случае допуска ошибок - обязательно указать на них и проверить исправление при утверждении следующего спринта)

  • Все комментарии на cjm, которые лежат в секции “Утверждено”, должны быть закрыты

Leantime

  • На доске утверждаемого спринта все задачи должны находиться в столбце “Done”/”Утверждено”

  • На доске предстоящего спринта должны быть расписаны все задачи. К задачам, которые направлены на реализацию функционала продукта (design, frontend, backend, qa) в описании должны быть приложены cjm/sjm, на которые нужно ориентироваться исполнителям.

Описание проекта

  • Не нарушена стилистика, документ соответствует формату оформления

  • Присутствует актуальное описание (описаны все технологии и модули, реализованные на момент сдачи спринта заказчику)

  • Приложены все резюме встреч с подтверждающей реакцией/сообщением от заказчика, с которым заключен договор

GitLab

  • Весь код слит на stage-контур перед сдачей спринта заказчику

  • После сдачи спринта заказчику, stage слит в main. Если на main существуют реальные пользователи, убедиться в его работоспособности и сделать акцент для PM’а на повышенном внимании и ответственности при работе с prod’ом.

  • README.md должен быть заполнен информацией о проекте (краткое описание, правила запуска и развертки)

  • Актуальное состояние веток (устаревшие ветки должны быть удалены)

  • С помощью repository graph проверить соблюдение пути кода (dev → test → stage → main)

После проверки всех инструментов, PM должен попросить балл за сданный спринт. Пока head не поставил балл - спринт не утвержден.

Далее, PM должен назначить встречу с тех. директором, на которой нужно утвердить смету по спринту на листе “Payments” в project report. Если спринт был закрыт в 0, встречу назначать не нужно - в текстовой форме уведомляем тех. директора: на каком проекте, какой спринт вышел в 0.

Критерии оценивания

Идеально сданный спринт

  • Все инструменты и материалы соответствуют описанию. Допускаются минимальные погрешности (например, не проставлен актуальный статус у 1 задачи на листе “Tasks” в project report, не удалена 1 устаревшая ветка в gitlab, неактуальное оглавление в описании проекта)

  • Отсутствуют критические ошибки ведения проекта

  • Не было привлечено руководство для решения острых вопросов с заказчиком (вопрос решен)

  • PM получает 0,5 балла в личный рейтинг

Сданный спринт

  • Допущены ошибки в 2-3 инструментах (например, после сдачи спринта, задачи в leantime не перенесены в столбец “Done”, сломана формула в project report, отсутствует резюме последней встречи с заказчиком)

  • Допущены 1-2 критические ошибки ведения проекта (например, расхождение между планом и фактом более 20%, не утвержден план работ с заказчиком на следующий спринт)

  • Было привлечено руководство для решения острых вопросов с заказчиком (вопрос решен)

  • PM получает 0,2 балла в личный рейтинг

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

Несданный спринт

  • Допущены ошибки в 4 и более инструментах

  • Допущено больше 2 критических ошибок в ведении проекта

  • Было привлечено руководство для решения острых вопросов с заказчиком (проект на грани закрытия)

  • PM получает “-1” балл в личный рейтинг

В случае, если спринт не сдан:

  • PM готовит план “улучшений” на следующий спринт и утверждает с head’ом

  • Поднимается обсуждение на собрании отдела (pm рассказывает подробности, демонстрирует свой план “улучшений”, проводится анализ и рефлексия совместно с коллегами и head’ом)

  • Head присутствует на основных этапах ближайшего спринта (процент head’а на ближайший спринт повышается на размер до 40%):

    • На старте, при распределении и постановке задач

    • В середине спринта, для контроля ведения всех инструментов и отслеживания прогресса выполнения работ

    • На подготовке к сдаче. В данной ситуации, PM утверждает спринт с head’ом до сдачи заказчику

    • На встрече с заказчиком при сдаче спринта