SCRUM: четыре итерации спустя

В октябре команда проекта Zarplata.ru перешла на скрам, предпосылки и ожидания я описал ранее. За прошедший квартал мы провели четыре спринта, старались следовать рекомендациям и общепринятым установкам. Наши договоренности остались в силе: все спринты были трехнедельными, был инженерный день, ретро и планирование.

Что было хорошего?

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

Постановка задач. Мы тратим полдня на планирование спринта. Постановка задач на первую итерацию была очень некачественной, возникало огромное количество вопросов тестировщика и программистов. На первой ретроспективе основной темой обсуждения были постановка задач и уточнение требований. В итоге требования стали лучше, формат требований изменился и стал более конкретным. Мы на планировании обсуждаем зачем задача нужна, проговариваем сценарии использования, значимые моменты реализации. Все это позволяет нам лучше понимать задачу, точнее оценивать задачи.

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

Что надо улучшить?

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

Как ни прискорбно, но у нас до сих пор нет юнит-тестирования. Надеюсь, что мы начнем использовать TDD или BDD при написании кода.

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

Технический долг, незакрытые баги. Необходимо закрыть все баги в TFS. Часть из них уже неактуальна, но тем не менее надо проверить, закрыть устаревшие, решить существующие. Данная мера позволит использовать баг-трекер более продуктивно. С техническим долгом также надо работать. В середине года мы начали работы по анализу 500 ошибок сайта. Также в коде было множество поглощаемых исключений. Каждое такое место мы начали логировать. Анализ логов также позволил закрыть ряд ошибок. В итоге количество 500 ошибок снизилось в несколько раз. Логи также не сильно пухнут от ошибок. Но эту работу необходимо продолжать.

Планирование на год. Есть идея завести несколько показателей и следить за их достижением в течение года. Количество пользователей, количество откликов, количество объявлений и т.д.

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