Тёмная сторона Agile Статьи редакции

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

Евгений Тюменцев

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

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

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

  1. ​Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

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

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

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

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

Для программирования свойственно падение производительности труда по мере роста проекта

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

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

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

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

Проблема №1. Нарушение сроков разработки

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

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

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

Следствие решения проблемы № 1: производительность всё равно падает

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

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

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

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

Проблема №2. Стоимость реализации требований увеличивается со временем

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

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

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

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

Проблема №3. Нет времени на документацию

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

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

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

Проблема №4. Невозможно выполнить проект при соблюдении сразу всех трёх ограничений: функциональность, сроки, бюджет

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

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

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

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

Проблема №5. В условиях, когда сроки сложно прогнозировать, результат проекта зависит от усилий и способностей конкретных исполнителей

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

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

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

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

0
84 комментария
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Artur Mustafin

Не мечи бисер перед свиньями, не трать время. В России вообще не принято использовать узкую специализацию. Берут человека который ВСЕ делает ПЛОХО. То есть если в резюме указать ОДНУ вещь, которую ты делаешь действительно ХОРОШО, например аналитику, то будешь годами сидеть без работы, плюс фактор кумовства в Москве никто не отменял. Поэтому возьмут человека который будет плохим системным администратором программистом и аналитиком, зато очевидная экономия на ИТ с точки зрения менеджера продукта. То же самое с архитектором, программистом и аналитиком. То есть все принимают правила игры, что в России в резюме можно написать вообще всё, что угодно, никакого доверия сертификатам, а проверять будут все равно так, как будто вчера институт закончил, при этом отдавая предпочтение однокурсникам. Так что вообще все равно, что и как ты знаешь, это не имеет почти никакого значения - главное- как ты "обманешь" работодателя. Поэтому хорошие кодеры - это full-stack програмисты, пргарммисты - это архитекторы систем а архитекторы систем - это у нас генеральные директора, не окончившие MBA, и все всё знают и умеют, а спеси - просто вагонами разгружай. Лично я вообще не встретил за 4 года в Москве вообще ни одного архитектора, все либо глубоко законспирировавшиеся менеджеры продукта, либо вообще пользователи ПК Visio, имеющие сугубо абстрактное представление о предмете. Потому что даже специализации такой в высшей школе нет - все без исключения в лучшем случае "инженер-программист"-ы. То есть это вообще не российская тема, нам не понять, зачем нужен отдельный человек для рисования в Visio архитектур, хоть немного приближенных к реальности, а не просто веселые картинки для заказчика (хотя на эту задачу как раз и берут), отдавая на откуп программистам всю архитектуру систем,на коленке сделал - молодец, сэкономил деньги гендиру на дачку. Нет - не беда, возьмем другого "гения". Так и получается, что в условиях отсутствия жесткой конкуренции все бросаются на "универсалов", и под iOS чот-то криворукое слабать, и страничку HTML наковырять, главное уметь сделать картинку, а уж как оно внутри работает - лучше вообще не спрашивать. Все равно никто никогда не пишет комментарии.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гала Перидоловна

Не надо ничего разбивать, надо нанимать адекватных людей, платить много денег и завышать строки 2.5x. Обкатано 2 системами, которые писались 4 и 5,5 лет. Обе по окончанию выстрелили и приносят кучу профита. Разработка шла без этих аджайлов/скрамов/вотерфолов. И большой проект - это геораспределенный сторадж со своим умным мастер элекшном и возможностью выбора поколоночного/сторокового храниения данных, а не сайтик с API, CI и прочими бэкендами.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гала Перидоловна

Я вам могу рассказать как работает докер до уровня строчек инициализации cgroups в ядре, тк учавствовал в разработке аналогичного решения на основе lxe. Я отлично знаю что такое cloud и учавствовал в запуске кластеров на самописных решениях ещё до появления хадупа и это все мы делали в России. Так вот, ваши микросервисы раньше назывались SOA, ничего революционного тут нет.

Про модель акторов/корутин известно давно и она ортогональна микросервисам. И сервисы, которые скейлятся это из области булшит бинго. Вы теряете минимум два сискола и контекст свеча и сеть у вас ни разу не рилаебл. А всякие паксосы с опытами и госип протоколами можно реализовывать без микросервисов. То о чем вы говорите это набор базвордов, типичный хайп драйвен девелопменту. Займитесь чтением Тененбаум лучше.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гала Перидоловна
Расскажите про это все разработчикам Netflix, которые построили свою систему так, что chaos monkey не могут вывести ее из строя. Если вы создаете систему которая ломается от упавшего элемента типа сети, то вам надо поучиться немного у Нетфликс.

Я готов поспорить на любые деньги что могу завалить Netflix несколькими командами при настройке сети. man autonomous system. Компания где я работаю выключает целые дата-центры для поиска проблем. Но да, куда уж нам до Netflix, они же статей понаписали как у них все хорошо.

-я и не писала что это одно и то же, я написала - либо либо, что в русском языке обозначает или или :)))

Тогда я вообще не понимаю зачем вы это написали.

Это не из области булшита, это из реальной жизни, когда можно scaleout количество вебсерверов при повышенной нагрузке и scale down когда пользователи идут спать, а так scale up и scale down database. Выигрыш по деньгам и доверию клиентов очевиден.

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

Причем тут cloud и хадуп? в клауде уже давно есть ВСЕ :)))

А теперь самое интересное. Netflix с точки зрения построения системы фактически read-only система. Это ни месседжер, ни социальная сеть, ни система обработки 100500 показаний с датчиков. Почему я выше упомянул 100Тб? Все элементарно, все что нужно от Netflix взять широкий канал и отдавать при совпадении какого-то хэша пользователю стрим с видео. Они не кодируют видео на лету, эта задаче даже не потребляет cpu, а при грамотном подходе можно вообще все популярные сериалы грузить в RAM и снизить нагрузку на диск на несколько порядков, а уж если подхачить ядро, то можно убрать copyto/copyfrom(например, dpdk) и вообще быть в шоколаде. Но это не работает если вам нужно процессить 100Тб данных в реалтайме. Я вот вижу как забиваются 10Гб/с интерконнекты между нодами кластера, и 40Гб/с видел забитыми. И это еще с учетом того что там нет TCP/IP, а свой собственный протокол. Сидят на другом конце Петя с Васей и периодически запускают свои аналитические скрипты + считаются какие-то ежедневные данные для пользователей. Никто из них не подозревает что с другой стороны 272000 ядер загружены на 85-92%(это очень высокий процент утилизации, если что), все 512Гб памяти каждой ноды используются на 80-90%. Там каждый день одна нода прокачивает через себя четверть всего дневного трафика Netflix, если не больше. А вы мне тут про микросервисы :)

CAP theorem как раз об этом и есть - вы либо выбираете availability, либо consistency.

https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html вот тут почитайте.

Давайте уже составим доску булшит бинго и будем опровергать ваши тезисы :)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

Напишите как лучше кем вы работаете, какова ваша специализация ?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

Вы нахватались buzzwords и раскрученных имен авторитетов (компаний и персоналий) и козыряете ими, а в технологии не шарите ;-)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

Ладно, отстану от вас, но только потому, что вы используете технологии моего любимого Микрософта (и даже упоминаете про VSTS).

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

Читал, вижу у вас используется MS SQL Server - вот это правильно !

Ответить
Развернуть ветку
Гала Перидоловна
Scale up и scale down real time работает совсем не так как вы написали. Создается новый сервер, больше памяти и CPU, происходит failover. Да там присутствует blip, но так как сервисы уже работают с расчетом что БД может быть недоступна, то ничего не падает, просто в какой то момент клиенты могут получить какое то количество failed response, но если failover произойдет за несколько секунд то даже этого не будет.

Это несусветная чушь, никто так не делает кроме стартапов. failover - это отказоустойчивость, она не происходит, она всегда присутствует. Создается либо избыточностью изначально, либо хот стендбаем. Никто. Никогда. Не запускает дополнительные инстансы в реальном времени потому что неизвестно как это будет происходить под нагрузкой, за сколько времени оно запустится и как перебалансируется. Вообще тема балансировки весьма сложная и только на rr не заканчивается. Перебалансировать новые веса, да еще и в разных ДЦ, да еще и с приоритетами и чтобы все работало - это только в рекламе маркетологов работает.

тоже смешно, вы наверное еще по ладони гадать умеете и будущее по кофейной гуще предсказываете.

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

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

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

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

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

Причем тут ваши кластеры - вообще непонятно.

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гала Перидоловна
Вы даже не видите разницы между архитектурой веб сервисов и ваших кластеров. Это принципиально разные вещи с разные проблемами.

Конечно не вижу, я же веб разработкой занимался много лет еще во времена когда все писалось на C/C++/perl или php. И ушел из нее с появлением NodeJS, потому что невозможно смотреть на код людей, которые за 3 месяца выучили JavaScript и теперь считают что они разработчики.

Сразу видно что вы лезете не в свою тему, в которой вообще ничего не понимаете, и про таймауты не слышали, про circuit breaker patterns не слышали.

Опять булшит бинго с базвордами. Circuit breaker используется как раз из-за убогости микросервисов. Вы мне решили всю http://www.oreilly.com/programming/free/microservices-antipatterns-and-pitfalls.csp процитировать? Я ее тоже читал, не удивите :)

Я тупо перепечатываю мысли других людей, а вы начинаете со мной спорить, как будто я сама все это придумала и этого ничего не существует и выставляете себя полным дураком.

Вы это не придумали, вы не понимаете причину и следствие. Вот тот же пример с circuit breaker говорит о том что вы не понимаете зачем оно нужно и почему появилось. Ну мне просто нельзя из-за NDA говорить где я работаю и над чем, а покидаться в микросервисы говном святое дело, особенно если человек не понимает что это всего лишь базворды. Вся ваша инфарструктура сейчас скопирована с той компании где я работаю. Мы это видели, плавали и знаем где оно стреляет :)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гала Перидоловна
Вы даете ссылку на книгу, которую написал an experienced hands-on software architect involved in the architecture, design, and implementation of Microservices Architectures, Service Oriented Architectures, and distributed systems in J2EE and other technologies.

А на кого я должен дать ссылку? На человека который никогда не проектировал микросервисы?

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

Начнем с того, что в названии книги есть слово antipatterns. Если начать читать то что там излагается, то можно внезапно узнать узкие места, которые являются критичными во многих системах. Иногда это приводит людей к тому, что они начинают задумываться стоит ли им бездумно следовать тренду и использовать микросервисы. Базворды это не плохо, плохо когда человек не понимает всей сути этих слов. Вот пример бездумного использования базвордов вами:

где вы либо пишете monolithic application я использованием actor pattern, либо кучу services, каждый из которых вы может потом либо переписывать, либо убирать, либо scale.

Что же здесь плохого? Модель акторов мы уже обсудили, она может быть использована в любом приложении, она ортогональна микросервисам. Это базворд, потому что вы не понимаете его сути и лепите куда попало. Куча сервисов тоже базворд, потому что это никак не затрудняет возможность рефакторинга монолитного приложения. Переписать можно все что угодно. Убирать тоже можно все что угодно. По поводу масштабирования тоже базворд, вы не понимаете сути построения приложения. Например, используя gossip протокол я могу приводить к консенсусу кучу инстансов монолитного приложения. Оно так же может быть отмасштабировано добавлением и удалением нод и это тоже ортогонально микросервисам.
Что же мы видим в книге и почему это не набор базвордов? Все очень просто. Автор описывает словами как и где не нужно использовать микросервисы. Он не просто бросается словами и пишет: "мы тут скейлимся за счет акторов, а ваши монолитные приложения так не могут". Видите разницу? Он ни где там не пишет что монолитные приложения устарели и всем пора переписать все на микросервисах.

Вы уже 10 раз повторили что я не понимаю причину и следствие,а по моему это у вас в голове каша полная.

Очень давно мне задали вопрос про работу MMU и я такой радостный начал выкрикивать слова вроде прерываний, аллокации памяти, виртуального и реального режима. Все это было чушью, ибо я не мог это объяснить словами. Да, я посидел с осцилом, почитал книги по микроэлектроннике, написал собственную реализацию процессора и только потом смог объяснить что же это такое. Вот когда вы сможете своими словами объяснить чем же плохи монолитные приложения, а не будете выкрикивать scale! docker! ci! services! как Стив Баллмер на конференции, тогда я приму ваше мнение как что-то стоящее, а сейчас это _набор базвордов_.

Ответить
Развернуть ветку
Андрей Захаров
Расскажите про это все разработчикам Netflix, которые построили свою систему так, что chaos monkey не могут вывести ее из строя

У них там есть интеграционное тестирование перед релизом ? Или как ? Если у них такая устойчивая архитектура, то особого смысла нет, т.к. даже пролезший баг вреда не принесет, не так ли ? ;-)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Захаров

Никаких откровений статья не содержит, равно как и упоминаний о микросервисах, а ведь мы о них же дискутируем ?

Ответить
Развернуть ветку
81 комментарий
Раскрывать всегда