Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.
В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».
Система, для развития которой мы решили применить agile — это давно и стабильно развивающееся решение. Продукт уже несколько лет в эксплуатации, поставка изменений делается итерациями, интервал между установками релизов в production — не более полугода. Процесс разработки не «заформализированный», фичи описываются представителями заказчика в довольно свободной форме и практически сразу идут в разработку. Разработкой в разное время занимались разные команды.
Для разработки очередного релиза мы решили применить Scrum, чтобы достичь следующих целей:
Ну а теперь, как и обещалось в названии, о проблемах, с которыми мы столкнулись.
Scrum предусматривает роль владельца продукта (Product owner). Product owner является и владельцем продуктового бэклога, добавляя, приоретизируя и удаляя истории. Может сложиться опасное ощущение, что для успеха достаточно иметь некоторое представление о функционале, который необходимо разработать, описать это представление в виде истории с нужным приоритетом, а команда на планировании спринта сама разберется, что и как нужно реализовать. Наш опыт показывает, что это предположение неверно.
Здесь уместно вспомнить покрытую пылью водопадную терминологию, а именно такие понятия, как анализ (analysis) и проектирование (design). Как ни странно, описания гибких методологий немного говорят о проектировании и практически совсем не упоминают об анализе. Из опыта подготовки бэклога, его обсуждения на планировании и последующей реализации функционала мы сделали вывод, что подготовка качественного бэклога требует времени и усилий, иначе говоря, проведения работы по анализу. Несмотря на то, что «интерфейсом» с командой является product owner, в анализе может быть занято значительное число людей. В отличие от водопадного процесса, анализ не выполняется в начале для всего проекта, а происходит в течение всей разработки, обеспечивая готовность наиболее приоритетных историй к планированию и реализации.
При работе с системой, имеющей длинную историю, введение почти каждой новой фичи сводится к изменению уже существующего функционала. При этом очень сложно провести эффективное планирование спринта. По нашему опыту планирование изменений происходит по одному из трех сценариев:
Проблема усугубляется тем, что некоторые разработчики склонны к углублению в свою задачу и не стремятся к широкому охвату области применения системы. Т.е. далеко не все хотят вникать в чужие задачи, и со временем носителями знания так и остаются отдельные разработчики, а не команда в целом.
Разработчики склонны отклоняться от требуемой функциональности для обеспечения более высокого с их точки зрения качества системы. При этом критерии качества разработчиков могут не совпадать с таковыми со стороны пользователей или заказчика. Вероятно, эта проблема особенно актуальна при использовании 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, когда отсутсвуют четкие спецификации, а следовательно и однозначные критерии качества.
Решению этой проблемы может способствовать формирование общего видения среди членов команды и последовательное донесение до команды реальных сценариев использования системы и целей выполнения каждой системной операции.
Первый среди равных
Производительность разработчиков неодинакова. Если в иерархической организационной структуре наиболее производительные сотрудники продвигаются вверх и соревновательный дух зачастую поощряется, то в плоской команде сама идея примата коллективного над индивидуальным может быть демотивирующей для амбициозных и высокопроизводительных разработчиков. Дело здесь не в том, что возможность сделать работающий продукт и привести свою команду к успеху является плохим стимулом, чтобы трудиться на совесть. Проблема в том, что когда все трудятся на совесть, производительность у разных людей все равно разная в силу различий индивидуальных способностей. Идей о том, какие поощрительные стимулы можно использовать для высокопроизводительных сотрудников вместо делегирования дополнительной ответственности и продвижения по карьерной лестнице, у меня на данный момент нет.
Перечисленный список ни в коей мере не претендует на полноту, а предлагаемые идеи еще не опробованы. Как отмечено выше, топик скорее приглашает к дискуссии, нежели дает рецепты.