Дайте хорошему айтишнику задачу и свободу творчества — и он сделает работу классно. В срок? Не факт. Учтет все требования ТЗ? Тоже вряд ли. Но на выходе будет классно, потому что программист полностью погружен в процесс, занят делом, которое он любит и хорошо знает.
А кто будет отвечать за распределение ресурсов, дедлайны и приоритеты? Это задача руководителя. Ему нужно создать среду, в которой команде разработчиков будет комфортно, а рамки не ограничат, а организуют работу.
Но регламентировать бизнес-процессы для программистов — та еще задачка. Еще в конце XX века стало понятно, что для IT не подходят каскадные методологии управления проектами — слишком низкая адаптивность и высокая стандартизация. Нужно что-то более гибкое, чтобы оценивать трудозатраты сотрудников, планировать процесс разработки с учетом меняющихся требований и контролировать дедлайны. Наша команда программистов нашла выход — методология SCRUM.
SCRUM: гибкость – наше второе имя
В IT-мире подход SCRUM стал настоящим спасением для организации работы разработчиков. Это гибкая методология управления проектами, при которой разработка разбивается на короткие итерации – спринты. Они могут иметь разную продолжительность: одну или две недели, месяц. Такая структура работы позволяет поддерживать непрерывность процесса и постоянное совершенствование продукта.
Во время работы по спринтам команду ждет несколько этапов.
Шаг №1: оцениваем трудозатраты задач
Для планирования спринта руководитель проекта должен учитывать, сколько задач может выполнить за это время каждый сотрудник. Но, в отличие от производства, в сфере разработки часто появляются нестандартные задачи, которые сложно оценить заранее. К примеру, адаптировать новый модуль к устаревшей системе — просто или сложно? А внести правки в старый код, когда не было проведено тестов — долго или быстро?
Ни руководитель, ни исполнитель ответить на эти вопросы не сможет, пока не начнет работу и не увидит масштаб задачи. А планировать время нужно заранее. Поэтому в SCRUM используют Story Points — единицу измерения трудозатрат.
Наша команда проводит оценку Story Points с помощью покера планирования. И ставки тут бывают повыше, чем в техасском холдеме — не на фантики играем, а на оценку собственной работы.
Алгоритм простой:
- Разработчики и руководитель проекта обсуждают задачу.
- Участники выбирают из колоды Фибоначчи карту с числом, как они оценивают сложность задачи, и вскрываются.
- Идет процесс обсуждения. Игроки, у которых значения карт сильно отличаются от остальных, объясняют свой выбор числа.
- Второй раунд — после обсуждения игроки снова делают ставки.
В процессе игры может быть несколько раундов, пока команда не придет к компромиссу.
Когда все задачи оценены, руководитель начинает планирование спринта.
Шаг №2: используем SCRUM-доску
Все задачи находятся в бэклоге — это список, который команда регулярно актуализирует. Перед началом спринта руководитель вытягивает из бэклога задачи и перемещает ее на доску. Здесь карточки с задачами двигаются по 4 колонкам:
- Сделать.
- В работе.
- Готово.
- Принято.
Задача команды — за отведенное на спринт время переместить все карточки в финальную колонку доски.
Шаг №3: проводим стендапы
Встречи команды в SCRUM называют стендапами. Собрания проводятся:
- до начала спринта — команда обсуждает объем работы и актуализирует бэклог;
- ежедневно перед началом рабочего дня — каждый сотрудник рассказывает о прогрессе, сложностях и планах;
- в конце спринта или месяца — во время ретроспективы команда анализирует проделанную работу.
Стендапы помогают не выходить за рамки планирования и поддерживать контакт между членами команды.
Шаг №4: фиксируем результаты
В конце каждого спринта мы анализируем результаты работы каждого участника команды. Фиксация данных о выполненных задачах позволяет нам выявлять закономерности и оценивать индивидуальную производительность. Это, в свою очередь, дает нам возможность более точно планировать будущие спринты, устанавливать реалистичные сроки и прогнозировать рентабельность проекта.
Как отдел разработки Аспро работает по Agile
Имея за плечами более 9 лет опыта в сфере создания программного обеспечения, мы решили рассказать, как налажена работа в нашем отделе разработки. В основе наших процессов лежит методология SCRUM, однако за годы практики мы пришли к выводу, что для достижения максимальной эффективности необходимо адаптировать некоторые ее элементы под наши потребности.
Организуем работу
Наши спринты подобны коротким забегам: неделя для спринтеров, две — для стайеров. Чтобы бегуны не путались, каждый участвует только в одном забеге — проекте.
Для простых обновлений задачи дизайнеру и маркетологу даются как разовые поручения, а в ежедневных стендапах участвуют только разработчики.
Для создания нового софта мы собираем кросс-функциональную команду: продакт-менеджера, разработчиков, дизайнера и маркетолога. Если задачи накапливаются как снежный ком и спринт грозит затянуться, оперативно привлекаем подкрепление, например, второго дизайнера.
Используем таск-трекер
Поначалу мы ютились в чужих таск-трекерах, но затем решили создать свой — Аспро.Agile. Мы создавали, тестировали и дорабатывали программу 5 лет, чтобы учесть требования всех членов команды.
Аспро.Agile — это как швейцарский нож: простой, удобный и с кучей полезных инструментов. Например, в системе есть база знаний. Она особенно полезна для начинающих разработчиков, которым больше не нужно стесняться задавать «глупые» вопросы. Решили сложную задачу — поделились решением в базе знаний, чтобы помочь другим.
Ставим задачи
Задачи по развитию продуктов хранятся в бэклоге. Спринты помогают нам структурировать этот поток и ставить перед командой четкие, достижимые цели. Разработчик получает ясное представление о задачах и их приоритетности: красный — срочно, зеленый — опционально. Использование покера планирования постепенно сходит на нет, так как для типовых задач мы ведем учет трудозатрат.
Проводим ежедневные стендапы
Рабочий день в отделе разработки начинается со стендапа — мы проводим общее собрание для команд из всех проектов. Почему это важно? Когда разработчик делится проблемой, коллеги могут предложить идею решения. Так все остаются в курсе происходящего, даже если работают над разными задачами. Успешные команды вдохновляют остальных, задавая высокую планку, даже неосознанно.
Закрываем спринты
Результат спринта — готовый продукт или его часть. Мы работаем по принципу постоянного улучшения, поэтому каждый прогресс считаем хорошим результатом. Чтобы протестировать продукт, сотрудник из другого проекта проводит код-ревью — так мы обеспечиваем кросс-проверки внутри отдела разработки.
Задача продакт-менеджера по завершении спринта — подсчитать затраченные сторипоинты, чтобы сделать более оптимальное планирование на следующую итерацию или новый проект.
Раз в квартал мы проводим ретроспективу со всеми сотрудниками отдела разработки, чтобы во время встречи рассмотреть успешные кейсы и найти причину провальных проектов.
