Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому
Генеральный директор компании Accera, консультант по Agile, DevOps и Digital Transformation Анатолий Шеин написал для vc.ru колонку о том, почему гибкая методология разработки может полностью остановить работу крупного бизнеса, но подходит маленьким стартапам.
Agile - это НЕ МЕТОДОЛОГИЯ и НЕ ПРОЦЕСС! Проявите наконец компетенцию, а если не разбираетесь, ну зачем писать???? Громкое название статьи, но нет конкретики. Жертва - тот кто пал с концами. Падения на биржах были и из-за "высококачественных" вотерфольных проектов. И банки так же этим страдали. Так все таки кто жертва Agile ??
Кстати, Dmitry Dzhafarov действительно прав :-) Строго говоря, "Agile Software Development” не является ни методологией, ни процессом, а простым набором принципов. Однако за почти 20 лет существования понятие Agile превратилось в собирательное, например https://en.wikipedia.org/wiki/Agile_management
Вы, судя по всему, разбираетесь. Что же тогда - Agile?)
Попытки обвинить инструмент в том, что исполнители и их руководители - недисциплинированные идиоты, очень наглядно характеризует авторов таких статей. Не вдаваясь даже в подробности, что есть совмещенные Waterflow и Agile фреймворки, как раз для больших государственных и бизнес-организаций, типа Prince 2 Agile.
- Как правило про аджайл, скрам и канбан пишут люди, которые про это не то что не читали, а считают все это одним и тем же.
- Это работает на западе, потому что выстроен процесс вокруг что я делал вчера? Что я делаю сегодня? Что буду делать завтра. И как это все улучшить каждый день. Это будет работать, если каждый в команде будет задавать этот вопрос прежде всего самому себе. Более того, я решал 90% проблем за первую неделю, как Продакт Менеджер, просто применяя скрамбан. Увеличение производительности было на уровне 200-300%, при этом не было поиска виноватых и промахов на уровне: -"я сидел ждал пока Петя сделает то и нифига не делал". Каждую неделю надо следить за тем чтобы не допускать моментов, что кто-то блокирует работу, кто-то не работает и так далее.
- Чем Agile/Scrum/Kanban всем не нравиться по моему опыту, это тем что надо работать, включаться в процесс, каждый день отвечать за то что ты делаешь и улучшать это, такой ритм не для всех подходит, но это тоже одна из фишек скрама, безболезненно улучшить процессы и убирать не нужных людей из проекта.
- Для всего этого нужен крутой Product Manager/Product Owner, которые не будут заниматься мастурбацией, а будут выстраивать продукт изначально выстроив правильные Agile/Scrum процессы.
Для тех кто все таки не читал, но осуждает, прочитайте книгу Джеффа Сазерленда - SCRUM.
под Agile принято сметать весь тот бардак в компании, с которым проект встречается задолго до разработки.
Если есть рабочие примеры agile у больших компаний, как фб, гугл, значит ли это что он не для крупняков?
Заголовок надо поправить на "бардак губит крупный бизнес".
Agile это в первую очередь образ мышления команды, а уж потом фреймворки типа скрама и прочие прикладные вещи. Если команда не понимает и не принимает манифест аджайла на низовом уровне это рождает как раз такие проблемы как в примерах.
Хорошая статья :thumbsup:
Спасибо, Екатерина !
"Во-первых, мы знаем, что общее — это обычно ничьё. Поэтому ответственность за качество продукта нивелируется, и крайнего здесь нет."
А как же прожект менеджеры? Для них это одно из главных качеств. Уложить проект в треугольник..
Действительно, менеджеры - "скрам-мастера” и всякие остальные “куры” - отвечают за сроки и содержание. Считается, что качество придёт само собой, стоит только запустить автоматические проверки и, в крайнем случае, благодаря “continuous deployment”, за очень короткие сроки починить в “production” . Этот подход замечательно работает для таких компаний, как Facebook - ну подумаешь, лайк не сработал...
Сдается мне, что все доводы построены на заблуждении: "Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта.".
Потому что, говоря о разработке программного обеспечения время доставки ценности может быль маленьким если обеспечивается Качество продукта. А Качество продукта обеспечивается Качеством процесса. И инженерные техники eXtrem Programming (Парное программирование, Тесты первыми (TDD) , Непрерывная интеграция, Рефакторинг) направлены в первую очередь на обеспечение Качества продукта.
Если под Agile понимать только спринты, летучки, игры в планирование то конечно это не будет работать. Гибкая разработка ПО это не всегда ДЕШЕВО, БЫСТРО. Это НЕ ДЕШЕВО, это только иллюзия что быстро, потому что результат доставляется кусочками и можно корректировать развитие. НО за все нужно платить. Поэтому нужны автотесты, нужен TDD, нужна непрерывная интеграция, нужны автоматические приемочные тесты, нужен рефакторинг. И если что-то выкинули "это очень дорого для нас", то готовьтесь к тому что после внедрения будут проблемы.
И чтобы потом не обвинять "Это не мы виноваты, это Agile у нас не работает", Используйте простое правило:
Качество превыше всего.
Улучшая качество, вы улучшите процессы и скорость доставки доставки ценности.
Очень печально, что такие псевдоэкспертные статьи выносятся редакторами на публику.
Весь посыл статьи, Agile не работает у больших компаний, потому что есть примеры фейлов. Во-первых, я бы подробнее разобрал эти фейлы, ну даже если принять их, то , во-вторых, назовите мне принципы/подход/методологию/процесс и Пр. , с которыми не было фейлов. С тем же вотерфоллом фейлов не меньше уж точно.
Ну вы сами себя послушайте? "Тестирование становится сложным"- это же прямое противоречие тому, что пишите сами. В вотерфолле тестирование на порядок сложнее, более трудоемкое и вероятность пропустить ошибку выше.
Да, есть задачи, которые аджайлом не покрыть- строительство атомой станции итерациями и "фаст фейлом" не построить, но не надо говорить про "все" большие корпорации, банки в том числе. Любую хорошую идею можно утопить.
Водопад иссяк, в этом сомнений нет. Однако Agile в комплексных проектах приводит к потере равновесия между частотой изменений и частотой тестов. Конечное качество продукта зависит пропорционально от этого равновесия. Компаниям, которые недовольны качеством, необходимо поддерживать равновесие, увеличивая частоту тестов.
Статья не дает ответа на вопрос, какая связь между Agile и отсутствием тестирования бизнес-критичного функционала при релизе
Голый Agile говорит об автоматических тестах и скорости изменений, чтобы починить быстро то, что завалилось в продакшн. Он не дает инструментов для быстрого тестирования бизнес-критичного функционала.
Так а в чём по вашему проблема с интеграции множества проектов? -Ничего толком не тестируется ни автоматически и ни в ручную.
-Плохая документация и как следствие неверное использование сервисов.
-Не понимают, что требуется реализовать для взаимодействия с другим проектом из-за плохой коммуникации.
Вроде каждую такую проблему по отдельности можно подтянуть, если уделить внимание. Или тут проблема с большими нагрузками именно? Что не могут протестировать всё целиком на highload как следует?
Родион, спасибо за очень хороший вопрос. Основная проблема именно с количеством проверок, которые необходимо запускать перед релизом. В сложных продуктах полный цикл проверок занимает несколько дней, а то и недель. А если что-то не работает и необходимо починить, так вообще затягивается на более долгие сроки, появляется дефицит проверочных сред и т.д. Даже для тех, кто работает с микросервисами в облаке, типа амазон, поднять необходимое количество сред при скоростях, о которых говорит Agile & DevOps, стоит чересчур дорого.
По Agile работают в Кремниевой долине, Facebook, Google, Uber. Это не правда. По Agile работает только некоторая часть команд в Google и Facebook. Скажем так, ни один друг моего друга, работающий в этих двух компаниях, не работает в командах где бы использовался Agile. На вопрос где же у них вот эти все "передовые" технологии управления большинство начинает вспоминать какие-то третьесортные проекты и отвечает что-то в духе: "да, возможно вот в той команде X это используется, но я не уверен, у нас все не так".
А как вы/они определяете Agile в проекте или нет?
Смутила концовка ответа "у нас все не так".
Факт, что передовые технологии, используемые в Facebook, приводят к развалу бизнеса
http://www.zdnet.com/article/facebook-outages-caused-by-failed-software-updates/
Яндекс. Яндекс.Диск Agile + scrum
Чтобы перейти на Аджайл нужно серьёзно перестроить процессы, причём не только в ИТ. Нужно научить заказчика мыслить по Аджайл.
Из опыта - Аджайл + Скрам вполне нормально работает в малых и средне больших проектах.
"Водопад" - прошлый век, как ни крути.
Одна хорошая мысль в статье - про то, что все определяется конкретными людьми. В одном проекте на нужных местах оказались квалифицированные и неравнодушные люди - все полетело, в другом были слабые звенья - зафакапили. На сам факт успеха или не успеха проекта методология может иметь крайне опосредованное отношение, по факту являсь инструментом контроля и оценки сроков.
Про то, что agile имеет ограниченное примерение Асхат, например, говорит минимум с 2008 года (точне я от него это слышал тогда). Причём разные технологии подходят для разных целей. Никто для встроенных систем его не предлагает. Плюс agile даже из названя следует- надо применять вдумчиво, меняя под себя.
Самое же ценное в этой статьи- упоминание того факта, что agile терубет высококвалифицированных работников. Да, это факт- если нанимаете г..кодеров- то не ходите в скрам.
С другой стороны- альтернативай скраму/канбану чаще является бардак и подход "а!!!!! вчера надо сделать, багов дофига, а то, что вы уже отдали заказчику- нифига не то, что надо".
Вообще интересно послушать про поставленные не-agile процессы. Водопад видел, но это вообще трындец- сроки срываются, абгов дофигища, зарезультат не отвечает вообще никто (я только кодил, а что всёразвалилось- не я виноват).
Вы описали что-то, что точно не водопад.
Действительно, уже давно говорят, что Agile подходит не всем. Однако, например, с 2008 распространение Agile увеличилось в 6 раз и будет увеличиваться дальше.
https://www.fullstackpython.com/web-frameworks.html
Алексей, а что вы подразумеваете, говоря "поставленные не-agile процессы”?
Вообще, мне кажется, что разделение на методологии это, что называется «научный подход» который, наверное, хорош для преподавания. В практическом же применении никто и никогда не использует какую-то конкретную методологию. Это всегда некий методологический микс специально создаваемый под задачи проекта и специфику команды. Agile и Scrum, например, и др.
Это и не означает обратного, что данной методологии не придерживаются, а уж в какой мере это другой вопрос. Если вас учили писать без ошибок, а вы сделали опечатку - это не означает, что вы при этом занимались чем то другим по сути.
Если в кране нет воды, то виноват Agile
сам в теме пока не очень шарю, но препод из Нетологии, преподающий в том числе agile-методы, сказал "коротко -статья от человека,не шарящего в теме"
Кстати, от ещё одного препода есть статья про Agile. Примерно теми же словами, но с другими выводами.
http://netology.ru/blog/loveagile
Складывается ощущение, что автор путает теплое с мягким.
http://agilemanifesto.org/iso/ru/principles.html
Agile - это набор принципов. То, что мы держим в голове.
На практике(особенно в разработке ПО) часто применяется так: берем набор принципов Agile + фреймворк Scrum + фреймворк Kanban.
Получает в итоге в рамках спринта наглядность, прогнозируемость, если надо - гибкость.
Идем на уровень выше, где продакт менеджеры планируют развитие продукта. Там можно применить ровно то же самое, только примитивы уже другие. Не конкретные баги/фичи, а, например, user story.
Ivano Ok выше уже расписал с картинкой это.
Какое отношение к Agile имеет плохое тестирование, отсутствие интеграционных или нагрузочных тестов - не понятно.
Пример с проблемами на этапе интеграции нескольких модулей показывает как раз полное расхождение с принципами Agile. По Agile надо было командам, делающим эти модули, собраться и обсудить, КАК и ГДЕ эти модули будут соприкасаться, на более ранних этапах обсудить интерфейсы взаимодействия, как можно раньше и чаще(ритмично) собирать продукт со всеми модулями для обнаружения проблем.
Люди не в курсе за скрам, а вы понятиями как скрам скрамов оперируете.
Наконец-то, думаю чем дальше тем больше таких статей будет. Аджайлом очень сложно реализовать серьёзный проект типа полёта на Марс или разработки новой АПЛ и и.п.
О, годнота подъехала. Очень толково, спасибо!
Спасибо, Владимир!
Методологии имеют описанные методы, процессы имеют описанные процессы. А что имеет Agile? Agile имеет вот это http://agilemanifesto.org/iso/ru/manifesto.html .
молодому человеку не нравится Agile?
Хотел сейчас запостить ссылку на статью на стене)))
Есть ощущение, что автор просто не умеет налаживать гибкие подходы, если компания не совсем маленькая. Ну не получается. И обвиняет в этом подходы
Тестирование тоже нужно уметь налаживать. "От нескольких месяцев до полугода" -- это как раз чудовищная потеря времени. Если это не rocket science, где действительно нельзя весь проект строить на гибких методологиях. Но это и ежу очевидно
Да, если люди не могут работать по скраму, например, то не нужно их мучить. Придется выбирать: или люди, или методология
Сайт у компании Accera еще замечательный. Такие статьи же пишутся в т.ч. для рекламы своей компании и компетенций? На сайте поехавшая верстка и поломанные скрипты на кнопках. И при таком сайтике автор рассуждает о тестировании в больших проектах
"Почему это происходит? При разработке по Agile все делается двухнедельными спринтами"
Хлесткие такие заявления. Как "все мы знаем, что мебель - это стулья". И из этого можно смело делать вывод, что на мебели надо сидеть, а не ставить на нее еду
"при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием"
Вот здесь без прояснения терминологической чехарды с "проблемами", "скоростью поставки" и.т.д. мне лично "простая математика" как-то непонятна. Хотелось бы расшифровки
Буду рад получить конструктивную критику о сайте. Это хороший пример того, когда пользователи могут быть тестерами.
Вообще как консультант по Agile вы слышали, что Scrum, например, при зарождении решал проблемы Waterfall и спасал дигитализацию ФБР? Что по нему первыми начали работать не маленькие стартапы, а фармацевтика, автомобилестроение и подобные более ответственные сферы?
ИМХО, лучшая методология на данный момент — RUP (итеративная модель). Масштабируется, решает многие проблемы продукта ещё до его разработки, почти не имеет недостатков. Главный недостаток — масштабируется она на большую компанию легко, а вот на двух-трёх человек её достаточно сложно натягивать. Но возможно
Статью не читал, но на фотке к новости - скриллекс через 20 лет
Абсолютно! Бизнес - единственная цель IT, соответсвенно Agile
"Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). "
Работаем по скраму, у нас код фриз - за 2 дня до окончания спринта, после этого тестировщики проводят регресс (в идеале должен быть максимально покрыт автотестами, но это по мере возможностей), а разработчикам не разрешено коммитить ничего кроме исправления критичных дефектов. Так что одно другому не мешает.
Вообще, большинство описанных в статье проблем - не проблемы гибких методологий, а проблемы организации установки обновлений и эксплуатации. Если эти процессы грамотно выстроить, чтобы на продуктив попадал только протестированный функционал без критичных багов, скрамы-эджайлы не будут причиной проблем.
Согласен с автором.
Интересно, сколько еще денег должно быть потеряно, репутаций разрушено а продуктов не выпущено, чтобы в it наконец отказались от этой заведомо дефективной, полностью оторванной от реальности, нелепой методологии?
Я не верю в способность наших современников придумать что-то принципиально новое и при этом эффективное в области организации труда.
То, что эти "новые методики" не использовались раньше, свидетельствует о их явной неэффективности. В противном случае Agile и прочий шлак придумал и успешно внедрил бы ещё Генри Форд, а то и Карнеги.
А вы ознакомлены с какой-либо статистикой зафейленных проектов на разных методологиях?
А самое ведь интересное, что если проект с agile - зафейлился (оказался не нужен на рынке или заказчикам и прочее) - то в силу своих принципов унесёт много меньше денег, чем проект с waterfall.
Пока вы собираете требования и планируете то, как это будет сделано в waterfall - ваши конкуренты с agile всё это уже сделают. Как не грустно, но это правда.
немного про статистику:
https://www.infoq.com/articles/standish-chaos-2015
Так чтобы совсем не использовались -- это ведь не правда. Чем, к примеру, серам-митинги отличаются от ежедневных летучек бывших в обыкновении на советских предприятиях?
Ещё раз повторю вопрос- а какая альтернатива?
Водопад? RUP? Без процесса?
И вы мне всё-таки скажите: есть такой процесс, который позволяет с разными (преимущественно средними и посредственными) исполнителями добиваться приемлемых результатов в приемлемые сроки, или-таки нет?
Только не надо задвигать про определение "приемлемых", я вас умоляю!
Если грубо, то "да". Строите любой процесс с действующей обратной связью (той самой, которая корректирует процесс в зависимости от результатов). И тогда обладая "преимущественно средними и посредственными" исполнителями вы будете иметь "работающий посредственный процесс" с "посредственными результатами", достигаемыми с вероятностью "посредственной"*(N+1), где N - длина цепочки в этом "посредственном процессе" до результата.
Это тот самый "приемлемый результат", которого вы ожидаете и на который можете смело рассчитывать. Если параметры результата вас не устраивают, вы меняете "посредственный" (растите внутри или нанимаете) на что-то более хорошее, тем самым улучшая качество процесса, его выхлопа и вероятность, с которой этот выхлоп будет таким.
Аджайл в явном виде конечно гемморно использовать. Но если связать, например, с Канбан, то ситуация становится значительно гибче. Внедрение фич из беклога происходит значительно быстрее. А вот Аджайл + Скрам будет медленнее. Но в российских реалиях, в угоду вредителям-заказчикам, работает только водопад. А вообще примеры не самые лучшие. Гибкие методологии использует, например, тот же Газпром. Но об этом не говорят :sleeping::sleeping:
срам — одно из ответвлений Agile, а Agile — вообще модель
Все описанные проблемы могут возникнуть и при вотерфолле, и при других методологиях. Проблема в том, что скрам — шаблон, который нужно адаптировать под реалии и процессы конкретной компании, поскольку аджайл-методологии в целом про людей, а не только про абстрактные процессы в вакууме. Большие проблемы начинаются как раз-таки когда приходят аджайл-коучи и начинают дрочить людей на своих тренингах, после чего в компаниях появляется Эталонный Скрам:tm: и процессы ради процессов.
В общем, скрамом нужно уметь пользоваться, и контроль качества никто не отменял.