Pull to refresh

Проблемы при внедрении Agile

Agile *
Sandbox
Как и многие сейчас, мы решили попробовать внедрить 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 коде


При работе с системой, имеющей длинную историю, введение почти каждой новой фичи сводится к изменению уже существующего функционала. При этом очень сложно провести эффективное планирование спринта. По нашему опыту планирование изменений происходит по одному из трех сценариев:
  1. Никто, кроме техлида, который готовил бэклог вместе с PO, не понимает, о каком функционале речь. В результате вместо обсуждения получается монолог техлида и оценки даются во многом с потолка. Задачи тоже формулируются в крайне общем виде.
  2. Необходимый функционал знают один-два человека из команды, они быстро понимают, что нужно изменить, дают осмысленные оценки. Остальные при этом чувствуют себя обделенными и «лишними на этом празднике» и пытаются подстраховаться очень консервативными оценками.
  3. Все члены команды понимают, о чем речь, — реализация истории планируется быстро, точно и эффективно. Пока этот случай встречался только в книгах про agile.

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

Что такое «хорошо»


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

Первый среди равных


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

Перечисленный список ни в коей мере не претендует на полноту, а предлагаемые идеи еще не опробованы. Как отмечено выше, топик скорее приглашает к дискуссии, нежели дает рецепты.
Tags:
Hubs:
Total votes 36: ↑33 and ↓3 +30
Views 3.8K
Comments Comments 7