Тёмная сторона Agile

Основатель компании-разработчика Hello World Technologies Евгений Тюменцев о том, почему ценности гибкой методологии не подходят для крупных проектов.

В январе 2016 года на Гайдаровском форуме Герман Греф произнес знаменитую фразу: «Кто не освоит Agile сегодня, тем придется в текущих бизнес-процессах быть лузерами завтра». Глава «Сбербанка» увидел в гибких методологиях инструмент, который увеличит скорость изменений программной платформы банка.

После заявления Грефа, возможно, многие компании не из ИТ-сферы начнут предпринимать попытки (или уже начали) внедрять у себя Agile. Может ли это ускорить изменения? Чтобы ответить на поставленный вопрос, вспомним, что такое Agile.

Ценности гибких методологий задекларированы в Agile-манифесте. Их четыре:

Любая методология разработки программного обеспечения, которая удовлетворяет этим четырем ценностям, может называться гибкой.

Еще в 60-х годах 20 века Наус и Фарр замерили, как количество программного кода влияет на продолжительность проекта. Они получили нелинейную зависимость, которая имела вид степенной функции с показателем 1,5 — как показано на рисунке. Пунктирная линия показывает график линейной зависимости, а сплошная — график фактической.

Поясним значение этого исследования на примере. Предположим, что программисту вместо написания кода пришлось бы выложить стену из кирпичей. Первый кирпич условно он бы уложил за две минуты, десятый — за пять минут, а тысячный — уже за десять часов.

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

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

Приведенный график показывает, что с определенного момента, даже если разработка стоила 30 млрд рублей, как у «Сбербанка», проект дешевле переписать, чем изменять. Некоторые компании сумели превратить это в бизнес, наладив регулярный выпуск новых версий и заставив платить за это потребителя.

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

Есть еще несколько проблем, которые порождены эффектом падения производительности и имеют непосредственное отношение к Agile. Каждую из проблем опишем с двух точек зрения: как её решают программисты и как решение подается клиенту.

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

Решение: итеративные процессы разработки. При небольших объемах скорость разработки меняется незначительно, а значит, можно добиться приемлемой точности оценки. Отказываемся от оценки всего проекта в целом. Разбиваем его на небольшие куски — фазы. Перед стартом новой фазы делаем оценку только для неё. Так появились итеративные процессы разработки.

Подача решения: необходимость в получении обратной связи. В конце каждой итерации необходимо получить обратную связь от заказчика, чтобы быть уверенным, что проект на правильном пути. Обратная связь, безусловно, очень важна, но современные практики, например, Continuous Delivery, позволяют получить её в любой момент, не дожидаясь конца итерации. Зато итеративная разработка прижилась.

Производительность команды снижается со временем. Поэтому даже при итеративной разработке ошибка будет только нарастать.

Решение: Velocity. В Agile есть практика Velocity, которая заключается в определении коэффициента — разница между фактическим объемом и планируемым, поделенная на планируемый объем работ. На этот коэффициент будет умножаться оценка следующей итерации.

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

Подача решения: никак. Это временной буфер, который каждый грамотный менеджер должен иметь на проекте.

Чем дольше откладывается изменение, тем дороже обойдется его реализация.

Решение: расставить приоритеты. Важна последовательность реализации. Делать в первую очередь надо то, что приносит наибольшую выгоду. Аргумент, с которым трудно спорить.

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

Подача решения: готовность к изменениям важнее следования первоначальному плану (четвёртая ценность Agile). Как следствие, заказчик, возможно, неосознанно, принимает, что будет реализована не вся функциональность, которую он хочет, а только та, на которую у него хватит денег, при этом заранее неизвестно, на что именно их хватит.

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

Решение: отказаться от документирования. Хороший код должен быть самодокументируемым — то есть понятным настолько, чтобы не нуждаться в документации. На первый взгляд, выглядит дико, но мне на практике не встречался проект, где с документацией было всё в порядке. Чаще всего её начинают писать, но потом бросают из-за того, что не хватает времени на разработку.

Подача решения: работающий продукт важнее исчерпывающей документации (третья ценность Agile).

Классический треугольник управления проектами описывает три ограничения: сроки, стоимость и содержание проекта. Изменение одного из параметров влияет на два остальных. Чего хочет клиент: получить нужную функциональность за оговоренные деньги в указанные сроки.

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

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

Подача решения: сотрудничество с заказчиком важнее согласования условий контракта (вторая ценность Agile).

Решение: дать людям почувствовать ответственность за результат. На этой почве в Agile используется очень много психологических приемов, цель которых — сделать так, чтобы человек принял на себя ответственность.

Например, довольно часто программист может отказаться от ответственности за соблюдение сроков по отдельной задаче, если оценку давал не он сам. Чтобы исключить подобную ситуацию, используется прием Planning Poker — коллективное оценивание задач на итерацию, конечный результат которого — согласие каждого члена команды с оценкой на каждую задачу.

Подача решения: люди и взаимодействие важнее процессов и инструментов (первая ценность Agile). Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу.

Дело в другом: Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей. В этом плане Agile-манифест — отличное пособие о том, как недостатки превратить в преимущества. Но этого недостаточно для больших проектов.

#Колонка