Как мы управляем разработкой ИТ-проектов в период неопределенности?
Разработка крутого ПО – это всегда про слаженную командную работу.
Как действуют наши проджекты-волшебники, чтобы взаимодействие внутри команды всегда приносило высокий результат?
Особенно в период турбулентности?
Используют заклинание! Шутим :)
Делимся с вами самым любимым и эффективным методом управления командой в наших проектах.
Скрамус Фреймворкус!
Этот метод слаживает специалистов разной экспертизы ради единой цели — разработки продукта. Подходит для проектов со сложной структурой и необходимостью в оперативной реакции на изменения.
Применяется на 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) — доступное время команды
- Диаграмма сгорания задач, показывающая количество завершенных
и оставшихся задач - Накопительная диаграмма потока, отражающая количество завершенных задач, задач в работе и оставшихся в очереди. Диаграмма показывает "здоровье" проекта, то есть отражает загрузку команды и заторы в работе на момент времени.
Как работает?
Этапы работы
Разработка ведется спринтами — периодами в 2-4 недели. Здесь подсвечивается особенность Scrum – возможность корректировать предыдущие этапы и оперативно реагировать на изменения в процессе разработки.
Промежуточные результаты постоянно оцениваются, а на основе оценки принимается решение о дальнейших задачах.
Идеально для BANI-мира с горизонтом планирования в 10 минут :)
Установление курса
В Scrum нет техзадания, команда руководствуется бэклогом.
Поэтому перед каждым спринтом проходит уточнение и упорядочивание бэклога продукта (refinement). Ее проводит бизнес-заказчик где определяет приоритетные функции продукта, которые команда берет в разработку на спринт. В это же время формируется бэклог спринта.
После приоритезации задач определяются критерии готовности промежуточного продукта. Именно по ним будет происходить соответствие промежуточного результата по итогу спринта с желаемым конечным продуктом.
Процесс
Бизнес-заказчик участвует в процессе ничуть ни меньше остальных — он подключается и к планированию, и к постоянной оценке промежуточных результатов. Только так команда может получать полноценную обратную связь и не сбиваться с намеченного курса.
Результат
В конце каждого спринта проводится обзор спринта (sprint review meeting), где принимают участие все члены команды и демонстрируют текущую итерацию продукта бизнес-заказчику. После чего внутри команды проходит ретроспектива.
Эффект
- Прозрачность процесса как для заказчика, так и для всех членов команды
- Возможность быстрого запуска проекта с наиболее приоритетными функциями и последующее наращивание функций
- Ежедневный контроль над ходом работ и более гибкий контроль
над бюджетом проекта - Высокая вероятность успеха разработки благодаря частой обратной связи
от заказчика продукта - Возможность вносить коррективы в разработку по ходу реализации проекта
Будьте осторожны! Побочка!
Если вы хотите внедрить Scrum в свою команду, помните: малая натренированность может повлечь за собой побочные эффекты!
Большое количество совещаний. Важно, чтобы команда успевала выполнять запланированную работу. Совещания четко по повестке, без затянутости
Может появиться необходимость в пересмотре части команды. Scrum требует от команды кросс-функциональность с высокой квалификацией. Это нужно учесть при внедрении изменений в жизнь команды
Сложности при заключении договоров в связи с отсутствием информации о полной стоимости проекта. Ориентируйте клиента по стоимости часа разработки и предоставьте предварительную оценку задач
И напоследок
Scrum, где фокус направлен на четкую детализацию и многократную итерацию системы, точно не подойдёт для конвейера, проектов с фиксированными сроками, стоимостью и 100% предварительным видением результата.
Именно поэтому в числе наших проектов есть 1%, с которым мы работаем иначе. Но это уже совсем другая история :)
Мы уверены, что кроме решения вашей задачи, мы найдем идеальный вариант построения командной работы на результат.
Поработаем вместе? Ждем ваше письмо у нас на почте request@codeinside.ru .
А если вы жаждите интересных проектов со сложным решением, ваше резюме просто обязано прилететь на job@codeinside.ru <3
"Scrum, где фокус направлен на четкую детализацию и многократную итерацию системы, точно не подойдёт для конвейера, проектов с фиксированными сроками, стоимостью и 100% предварительным видением результата."
Почему? Это решается очень просто, вы слишком усложняете.
Потому что для выше описанных проектов более эффективными будут классические "водопадные" методы :) Проверено!))