Лого vc.ru

Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому

Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому

Генеральный директор компании Accera, консультант по Agile, DevOps и Digital Transformation Анатолий Шеин написал для vc.ru колонку о том, почему гибкая методология разработки может полностью остановить работу крупного бизнеса, но подходит маленьким стартапам.

Жертвы Agile

Периодически мою ленту в Facebook заполняет поток претензий к некорректной работе банковских сервисов. Обычно жалобы пользователей становятся ответом на плановые релизы — обновления и «улучшения» интернет-банков и мобильных приложений.

Сегодня банки почти повально перешли на работу по гибким методологиям и, разом отказавшись от привычной и проверенной Waterfall, внедряют, почти не глядя, Agile. Это не просто модно — это инновационно, и это же реально работает во многих крутых компаниях. По Agile работают в Кремниевой долине, Facebook, Google, Uber. Да и в России на него подсаживаются не только ИТ-компании, но и, например, Министерство образования и Правительство Москвы.

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

Секрет успеха Agile

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

Совсем по-другому обстояло дело у глобального поставщика телекоммуникационных систем. Компания была на грани срыва поставки нескольких проектов обновления ПО общей стоимостью более $1 миллиона. Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены.

Это не случайность — Agile отлично работает в стартапах, маленьких командах, но на больших проектах, как правило, приводит к большим проблемам: отсрочкам запуска на месяцы и даже полному провалу

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

На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее.

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов. И в этом заключается еще один «большой секрет для маленькой компании» — некоторые стартапы и большие ИТ-компании (преимущественно из Кремниевой долины) могут позволить себе нанимать крутых специалистов. И это еще одна причина, почему у них все работает хорошо. Возможно, будь у этих людей в распоряжении просто лопата, а не самая модная методология, они бы все равно сделали все очень круто.

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

Да, вышеупомянутые Google, Facebook и Uber — это большие компании. И да, они тоже подвержены «болезням» Agile — время от времени все мы это видим сами или читаем жалобы других пользователей — вчера сервис не работал полдня, сегодня был недоступен полчаса и так далее. Но в этих компаниях цепочки работают почти безупречно, и в случае возникновения проблем команда устраняет их очень быстро. Хотя сейчас проблем становится все больше, и даже в условиях четко отлаженной коммуникации сроки их устранения увеличиваются.

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

Agile-провалы больших компаний

Agile очень привлекателен, и перед ним не смогли устоять не только российские банки, но и многие крупные мировые бренды. И почти все они потерпели неудачу или даже хуже.

Например, в июле 2015 года торги на Нью-Йоркской фондовой бирже были остановлены на четыре часа. Первоначальная версия сбоя основывалась на кибератаке, но проблема оказалась всего-навсего в баге во время очередного обновления. Сложно даже представить, во сколько миллиардов обошлись эти четыре часа простоя центра мировой торговли.

Ладно брокеры — сейчас потеряли миллиард, потом заработали два. Но у авиакомпаний совсем другая история. Примерно так же после банального обновления ПО авиакомпании «Дельта» информация перестала поступать в диспетчерскую систему, и все рейсы пришлось отменить. И здесь, кроме прямых убытков, у авиакомпании возникли репутационные проблемы.

Наверное, один из самых громких провалов применения Agile — это запуск известной американской системы медицинского страхования Obama Care

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

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

Obama Care «полетела» примерно через полгода после запуска. Для того, чтобы все заработало, пришлось пригласить внешнего специалиста-консультанта, который смог оценить картину целиком и, начав с конца — с продакшена, постепенно собирал части системы воедино и все-таки добился слаженной работы.

Ловушка Agile

Agile вполне успешно решает проблему Time Delivery. Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта. В случае Obama Care, и это типичный случай, над проектом работало много людей — несколько больших групп — программисты, специалисты, которые отвечали за работу серверов, представители страховых компаний и другие. И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело.

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

Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность, в отличие от Waterfall, где за качество продукта отвечают специально обученные люди. Кроме того, при использовании гибкой методологии проверка качества должна быть максимально автоматизирована, чтобы вся работа уложилась в короткие сроки двухнедельного спринта.

Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). И после этого процесс проверки занимает по времени от нескольких месяцев до полугода.

Из главных принципов Agile вытекают и главные проблемы

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

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

Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи. Но должны ли пользователи выполнять работу Quality Assurance? И почему банки готовы идти на репутационные риски ради Agile?

P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в российских банках. Когда я закончил писать эту статью, то зашел на сайт своего банка в Израиле, и тот оказался недоступен.

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru.

"Во-первых, мы знаем, что общее — это обычно ничьё. Поэтому ответственность за качество продукта нивелируется, и крайнего здесь нет."

А как же прожект менеджеры? Для них это одно из главных качеств. Уложить проект в треугольник..

0

Действительно, менеджеры - "скрам-мастера” и всякие остальные “куры” - отвечают за сроки и содержание. Считается, что качество придёт само собой, стоит только запустить автоматические проверки и, в крайнем случае, благодаря “continuous deployment”, за очень короткие сроки починить в “production” . Этот подход замечательно работает для таких компаний, как Facebook - ну подумаешь, лайк не сработал...

Это прекрасно работает для RTB-рекламных серверов с DMP и прочей доставкой контента.
Пока только инфраструктура напрягает- то фрагмент сети отвалится у провайдера, то диск улетит в мир иной.
Отдела тестирования в той команде нет вообще. Только автотесты. На UI да, бывают баги, но деньги платят не за это.

Наконец-то, думаю чем дальше тем больше таких статей будет. Аджайлом очень сложно реализовать серьёзный проект типа полёта на Марс или разработки новой АПЛ и и.п.

0

Аджайл в явном виде конечно гемморно использовать. Но если связать, например, с Канбан, то ситуация становится значительно гибче. Внедрение фич из беклога происходит значительно быстрее. А вот Аджайл + Скрам будет медленнее. Но в российских реалиях, в угоду вредителям-заказчикам, работает только водопад. А вообще примеры не самые лучшие. Гибкие методологии использует, например, тот же Газпром. Но об этом не говорят 😴😴

0

срам — одно из ответвлений Agile, а Agile — вообще модель

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

Вроде каждую такую проблему по отдельности можно подтянуть, если уделить внимание. Или тут проблема с большими нагрузками именно? Что не могут протестировать всё целиком на highload как следует?

Родион, спасибо за очень хороший вопрос. Основная проблема именно с количеством проверок, которые необходимо запускать перед релизом. В сложных продуктах полный цикл проверок занимает несколько дней, а то и недель. А если что-то не работает и необходимо починить, так вообще затягивается на более долгие сроки, появляется дефицит проверочных сред и т.д. Даже для тех, кто работает с микросервисами в облаке, типа амазон, поднять необходимое количество сред при скоростях, о которых говорит Agile & DevOps, стоит чересчур дорого.

0

Убер нагрузочные тесты акциями проводит, например )

> говорит о дигитализации
Иксперд был пьян...
владение рузки йзика на высоте

Agile - это НЕ МЕТОДОЛОГИЯ и НЕ ПРОЦЕСС! Проявите наконец компетенцию, а если не разбираетесь, ну зачем писать???? Громкое название статьи, но нет конкретики. Жертва - тот кто пал с концами. Падения на биржах были и из-за "высококачественных" вотерфольных проектов. И банки так же этим страдали. Так все таки кто жертва Agile ??

Вы, судя по всему, разбираетесь. Что же тогда - Agile?)

Методологии имеют описанные методы, процессы имеют описанные процессы. А что имеет Agile? Agile имеет вот это agilemanifesto.org/iso/ru/manifesto.html

Это набор принципов.
А вот добрая часть доморощенных agile-экспертов по-моему не читали манифест и под эджайлом понимают какие-то методички по скраму.

Кстати, Dmitry Dzhafarov действительно прав :-) Строго говоря, "Agile Software Development” не является ни методологией, ни процессом, а простым набором принципов. Однако за почти 20 лет существования понятие Agile превратилось в собирательное, например en.wikipedia.org/wiki/Agile_management

Методологии имеют описанные методы, процессы имеют описанные процессы. А что имеет Agile? Agile имеет вот это agilemanifesto.org/iso/ru/manifesto.html .

0

молодому человеку не нравится Agile?

0

Если речь про меня - мне нравится-)

0

что нравится-то?))

Чтобы перейти на Аджайл нужно серьёзно перестроить процессы, причём не только в ИТ. Нужно научить заказчика мыслить по Аджайл.
Из опыта - Аджайл + Скрам вполне нормально работает в малых и средне больших проектах.
"Водопад" - прошлый век, как ни крути.

> По Agile работают в Кремниевой долине, Facebook, Google, Uber.
Это не правда. По Agile работает только некоторая часть команд в Google и Facebook. Скажем так, ни один друг моего друга, работающий в этих двух компаниях, не работает в командах где бы использовался Agile. На вопрос где же у них вот эти все "передовые" технологии управления большинство начинает вспоминать какие-то третьесортные проекты и отвечает что-то в духе: "да, возможно вот в той команде X это используется, но я не уверен, у нас все не так".

0

Факт, что передовые технологии, используемые в Facebook, приводят к развалу бизнеса
www.zdnet.com/article/facebook-outages-caused-by-failed-software-updates/

0

А как вы/они определяете Agile в проекте или нет?
Смутила концовка ответа "у нас все не так".

0

> А как вы/они определяете Agile в проекте или нет?
Подходил и спрашивал у менеджеров что они думают об Agile/Scrum.

> Смутила концовка ответа "у нас все не так".
Друзья друзей работают над большими проектами. Т.к. сейчас я нахожусь в команде где практикуется Scrum и мне уже надоело ругаться с начальством о том что весь проект состоит из костылей и подпорок, то при выборе новой команды хотелось быть уверенным что в команде не будет Agile, а будет нормальное планирование на 2-3 года, как было в предыдущей команде.

0

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

Иногда для проверок идей вставляют костыли и подпорки, но после этого постоянно и постепенно рефакторят код (если читать про хороший путь), чтобы он не оставался сделанным из костылей. Но тут обычно начинаются проблемы с командой их agile-mindset. Как таковое, команда сама решает что будет использовать: костыли\ костыли + рефакторинг\ красивый код; так как только она отвечает за техническую реализацию фичей.

Просто не повезло с командой и\или начальством.

p.s.: у меня знакомая работает в facebook (почти как у вас, только на 1 рукопожатие меньше). У них свой agile, но совсем не scrum. Есть итерации, есть планирование.

> Иногда для проверок идей вставляют костыли и подпорки, но после этого постоянно и постепенно рефакторят код (если читать про хороший путь), чтобы он не оставался сделанным из костылей. Но тут обычно начинаются проблемы с командой их agile-mindset. Как таковое, команда сама решает что будет использовать: костыли\ костыли + рефакторинг\ красивый код; так как только она отвечает за техническую реализацию фичей.
Но это же не работает. Это в теории только так. Приходишь на совещание и слушаешь весь этот булшит про то как все будет хорошо, а на практике невозоможно ничего рефакторить. Я 3,5 месяца рефакторил интерфейс работы с БД, какие тут могут быть спринты по 2 недели? Возможно приложение для iOS или Android можно клепать с такой скоростью, но скедулер кластера релизить так не получится. Это ядро системы. Я трачу 3 часа в неделю на совещания/планирование и прочее бла-бла-бла только потому что нужно разбить огромные задачи на подзадачи. Это же бред.

> p.s.: у меня знакомая работает в facebook (почти как у вас, только на 1 рукопожатие меньше). У них свой agile, но совсем не scrum. Есть итерации, есть планирование.
Опять же, это зависит от отдела. В одном только лондонском офисе fb работает 14 моих бывших коллег, включая одного из бывших начальников. В US не могу точно сказать количество, но с некоторыми успел поработать даже в двух местах :)

Про то, что agile имеет ограниченное примерение Асхат, например, говорит минимум с 2008 года (точне я от него это слышал тогда). Причём разные технологии подходят для разных целей. Никто для встроенных систем его не предлагает. Плюс agile даже из названя следует- надо применять вдумчиво, меняя под себя.

Самое же ценное в этой статьи- упоминание того факта, что agile терубет высококвалифицированных работников. Да, это факт- если нанимаете г..кодеров- то не ходите в скрам.

С другой стороны- альтернативай скраму/канбану чаще является бардак и подход "а!!!!! вчера надо сделать, багов дофига, а то, что вы уже отдали заказчику- нифига не то, что надо".

Вообще интересно послушать про поставленные не-agile процессы. Водопад видел, но это вообще трындец- сроки срываются, абгов дофигища, зарезультат не отвечает вообще никто (я только кодил, а что всёразвалилось- не я виноват).

Вы описали что-то, что точно не водопад.

0

Я видел и водопад и "вчера". Это разные вещи.
Но кроме agile, водопада и "вчера" я больше реально процессов разработки не видел.
Даже когда писал софт для встроенных систем для меня это был agile - просто заказчиком выступал создатель железа, а заливал я на стенд иногда по 20 раз в день.

Вот и интересно- а чтоесть _лучше agile? Водопад и "вчера" точно хуже.

0

То, что вы видели как водопад - это не так. Если в конце этапа обнаружили, что не достигли требуемого качества (баги), то продлевают срок этапа на устранение дефектов и дальше проект не идет, а ждет окончания этапа. Поэтому и баги и сорванные сроки не могут быть одновременно. И за результат проекта как раз отвечает и не разработчик, и не бизнес-заказчик, а менеджер, вся работа которого сводится только к несению персональной ответственности.

Да, продлевали этап. Только багиприлетали ещё из продакшна, и чинились они, естественно, "вчера", в отдельной ветке (ага, это ж год назад выпустили).
Классический водопад быстро срубили (сначала были даже отдельные проектировщики, которые код не писали, а только думали архитектуру), но на полный agile так и не перешли.
А оотдельный ответственнй (зиц-председатель) это забавно, но что толку-то?

0

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

"Если в конце этапа обнаружили, что не достигли требуемого качества (баги), то продлевают срок этапа на устранение дефектов и дальше проект не идет, а ждет окончания этапа."

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

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

Невозможно отыскать абсолютно все ошибки в программном продукте:
- Ошибки остаются всегда.
- Построение исчерпывающего входного теста невозможно.
(www.4stud.info/software-construction-and-testing/lecture7.html)

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

0

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

Аналогично рассуждая, если в прод выехали с багами (что в общем-то не всегда плохо) и при этом команда говорит, что она тут не причём - то это тоже не Agile.
Команда отвечает за свой продукт, иначе это противоречит сути Agile. А следовательно - это раздолбайство, прикрываемое Agile.

0

Действительно, уже давно говорят, что Agile подходит не всем. Однако, например, с 2008 распространение Agile увеличилось в 6 раз и будет увеличиваться дальше.
www.fullstackpython.com/web-frameworks.html

Алексей, а что вы подразумеваете, говоря "поставленные не-agile процессы”?

0

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

PS: разрабатывал для банка по смеси scrum'а и cunban'а, кстати. Вроде все группы использовали только agile, хотя не до конца уверен.

Чтобы Agile подходил для банка, он должен обращать внимание на качество в интегральных средах. Самое простое и самое дорогое решение - гонять все тесты (и ручные и автоматические) сразу же по окончании разработки фичи. Другой способ - сдвинуть влево проверки, которые обычно проводятся в интегральных средах, и подготовить инструменты для программистов, чтобы запускать эти тесты. Такими инструментами являются, например, Cucumber и Vagrant. Еще один из вариантов - Service Virtualization. Можно и все вместе.

под Agile принято сметать весь тот бардак в компании, с которым проект встречается задолго до разработки.

Если есть рабочие примеры agile у больших компаний, как фб, гугл, значит ли это что он не для крупняков?

Заголовок надо поправить на "бардак губит крупный бизнес".

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

- Как правило про аджайл, скрам и канбан пишут люди, которые про это не то что не читали, а считают все это одним и тем же.
- Это работает на западе, потому что выстроен процесс вокруг что я делал вчера? Что я делаю сегодня? Что буду делать завтра. И как это все улучшить каждый день. Это будет работать, если каждый в команде будет задавать этот вопрос прежде всего самому себе. Более того, я решал 90% проблем за первую неделю, как Продакт Менеджер, просто применяя скрамбан. Увеличение производительности было на уровне 200-300%, при этом не было поиска виноватых и промахов на уровне: -"я сидел ждал пока Петя сделает то и нифига не делал". Каждую неделю надо следить за тем чтобы не допускать моментов, что кто-то блокирует работу, кто-то не работает и так далее.
- Чем Agile/Scrum/Kanban всем не нравиться по моему опыту, это тем что надо работать, включаться в процесс, каждый день отвечать за то что ты делаешь и улучшать это, такой ритм не для всех подходит, но это тоже одна из фишек скрама, безболезненно улучшить процессы и убирать не нужных людей из проекта.
- Для всего этого нужен крутой Product Manager/Product Owner, которые не будут заниматься мастурбацией, а будут выстраивать продукт изначально выстроив правильные Agile/Scrum процессы.

Для тех кто все таки не читал, но осуждает, прочитайте книгу Джеффа Сазерленда - SCRUM.

Попытки обвинить инструмент в том, что исполнители и их руководители - недисциплинированные идиоты, очень наглядно характеризует авторов таких статей. Не вдаваясь даже в подробности, что есть совмещенные Waterflow и Agile фреймворки, как раз для больших государственных и бизнес-организаций, типа Prince 2 Agile.

Согласен с автором.

Интересно, сколько еще денег должно быть потеряно, репутаций разрушено а продуктов не выпущено, чтобы в it наконец отказались от этой заведомо дефективной, полностью оторванной от реальности, нелепой методологии?

Я не верю в способность наших современников придумать что-то принципиально новое и при этом эффективное в области организации труда.

То, что эти "новые методики" не использовались раньше, свидетельствует о их явной неэффективности. В противном случае Agile и прочий шлак придумал и успешно внедрил бы ещё Генри Форд, а то и Карнеги.

0

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

Отличный пример! ;-) Советское производство славилось качеством и эффективностью.

Советская индустрия дала миру Sputnik, корабли "Союз", ракету-носитель "Протон" и т.д. Меня неизменно смущает, что в дискурсе о методологиях и подходах успешных стартапов совсем не находится внимания для советских супер-стартапов. Как людям удалось их организовать разработку этих по-настоящему инновационных систем, свести вместе труд тысяч специалистов? Наверно, не совсем бессмысленные управленческие методологии использовались.

"Советская" индустрия (полностью созданная западными специалистами, см. историю "индустриализации" и далее со всеми остановками) ничего не дала рядовому обывателю и развалилась вместе с СССР как гнилая колода четверть века назад.

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

0

Ещё раз повторю вопрос- а какая альтернатива?
Водопад? RUP? Без процесса?

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

Разумеется, никакая методология сама по себе задач не решает. Но в рамках Водопада реализовать грамотное планирование и качественное производство гораздо проще.

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

Как вы думаете для чего люди придумали итеративные модели разработки, если каскадная позволяет и планировать лучше и качество обеспечивать?

Это даже странно обсуждать. Даже в текущем стандарте PMI нет каскадной модели в чистом виде.

0

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

О результатах такого подхода можно почитать в статье выше.

0

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

"Инновации", кот. возникают ВНЕ, а не ВНУТРИ работающего бизнеса, создаются далёкими от реальной работы (и ответственности) людьми, начинают агрессивно внедряться в сложившиеся и эффективно работающие структуры, преследуют единственную цель - обогащение создателей.

Кто придумал Agile Manifesto? Чего добились его авторы? Какие сервисы и продукты они создали? Какие компании построили с нуля собственным трудом?

Небольшая цитата: "Agile Alliance supports people who explore and apply Agile values, principles..." Т.е. Альянс поддерживает тех, кто разделяет ценности Альянса, не более того.

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

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

Чтобы самолёты летали, торги не останавливались, страховые полисы выдавались вовремя.

Грамотное планирование, разработка, выкатка, фигак – а твой продукт рынку не нужен. И что делать будем? :)

0

До какой степени нужно НЕ иметь представления о рынке и его потребностях, чтобы твоя "гениальная" идея оказывается никому не нужна спустя 6-12 месяцев, кот. занимает разработка?

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

0

Но ведь Agile тоже не собирается параллельно строить мансарду и первый этаж.

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

В вашем же случае: мансарда не имеет ценность без пути к ней, первый этаж - тоже не имеет ценности, так как непонятна его планировка. Поэтому первым делом будет взят Заказчик дома, хорошие специалисты и будет обговорён некоторый план того, что он хочет (получит некий Backlog), и наиболее важные моменты, которые нужны нам на ближайший спринт (Product backlog). Никто не будет строить параллельно разные части дома, или менять местами причинно следственные связи в этом мире только потому, что это Agile.

Принципы Agile можно прочитать тут: agilemanifesto.org/iso/ru/principles.html

Картинку посмотреть, и статью прочитать о том, как разрабатывается продукт по Agie, можно прочитать тут: netology.ru/blog/loveagile

0

Смотрел я эти принципы. :-)

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

По поводу второй ссылки: "Предположим, тестировщики нашли в продукте серьезные ошибки, и его нужно перепроектировать." Т.е. за все этапы ДО тестирования отвечали кретины, которые позволили критическим, фатальным ошибкам пройти стадию анализа, планирования и разработки?! Боюсь, такой команде никакая методология не поможет.

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

0

Как тестированию, скажу вам интересную статистику: там где были аналитики, которые-то генерировали требования и описание задач на спирт! (То есть не очень большие задачи), разработчики часто интерпретировались требования неправильно! Они даже не общались с аналитиками по этому поводу, потому что считали, что поняли все правильно. - каждая третья задача, уровень недопонимания отличается: от мелких правок, до изменения логики.
А представьте в waterfall на полгода-год. Через год оказывается, что ты неправильно понял требования и сделал не так. Тадам!

0

Пример по существу, такая проблема имеет место. Но это не вопрос методологии, это вопрос организации нормальной коммуникации внутри компании, сфера ответственности менеджеров.

Я сам часто сталкивался с ленью (нежеланием обсуждать), а то и стремлением самовольно "улучшать" со стороны разработчиков. Лечится максимально точными формулировками, нормальной постановкой задачи (подробное описание, чек-листы, интерактивный прототип) и ежедневным наблюдением над процессом.

Нормальный менеджер изначально должен исходить из того, что задачу поймут неправильно, смотреть на её формулировку прежде всего под этим углом, замечать и устранять невнятные формулировки.

0

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

Пожалуй добавлю целый абзац из последней книги, которую я прочитал о командной работе:
"Как все это связано со следующим пороком – безразличием к результатам? Если члены команды не несут ответственности за свой вклад в общее дело, то они больше внимания уделяют своим собственным делам, своей карьере. Именно с отсутствия требовательности и взаимного контроля начинается равнодушие к успеху команды и безразличие к достижению результатов."
( Пять пороков команды. Притчи о лидерстве. )

0

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

Стремление уделять повышенное внимание своим делам и своей карьере естественно и нормально. Не стоит идеализировать людей и пытаться менять их приоритеты.

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

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

А вы ознакомлены с какой-либо статистикой зафейленных проектов на разных методологиях?

А самое ведь интересное, что если проект с agile - зафейлился (оказался не нужен на рынке или заказчикам и прочее) - то в силу своих принципов унесёт много меньше денег, чем проект с waterfall.

Пока вы собираете требования и планируете то, как это будет сделано в waterfall - ваши конкуренты с agile всё это уже сделают. Как не грустно, но это правда.

немного про статистику:
www.infoq.com/articles/standish-chaos-2015

Вообще, мне кажется, что разделение на методологии это, что называется «научный подход» который, наверное, хорош для преподавания. В практическом же применении никто и никогда не использует какую-то конкретную методологию. Это всегда некий методологический микс специально создаваемый под задачи проекта и специфику команды. Agile и Scrum, например, и др.

0

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

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

Складывается ощущение, что автор путает теплое с мягким.
agilemanifesto.org/iso/ru/principles.html
Agile - это набор принципов. То, что мы держим в голове.
На практике(особенно в разработке ПО) часто применяется так: берем набор принципов Agile + фреймворк Scrum + фреймворк Kanban.
Получает в итоге в рамках спринта наглядность, прогнозируемость, если надо - гибкость.

Идем на уровень выше, где продакт менеджеры планируют развитие продукта. Там можно применить ровно то же самое, только примитивы уже другие. Не конкретные баги/фичи, а, например, user story.
Ivano Ok выше уже расписал с картинкой это.

Какое отношение к Agile имеет плохое тестирование, отсутствие интеграционных или нагрузочных тестов - не понятно.

Пример с проблемами на этапе интеграции нескольких модулей показывает как раз полное расхождение с принципами Agile. По Agile надо было командам, делающим эти модули, собраться и обсудить, КАК и ГДЕ эти модули будут соприкасаться, на более ранних этапах обсудить интерфейсы взаимодействия, как можно раньше и чаще(ритмично) собирать продукт со всеми модулями для обнаружения проблем.

Люди не в курсе за скрам, а вы понятиями как скрам скрамов оперируете.

Если в кране нет воды, то виноват Agile

Сдается мне, что все доводы построены на заблуждении: "Ловушка в том, что он решает проблему скорости, упуская при этом вопрос качества выпускаемого продукта.".

Потому что, говоря о разработке программного обеспечения время доставки ценности может быль маленьким если обеспечивается Качество продукта. А Качество продукта обеспечивается Качеством процесса. И инженерные техники eXtrem Programming (Парное программирование, Тесты первыми (TDD) , Непрерывная интеграция, Рефакторинг) направлены в первую очередь на обеспечение Качества продукта.

Если под Agile понимать только спринты, летучки, игры в планирование то конечно это не будет работать. Гибкая разработка ПО это не всегда ДЕШЕВО, БЫСТРО. Это НЕ ДЕШЕВО, это только иллюзия что быстро, потому что результат доставляется кусочками и можно корректировать развитие. НО за все нужно платить. Поэтому нужны автотесты, нужен TDD, нужна непрерывная интеграция, нужны автоматические приемочные тесты, нужен рефакторинг. И если что-то выкинули "это очень дорого для нас", то готовьтесь к тому что после внедрения будут проблемы.

И чтобы потом не обвинять "Это не мы виноваты, это Agile у нас не работает", Используйте простое правило:

Качество превыше всего.

Улучшая качество, вы улучшите процессы и скорость доставки доставки ценности.

0

Все описанные проблемы могут возникнуть и при вотерфолле, и при других методологиях. Проблема в том, что скрам — шаблон, который нужно адаптировать под реалии и процессы конкретной компании, поскольку аджайл-методологии в целом про людей, а не только про абстрактные процессы в вакууме. Большие проблемы начинаются как раз-таки когда приходят аджайл-коучи и начинают дрочить людей на своих тренингах, после чего в компаниях появляется Эталонный Скрам™ и процессы ради процессов.
В общем, скрамом нужно уметь пользоваться, и контроль качества никто не отменял.

0

И вы мне всё-таки скажите: есть такой процесс, который позволяет с разными (преимущественно средними и посредственными) исполнителями добиваться приемлемых результатов в приемлемые сроки, или-таки нет?

Только не надо задвигать про определение "приемлемых", я вас умоляю!

Если грубо, то "да". Строите любой процесс с действующей обратной связью (той самой, которая корректирует процесс в зависимости от результатов). И тогда обладая "преимущественно средними и посредственными" исполнителями вы будете иметь "работающий посредственный процесс" с "посредственными результатами", достигаемыми с вероятностью "посредственной"*(N+1), где N - длина цепочки в этом "посредственном процессе" до результата.

Это тот самый "приемлемый результат", которого вы ожидаете и на который можете смело рассчитывать. Если параметры результата вас не устраивают, вы меняете "посредственный" (растите внутри или нанимаете) на что-то более хорошее, тем самым улучшая качество процесса, его выхлопа и вероятность, с которой этот выхлоп будет таким.

0

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

Статья не дает ответа на вопрос, какая связь между Agile и отсутствием тестирования бизнес-критичного функционала при релизе

0

Голый Agile говорит об автоматических тестах и скорости изменений, чтобы починить быстро то, что завалилось в продакшн. Он не дает инструментов для быстрого тестирования бизнес-критичного функционала.

0

Не уверен, что бизнес-критикал работает - не релизь.
Нет времени убеждаться - не вали потом на Agile.

Коли зашёл разговор о тестах, то мне как тестеру было бы интересно получить пару ответов:

1) "Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены." (с)
- А чем эти тесты занимались раньше, как и что они тестировали до этого момента?
- Что понимается под "реальной базой данных"? Если это база с прода, то что мешало сделать копию и тестировать на ней изначально?
- Как проверялась работоспособность продукта? Ведь это основная ценность agile.

В целом крайне похоже на историю с водопадом, когда люди делали-делали, а потом начинают тестировать и понеслось...

2) "По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше."
На сайте говорится "They have 24 times faster recovery times and three times lower change failure rates." - что относится к fail/success самих билдов больше, чем количеству багов в билде (если я умею английский и осознал смысл происходящего).
(ваша ссылка puppet.com/resources/white-paper/2016-state-of-devops-report)

Статистика в общем-то говорит о влиянии DevOps практик на результат команд, судя из названия статьи, а не сравнивает Waterfall и Agile. Насколько я понял, интернет говорит, что "DevOps + waterfall != love", и вряд ли где-то это реально работает вместе. А следовательно данная статистика скорее всего говорит о том, как разнятся данные в самих Agile компаниях, что частично подтверждается формулировкой наиболее продуктивные и наименее продуктивные в этом пункте "High-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times."

О DevOps + waterfall:
techbeacon.com/devops-waterfall-dont-waste-your-time

3) "На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее."

Да, работы прибавляется. Но она пропорциональна изменениям в релизе. Не уверен про уменьшение количества проблем в 3 раза - о чём я писал в п.2. Разница в скорости поставки выглядит правдоподобной.
Если говорить о проблемах в этих "небольших изменениях" - то QA в силу размера изменений достаточно быстро даёт фидбек разработчикам, которые всё ещё в контексте проблемы, что приводит к более быстрым фиксам и меньшим постэффектам, но всякое бывает и зависит от сложности кода.
Следовательно вопросы таковы:
- почему в данной моделе тестирование стало особняком от деятельности команды, так как в Agile нет отдельного этапа тестирования, там говорится о доставке продукта? Да и в Agile в команде разработки есть "член команды", там нет выделенной роли QA. Она разделена между всеми членами команды и одним "эекспертом в этой области", если он есть.
- почему число 60, являясь результатом работы QA службы, становится показателем нагрузки на неё же?
- тестеры вполне себе могли не успевать проверить сисетму в waterfall, так как на этапе разработки/интеграции у разработчиков возникали проблемы, что отъедало время тестирования. А менеджеры принимали решение провести сколько успеем, что бы войти в бюджет. Где принципиальная разница?

4) "Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов." (с)
и "Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность..." (с)
- почему эти высказывания противоречат друг другу?

5) "И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело."
- Почему пробелемы в коммуникациях стали проблемой только в Agile?
В Agile нет как-такого деления "своя работа" - у всей команы есть продукт "obama care", и то что никто ни разу не попробовал его запустить целиком до окончания разработки - это как раз не Agile. Ибо у них не было рабочего продукта (главная ценность и показатель прогресса в Agile) практически до конца разработки. Пока это выглядит как waterfall - каждая команда собрала требования, "реализовала свою часть хорошо", а потом оказалось, что всё не работает. Нет той пресловутой проверки "работоспособности продукта" на каждом этапе.

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

7) "Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз."
Agile говорит, что проверять надо постоянно работоспособность продукта, а не работоспособность компонента.
- проблема в понимании тестирования, а не в Agile.

8) "А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента."
- Почему вы решили, что Agile запрещает создавать тесты более высоких уровней: интеграционных и системных? Что бы добиться высокой скорости - рутинную работа автоматизируют, но то, то автоматизация заключается исключительно в unit тестах это проблема конкретной команды\ проекта\ компании. Видимо они не слушают тестеровщиков или изрядно на них экономят. Но это никак не связано в Agile напрямую, скорее как и везде "авось и без них справимся, все же код писать умеем".

9) "Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи."
Такое случается, когда тестирования нет или оно выполняется абы как.
- Говорит ли Agile что-нибудь о том, как и что надо тестировать?

В общем, вся статься похожа на кране забавный пример того, как кого-то начал делать старые дела на новый лад, назвал это Agile (ну ведь не waterfall же? а если не он, то получается это уже Agile!), и при этом у него так как все проблемы скатываются к тому, что:
- Если проект работает не по waterfall, то стиль его работы автоматически подпадает у вас под определение Agile. А это не так! Смотрите видео
(Как понять, что Agile работает | habrahabr.ru/company/oleg-bunin/blog/309878/ )
- Никто не понимает, что такое Agile - но все по нему работают =)
- Все считают, что привычки и mindset людей при добавлении стендапов моментально меняется - а вот и нет.
- вместо продукта в целом, команды\проекты думают только о своём компоненте (в общем-то, как и в Waterfall). Тестеры же всё равно проверят в конце!
- тестирование реализовано кусочно: unit тесты уже хорошо, но всё ещё не достаточно. Проблема всех и вся.
- P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в Agile компания. +__+

Очень печально, что такие псевдоэкспертные статьи выносятся редакторами на публику.
Весь посыл статьи, Agile не работает у больших компаний, потому что есть примеры фейлов. Во-первых, я бы подробнее разобрал эти фейлы, ну даже если принять их, то , во-вторых, назовите мне принципы/подход/методологию/процесс и Пр. , с которыми не было фейлов. С тем же вотерфоллом фейлов не меньше уж точно.
Ну вы сами себя послушайте? "Тестирование становится сложным"- это же прямое противоречие тому, что пишите сами. В вотерфолле тестирование на порядок сложнее, более трудоемкое и вероятность пропустить ошибку выше.
Да, есть задачи, которые аджайлом не покрыть- строительство атомой станции итерациями и "фаст фейлом" не построить, но не надо говорить про "все" большие корпорации, банки в том числе. Любую хорошую идею можно утопить.

0

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

0

> Однако Agile в комплексных проектах приводит к потере равновесия между частотой изменений и частотой тестов

Почему же? Если так случается, то ценность поставки "работающего продукта" теряется и это уже не agile, а "фигак-фигак-и в продакшн".

Хотел сейчас запостить ссылку на статью на стене)))

Есть ощущение, что автор просто не умеет налаживать гибкие подходы, если компания не совсем маленькая. Ну не получается. И обвиняет в этом подходы

Тестирование тоже нужно уметь налаживать. "От нескольких месяцев до полугода" -- это как раз чудовищная потеря времени. Если это не rocket science, где действительно нельзя весь проект строить на гибких методологиях. Но это и ежу очевидно

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

Сайт у компании Accera еще замечательный. Такие статьи же пишутся в т.ч. для рекламы своей компании и компетенций? На сайте поехавшая верстка и поломанные скрипты на кнопках. И при таком сайтике автор рассуждает о тестировании в больших проектах

"Почему это происходит? При разработке по Agile все делается двухнедельными спринтами"
Хлесткие такие заявления. Как "все мы знаем, что мебель - это стулья". И из этого можно смело делать вывод, что на мебели надо сидеть, а не ставить на нее еду

"при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием"
Вот здесь без прояснения терминологической чехарды с "проблемами", "скоростью поставки" и.т.д. мне лично "простая математика" как-то непонятна. Хотелось бы расшифровки

0

Буду рад получить конструктивную критику о сайте. Это хороший пример того, когда пользователи могут быть тестерами.

Вообще как консультант по Agile вы слышали, что Scrum, например, при зарождении решал проблемы Waterfall и спасал дигитализацию ФБР? Что по нему первыми начали работать не маленькие стартапы, а фармацевтика, автомобилестроение и подобные более ответственные сферы?

ИМХО, лучшая методология на данный момент — RUP (итеративная модель). Масштабируется, решает многие проблемы продукта ещё до его разработки, почти не имеет недостатков. Главный недостаток — масштабируется она на большую компанию легко, а вот на двух-трёх человек её достаточно сложно натягивать. Но возможно

сам в теме пока не очень шарю, но препод из Нетологии, преподающий в том числе agile-методы, сказал "коротко -статья от человека,не шарящего в теме"

0

Кстати, от ещё одного препода есть статья про Agile. Примерно теми же словами, но с другими выводами.

netology.ru/blog/loveagile

Статью не читал, но на фотке к новости - скриллекс через 20 лет

Абсолютно! Бизнес - единственная цель IT, соответсвенно Agile

"Для сравнения, при работе по Waterfall тестирование происходит в самом конце — код стабилизируется (code freeze) и все изменения и доработки исключены (кроме исправления ошибок). "

Работаем по скраму, у нас код фриз - за 2 дня до окончания спринта, после этого тестировщики проводят регресс (в идеале должен быть максимально покрыт автотестами, но это по мере возможностей), а разработчикам не разрешено коммитить ничего кроме исправления критичных дефектов. Так что одно другому не мешает.

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

Прямой эфир
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления