Как мы управляем разработкой ИТ-проектов в период неопределенности

Делимся с вами самым любимым и эффективным методом управления командой в наших проектах!

Содержание:

управление командой


Скрамус Фреймворкус!

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

Применяется на 99% проектов CodeInside!

Scrum — это гибкий и структурированный метод управления проектами, основанный на принципах Agile:

  • Люди важнее инструментов
  • Качество продукта важнее подробной документации
  • Взаимодействие с заказчиком важнее обсуждения деталей договора
  • Реакция на изменения важнее следования плану

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


Нам понадобится

Как мы говорили ранее, в Scrum все роли и процессы чётко прописаны.
Основные категории Scrum – это команда, события, артефакты и метрики.

Давайте ознакомимся с категориями, их составляющими и основными терминами.

Scrum-команда

  • Кросс-функциональная команда под задачи проекта с высокой квалификацией специалистов
  • Scrum-мастер – координатор команды. У нас эту роль исполняет проектный менеджер

Scrum-события

  • Спринт (sprint) – отведенное время на разработку одной итерации продукта, готовой для запуска.
  • Ежедневные митинги (daily meeting) – короткие встречи команды по промежуточному результату. На них обсуждается всего 3 вопроса: «Что сделано за предыдущий день?», «Что запланировано сегодня?», «Какие проблемы мешают достижению целей спринта?».
  • Обзор спринта (sprint review meeting) — подведение итогов спринта, демонстрация итерации продукта для владельца продукта (product owner) или заказчика.
  • Ретроспектива — подведение итогов спринта внутри команды, что было сделано хорошо, что требуется улучшить в следующем спринте.

Scrum-артефакты

  • Беклог продукта (product backlog) — перечень требований к продукту от владельца продукта или заказчика
  • Шаблон сценария (user story) — задачи бэклога и спринта, коротко сформулированные на повседневном или деловом языке пользователя
  • Критерии подготовленности (definition of ready) требований в бэглоге до планирования итерации
  • Критерии готовности (definition of done) итерации продукта в соответствие с общей идеей продукта
  • Покер планирование (Planning poker) — технология коллективной оценки трудоемкости задач
  • Бэклог спринта (sprint backlog) — максимальное количество задач в спринте
  • Итерация продукта — версия продукта по окончанию спринта, готовая к запуску.

Scrum-метрики

 

  • Скорость (velocity) – среднее количество задач, которое команда выполняет в спринт
  • Емкость (capacity) — доступное время команды
  • Диаграмма сгорания задач, показывающая количество завершенных
    и оставшихся задач
  • Накопительная диаграмма потока, отражающая количество завершенных задач, задач в работе и оставшихся в очереди. Диаграмма показывает «здоровье» проекта, то есть отражает загрузку команды и заторы в работе на момент времени.

Как работает?

Наглядная иллюстрация процесса, построенного по методу Scrum

Этапы работы

Разработка ведется спринтами — периодами в 2-4 недели. Здесь подсвечивается особенность Scrum – возможность корректировать предыдущие этапы и оперативно реагировать на изменения в процессе разработки.

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

Идеально для BANI-мира с горизонтом планирования в 10 минут ?

Установление курса

В Scrum нет техзадания, команда руководствуется бэклогом.

Поэтому перед каждым спринтом проходит уточнение и упорядочивание бэклога продукта (refinement). Ее проводит бизнес-заказчик где определяет приоритетные функции продукта, которые команда берет в разработку на спринт. В это же время формируется бэклог спринта.

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

Процесс

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

Результат

В конце каждого спринта проводится обзор спринта (sprint review meeting), где принимают участие все члены команды и демонстрируют текущую итерацию продукта бизнес-заказчику. После чего внутри команды проходит ретроспектива.


Эффект

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

Будьте осторожны! Побочка!

Если вы хотите внедрить Scrum в свою команду, помните: малая натренированность может повлечь за собой побочные эффекты!

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

И напоследок

Scrum, где фокус направлен на четкую детализацию и многократную итерацию системы, точно не подойдёт для конвейера, проектов с фиксированными сроками, стоимостью и 100% предварительным видением результата.

Именно поэтому в числе наших проектов есть 1%, с которым мы работаем иначе. Но это уже совсем другая история ?

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

Поработаем вместе? Ждем ваше письмо у нас на почте request@codeinside.ru .

А если вы жаждете интересных проектов со сложным решением, ваше резюме просто обязано прилететь на job@codeinside.ru <3


МЫ
НА СВЯЗИ

для СМИ и партнеров

pr@codeinside.ru