Дайте хорошему айтишнику задачу и свободу творчества — и он сделает работу классно. В срок? Не факт. Учтет все требования ТЗ? Тоже вряд ли. Но на выходе будет классно, потому что программист полностью погружен в процесс, занят делом, которое он любит и хорошо знает.

А кто будет отвечать за распределение ресурсов, сроки и приоритеты? Это задача руководителя. Ему нужно создать среду, в которой команде разработчиков будет комфортно, а рамки не ограничат, а работу организуют.

Но регламентировать бизнес-процессы для программистов — та еще задачка. Еще в конце XX века стало понятно, что для сферы ИТ не подходят каскадные методологии управления проектами — слишком низкая адаптивность и высокая стандартизация. Нужно что-то более гибкое, чтобы оценивать трудозатраты сотрудников, планировать процесс разработки с учетом меняющихся требований и контролировать дедлайны. Наша команда программистов нашла выход — методология Скрам (Scrum).

Скрам: гибкость – наше второе имя

В ИТ-мире подход Скрам (Scrum) стал настоящим спасением для организации работы разработчиков. Это гибкая методология управления проектами, при которой разработка разбивается на короткие итерации – спринты. Они могут иметь разную продолжительность: одну или две недели, месяц. Такая структура работы позволяет поддерживать непрерывность процесса и постоянное совершенствование продукта.

Во время работы по спринтам команду ждет несколько этапов.

Шаг №1: оцениваем трудозатраты задач

Для планирования спринта руководитель проекта должен учитывать, сколько задач может выполнить за это время каждый сотрудник. Но, в отличие от производства, в сфере разработки часто появляются нестандартные задачи, которые сложно оценить заранее. К примеру, адаптировать новый модуль к устаревшей системе — просто или сложно? А внести правки в старый код, когда не было проведено тестов — долго или быстро?

Ни руководитель, ни исполнитель ответить на эти вопросы не сможет, пока не начнет работу и не увидит масштаб задачи. А планировать время нужно заранее. Поэтому в Скрам (Scrum) используют сторипоинты (story points) — единицу измерения трудозатрат.

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

Алгоритм простой:

Разработчики и руководитель проекта обсуждают задачу.
Участники выбирают из колоды Фибоначчи карту с числом, как они оценивают сложность задачи, и вскрываются.
Идет процесс обсуждения. Игроки, у которых значения карт сильно отличаются от остальных, объясняют свой выбор числа.
Второй раунд — после обсуждения игроки снова делают ставки.

В процессе игры может быть несколько раундов, пока команда не придет к компромиссу.

Когда все задачи оценены, руководитель начинает планирование спринта.

Шаг №2: используем доску

Все задачи находятся в списке, который команда регулярно актуализирует. Перед началом спринта руководитель вытягивает из него задачи и перемещает на доску. Здесь карточки с задачами двигаются по 4 колонкам:

Сделать.
В работе.
Готово.
Принято.

Задача команды — за отведенное на спринт время переместить все карточки в финальную колонку доски.

Шаг №3: проводим стендапы

Встречи команды в Скрам (Scrum) называют стендапами. Собрания проводятся:

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

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

Шаг №4: фиксируем результаты

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

Как отдел разработки Аспро работает по гибкому методу

Имея за плечами более 9 лет опыта в сфере создания программного обеспечения, мы решили рассказать, как налажена работа в нашем отделе разработки. В основе наших процессов лежит методология Скрам (Scrum), однако за годы практики мы пришли к выводу, что для достижения максимальной эффективности необходимо адаптировать некоторые ее элементы под наши потребности.

Организуем работу

Наши спринты подобны коротким забегам: неделя для спринтеров, две — для стайеров. Чтобы бегуны не путались, каждый участвует только в одном забеге — проекте.

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

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

Используем таск-трекер

Поначалу мы ютились в чужих менеджерах задач, но затем решили создать свой — Аспро.Agile. Мы создавали, тестировали и дорабатывали программу 5 лет, чтобы учесть требования всех членов команды.

Аспро.Agile — это как швейцарский нож: простой, удобный и с кучей полезных инструментов. Например, в системе есть база знаний. Она особенно полезна для начинающих разработчиков, которым больше не нужно стесняться задавать «глупые» вопросы. Решили сложную задачу — поделились решением в базе знаний, чтобы помочь другим.

Ставим задачи

Задачи по развитию продуктов хранятся в списке. Спринты помогают нам структурировать этот поток и ставить перед командой четкие, достижимые цели. Разработчик получает ясное представление о задачах и их приоритетности: красный — срочно, зеленый — опционально. Использование покера планирования постепенно сходит на нет, так как для типовых задач мы ведем учет трудозатрат.

Проводим ежедневные стендапы

Рабочий день в отделе разработки начинается со стендапа — мы проводим общее собрание для команд из всех проектов. Почему это важно? Когда разработчик делится проблемой, коллеги могут предложить идею решения. Так все остаются в курсе происходящего, даже если работают над разными задачами. Успешные команды вдохновляют остальных, задавая высокую планку, даже неосознанно.

Закрываем спринты

Результат спринта — готовый продукт или его часть. Мы работаем по принципу постоянного улучшения, поэтому каждый прогресс считаем хорошим результатом. Чтобы протестировать продукт, сотрудник из другого проекта проводит обзор кода — так мы обеспечиваем перекрестные проверки внутри отдела разработки.

Задача продуктового менеджера по завершении спринта — подсчитать затраченные сторипоинты (story points), чтобы сделать более оптимальное планирование на следующую итерацию или новый проект.

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

Во время перехода на Скрам (Scrum) мы рекомендуем использовать разработчикам Аспро.Agile. В системе есть все необходимое для работы по гибкой методологии. Но подходящие инструменты — это еще не означает работу по гибким методологиям. Платформа эффективна, только если команда проводит стендапы, оценивает задачи и следует принципам методологии.

Секреты от Аспро: как сделать разработку гибкой и эффективной