{"id":13642,"url":"\/distributions\/13642\/click?bit=1&hash=b1d04d123bef3157778955d4fff0f37b6ea4b9628be659b0252c803d9c42eced","title":"\u0412\u044b \u0441\u0430\u043c\u043e\u0437\u0430\u043d\u044f\u0442\u044b\u0439? \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0430\u0442\u044c \u043d\u0430 \u00ab\u042f\u043d\u0434\u0435\u043a\u0441 \u041c\u0430\u0440\u043a\u0435\u0442\u0435\u00bb","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"7b44ef31-f829-53ec-90f8-add9595cf252","isPaidAndBannersEnabled":false}
Офтоп
Редакция vc.ru

Жертвы 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. Справедливости ради стоит отметить, что такие проблемы существуют не только в российских банках. Когда я закончил писать эту статью, то зашел на сайт своего банка в Израиле, и тот оказался недоступен.

0
93 комментария
Написать комментарий...
Dmitry Dzhafarov

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

Ответить
Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
Dmitry Mintz

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

Ответить
Развернуть ветку
2 комментария

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

Развернуть ветку
Max Yeremenko

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

Ответить
Развернуть ветку
Vitaly Vishnevsky

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

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

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

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

Развернуть ветку
Тимур Харисов

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

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

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

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

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

Развернуть ветку
Viacheslav Potemkin

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

Ответить
Развернуть ветку
Екатерина Тихомирова

Хорошая статья :thumbsup:

Ответить
Развернуть ветку
Anatoly Shein

Спасибо, Екатерина !

Ответить
Развернуть ветку
Alekseev Sergey

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

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

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

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

Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
1 комментарий
Alexey Vasilyev

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

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

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

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

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

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

Ответить
Развернуть ветку
Rauf Enikeev

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

Ответить
Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
1 комментарий
Семен Смирнов

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

Ответить
Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
2 комментария
Родион Кулин

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

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

Ответить
Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
1 комментарий

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

Развернуть ветку

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

Развернуть ветку
Гала Перидоловна
По Agile работают в Кремниевой долине, Facebook, Google, Uber.

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

Ответить
Развернуть ветку
Ivan Trechyokas

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

Ответить
Развернуть ветку
3 комментария
Anatoly Shein

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

Ответить
Развернуть ветку
Михаил Алилеков

Яндекс. Яндекс.Диск Agile + scrum

Ответить
Развернуть ветку
Aleksandrs Zaharovs

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

Ответить
Развернуть ветку
Вадим Жогальский

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

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

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

Развернуть ветку

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

Развернуть ветку
Алексей Томин

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

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

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

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

Ответить
Развернуть ветку
Prolis Labkk

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

Ответить
Развернуть ветку
7 комментариев
Anatoly Shein

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

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

Ответить
Развернуть ветку
2 комментария
Dmitry Mintz

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

Ответить
Развернуть ветку
Shadlance Darking

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

Ответить
Развернуть ветку
Дмитрий Беспалов

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

Ответить
Развернуть ветку
†Deathcore

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

Ответить
Развернуть ветку
Ivan Trechyokas

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

http://netology.ru/blog/loveagile

Ответить
Развернуть ветку
Дмитрий Арбузов

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

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

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

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

Ответить
Развернуть ветку
Vitaly Vishnevsky

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

Ответить
Развернуть ветку
Барбос Барбосыч

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

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

О, годнота подъехала. Очень толково, спасибо!

Ответить
Развернуть ветку
Anatoly Shein

Спасибо, Владимир!

Ответить
Развернуть ветку
Dmitry Dzhafarov

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

Ответить
Развернуть ветку
Elena Sokolova

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

Ответить
Развернуть ветку
2 комментария
Кемал Тамбиев

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Anatoly Shein

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

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

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

Ответить
Развернуть ветку
Mark Rapida Gromov

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

Ответить
Развернуть ветку
Максим Иващенко

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

Ответить
Развернуть ветку
Anatoly Shein

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

Ответить
Развернуть ветку
Dmitry Orlov

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

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

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

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

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

Развернуть ветку
Ilya Gorozhankin

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

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

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

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

Ответить
Развернуть ветку
Ivan Trechyokas

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

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

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

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

Ответить
Развернуть ветку
Alexey Nacharov

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

Ответить
Развернуть ветку
3 комментария
Алексей Томин

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

Ответить
Развернуть ветку
12 комментариев

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

Развернуть ветку

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

Развернуть ветку

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

Развернуть ветку
m0NKey bR4in

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

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

Ответить
Развернуть ветку
Alexander Zakharov

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

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

Ответить
Развернуть ветку
1 комментарий
Павел Сайк

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

Ответить
Развернуть ветку
Mark Rapida Gromov

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

Ответить
Развернуть ветку
Денис Токарев

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

Ответить
Развернуть ветку
Читать все 93 комментария
null