Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее,
поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от
использования менее гибких подходов к использованию более гибких.
В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как
некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу
дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным
методологиям» в плоскость «как работать по agile наиболее эффективно».
С чего все началось
Система, для развития которой мы решили применить agile — это давно и стабильно развивающееся решение. Продукт
уже несколько лет в эксплуатации, поставка изменений делается итерациями, интервал между установками релизов в
production — не более полугода. Процесс разработки не «заформализированный», фичи описываются представителями
заказчика в довольно свободной форме и практически сразу идут в разработку. Разработкой в разное время
занимались разные команды.
Для разработки очередного релиза мы решили применить Scrum, чтобы достичь следующих целей:
- Сделать разработку более упорядоченной. В отсутствие формального процесса и детального
планирования разработка шла по старому-доброму code-and-fix, временами переходящему в code-like-hell,
что не нравилось ни разработчикам, ни менеджерам. В то же время вводить зарегулированный процесс,
демотивируя разработчиков и увеличивая накладные расходы, никому не хотелось.
- Повысить точность оценок. До этого оценки на разработку единолично давались техлидом и
валидировались PM-ом. Как показал опыт, эти оценки были далеко не всегда точны. Привлечением всей
команды к оцениванию мы рассчитывали существенно повысить точность.
- Облегчить отслеживание состояния проекта. С помощью скрама, его коротких спринтов,
burndown chart, бинарного статуса историй мы рассчитывали получить возможность в каждый момент времени
понимать, сколько уже сделано, сколько осталось сделать, и с неплохой точностью предсказывать, какие
фичи будут готовы к определенному моменту.
- Снизить зависимость успеха команды от ключевых людей. В прошлом задачи детализировались
и распределялись техлидом. Т.к. объем функционала был довольно большим, ориентироваться в нем могли
только техлид и, в меньшей мере, один-два ключевых разработчика. Уход каждого из этих людей из команды
неизменно оборачивался большими проблемами.
Ну а теперь, как и обещалось в названии, о проблемах, с которыми мы столкнулись.
Откуда берется бэклог
или куда подевалась фаза анализа
Scrum предусматривает роль владельца продукта (Product owner). Product owner является и владельцем продуктового
бэклога, добавляя, приоретизируя и удаляя истории. Может сложиться опасное ощущение, что для успеха достаточно
иметь некоторое представление о функционале, который необходимо разработать, описать это представление в виде
истории с нужным приоритетом, а команда на планировании спринта сама разберется, что и как нужно реализовать.
Наш опыт показывает, что это предположение неверно.
Здесь уместно вспомнить покрытую пылью водопадную терминологию, а именно такие понятия, как анализ (analysis) и
проектирование (design). Как ни странно, описания гибких методологий немного говорят о проектировании и
практически совсем не упоминают об анализе. Из опыта подготовки бэклога, его обсуждения на планировании и
последующей реализации функционала мы сделали вывод, что подготовка качественного бэклога требует времени и
усилий, иначе говоря, проведения работы по
анализу. Несмотря на то, что «интерфейсом» с командой
является product owner, в анализе может быть занято значительное число людей. В отличие от водопадного процесса,
анализ не выполняется в начале для всего проекта, а происходит в течение всей разработки, обеспечивая готовность
наиболее приоритетных историй к планированию и реализации.
Как планировать изменения в legacy коде
При работе с системой, имеющей длинную историю, введение почти каждой новой фичи сводится к изменению уже
существующего функционала. При этом очень сложно провести эффективное планирование спринта. По нашему опыту
планирование изменений происходит по одному из трех сценариев:
- Никто, кроме техлида, который готовил бэклог вместе с PO, не понимает, о каком функционале речь. В
результате вместо обсуждения получается монолог техлида и оценки даются во многом с потолка. Задачи тоже
формулируются в крайне общем виде.
- Необходимый функционал знают один-два человека из команды, они быстро понимают, что нужно изменить, дают
осмысленные оценки. Остальные при этом чувствуют себя обделенными и «лишними на этом празднике» и
пытаются подстраховаться очень консервативными оценками.
- Все члены команды понимают, о чем речь, — реализация истории планируется быстро, точно и эффективно.
Пока этот случай встречался только в книгах про agile.
Проблема усугубляется тем, что некоторые разработчики склонны к углублению в свою задачу и не стремятся к
широкому охвату области применения системы. Т.е. далеко не все хотят вникать в чужие задачи, и со временем
носителями знания так и остаются отдельные разработчики, а не команда в целом.
Что такое «хорошо»
Разработчики склонны отклоняться от требуемой функциональности для обеспечения более высокого с их точки зрения
качества системы. При этом критерии качества разработчиков могут не совпадать с таковыми со стороны
пользователей или заказчика. Вероятно, эта проблема особенно актуальна при использовании agile, когда отсутсвуют
четкие спецификации, а следовательно и однозначные критерии качества.
Решению этой проблемы может способствовать формирование общего видения среди членов команды и последовательное
донесение до команды реальных сценариев использования системы и целей выполнения каждой системной операции.
Первый среди равных
Производительность разработчиков неодинакова. Если в иерархической организационной структуре наиболее
производительные сотрудники продвигаются вверх и соревновательный дух зачастую поощряется, то в плоской команде
сама идея примата коллективного над индивидуальным может быть демотивирующей для амбициозных и
высокопроизводительных разработчиков. Дело здесь не в том, что возможность сделать работающий продукт и привести
свою команду к успеху является плохим стимулом, чтобы трудиться на совесть. Проблема в том, что когда все
трудятся на совесть, производительность у разных людей все равно разная в силу различий индивидуальных
способностей. Идей о том, какие поощрительные стимулы можно использовать для высокопроизводительных сотрудников
вместо делегирования дополнительной ответственности и продвижения по карьерной лестнице, у меня на данный момент
нет.
Перечисленный список ни в коей мере не претендует на полноту, а предлагаемые идеи еще не опробованы. Как
отмечено выше, топик скорее приглашает к дискуссии, нежели дает рецепты.