Прибыль на нервах айтишников или Почему капиталистический Agile победил социалистический Waterfall

Почему Аджайл выигрывает у Ватерфолла?

Agile методологии (aka «тяп-ляп и готово») уже давно стали де-факто стандартом разработки софта. В некогда солидной сфере IT, которая брала свои истоки от классической инженерии, где планировался и предугадывался каждый шаг, стала теперь по сути игрой без правил. Что заказчик хочет — то и творит.

Если еще пару десятилетий назад тотальное большинство программ разрабатывалось по надежной (но потому и более дорогой) каскадной методологии — Waterfall, то в начале двухтысячных разжирневшему на IT бизнесу потребовалась более гибкая методика клепания софта, которая бы заменила закостенелые «академические» методики и позволила бы быстрее перестраивать софт под сиюминутные хотелки заказчика. Так появилась целая плеяда методологий разработки, объединенных в одно коварное слово Agile.

SCRUM (он же скрам/срам) — это фреймворк, следующий принципам Agile, который и должен был описать и структурировать новый подход к разработке ПО. А именно:

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

Если вас, прочитав эти слова, не стало тошнить радугой, то скорее всего вы:
1) Бесконечно далеки от разработки программного обеспечения
2) Вы — Agile-коуч (то бишь нахлебник, паразитирующий на бесчеловечных методологиях выжимания соков из работников)
3) Вы — программист-мазохист

Как программисты сами загнали себя в клетку Agile, Scrum и спринтов, а также практики «писать код, думая о бизнесе»

Кто платит, тот и заказывает музыку
Для бизнеса Agile выгоден, иначе бы им не пользовались так широко. Заказчику намного дешевле поскорее сделать работающий прототип и сразу же его протестировать, чтоб на ходу внести изменения и снова тестировать, чем разрабатывать «от» и «до», неукоснительно придерживаясь плана, заморачиваться красотой кода и правильными архитектурными подходами, а также спокойствием команды. Иначе бизнес не выживет! В конкурентном капиталистическом мире бизнес-акул побеждает тот, кто быстрее может нащупать золотую жилу. Поэтому у заказчика нет выбора. Раз все стали играть в гибкие методологии разработки, то и тебе придется, голубчик, иначе ты быстро проиграешь. Звучит вроде бы логично. Но кто в этой истории крайний? Правильно — исполнители-золотоискатели, они же айтишники. Рядовые пешки — солдаты фронта нулей и единиц.

Формулировка SCRUM-определения «заказчик изменит мнение» — уже многое говорит о том, чего стоит вся эта возня с Agile’ом. Она стоит нервов и здоровья. Как юная девушка, которая всё время «меняет мнение» и тем самым нервирует парня, так и заказчик всё время «меняет мнение», нервируя всю команду — от тестировщиков и программистов до тимлида и продакт оунера. Это та плата, которую платят исполнители за то, чтоб бизнес получил максимальную прибыль.

Одна из целей SCRUM-подхода:

[…] максимизировать способность команды быстро выполнять поставленные задачи, реагировать на возникающие требования и адаптироваться к развивающимся технологиям и изменениям рынка.

Но мы-то с вами понимаем, что любая «максимизация» требует того, чтоб кто-то больше напрягался. Как и любая «адаптация». Все эти телодвижения требуют как минимум большего напряжения извилин и выжигания нервных клеток и сетчатки. Ведь если у тебя распланирована работа на полгода вперед — ты приходишь каждый день и знаешь что будешь делать и у тебя нет никаких неприятных неожиданностей, а значит и стрессов. Однако в современном мире разработки софта, даже двухнедельное планирование — утопия. В какой-то момент отцы-основатели «Скрама» это поняли, и потому даже заменили в своем Scrum Guide слово commitment на forecast. Мол, мы не беремся сделать все задачи, мы лишь прогнозируем, что выполним такой-то объем задач.

Однако легче от этого не стало. Вместо того, чтоб спокойно, с чашечкой кофе, запланировать на полгода вперед объем задач и постепенно выполнять его от фазы к фазе: от дизайна к разработке, от разработки к тестированию и так далее, у 99% айтишников Земли сплошной головняк. Никто не знает, что будет завтра на работе. Ни программист, ни тестировщик, ни тимлид, ни даже продакт-оунер. И все потому стрессуют. Либо же уходят «в отказ» (во внутреннюю эмиграцию с целью сохранить здоровье), то бишь перестают переживать за проект. И потому качество их работы страдает. Да и к чему рвать пятую точку, если ты никогда не выполнишь все задачи в срок (а если и выполнишь, то тестировщики не успеют их протестить)? Или если вы даже напишете весь функционал, а QA его протестят, то вам всё равно накинут задач. К чему тогда упахиваться? Ведь в любом случае вам будет уготовано вечное чувство неудовлетворенности, будто вы недорабатываете.

Работающим по SCRUM’у в принципе надо выписывать как летчикам — кефир или 100 грамм. От нервов. Может поэтому многие IT-компании поощряют алкоголь и устраивают «алко-пятницы» для своих сотрудников.

В самих «энциклопедических» Agile методиках по SCRUM’у давным давно было некое планирование со встроенной защитой от «дурака» (читай, переменчивого мечтателя-заказчика). Например, если Sprint (двухнедельная итерация, он же «забег») был запланирован на определенное количество задач и человекочасов, то изменять на ходу его ёмкость было нельзя. Однако очень быстро на это правило все стали плевать, объясняя это тем, что есть «бэклог» (набор задач), и раз в нем есть задачи, значит их можно докидывать в спринт. Или мол «а как это нельзя менять задачи по ходу пьесы, если вдруг команда прозрела, что разрабатывала что-то не то или использовала неподходящие технологии?». Хотя никто почему-то не вспоминает, что такая ситуация возникла в первую очередь из-за того, что на фазу планирования как таковую просто наплевали, ужав всё до минимальных сроков. Ведь это Agile, детка, тут надо всё успеть сделать на коленке. Иначе конкуренты сожрут.

Что бы предпочел программист, если бы ему предложили:
1) Минимум стресса, спокойный распланированный день без суеты, понимание всего объема задач на несколько месяцев вперёд и уверенность в выбранных технологиях.
2) Стресс, суета, планирование «для галочки» (по факту хаос), непонимание всего объема задач даже на ближайщие пару недель, отсутствие уверенности в выбранных технологиях и качестве продукта, вероятные овертаймы.
?

Ответ очевиден. Лишь самые забитые рабы-мазохисты, страдающие подобием стокгольмского синдрома, выбрали бы пункт #2.

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

Waterfall можно сравнить с социализмом. Такой подход более человечен, но менее прибылен.

Тогда как Agile — квинтэссенция капитализма в самом скверном смысле этого слова. «Рубить бабло любой ценой, здесь и сейчас» — вот о чем гибкие методологии разработки. Или, если быть точнее, — «практики прогибающихся». Поэтому и неудивительно, что проблема выгорания приобретает масштабы эпидемии в IT-компаниях мира, где применяется SCRUM. Человеческая психика не готова к ежедневному стрессу. Но капитализм сильнее социализма, поэтому будем работать по Аджайлу, то есть на износ, хлопцы и девчата. Добро пожаловать в блаженный мир IT, дамы и господа!

  • Victor

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

    «Каскадная модель» практически никогда не использовалась. Использовалась итеративно-инкрементальная, когда проект разбивался на фазы.
    Проблема предиктивных (классических) процессов разработки в том, что они неэффективны:
    — мало кто точно представляет, что хочет получить в результате.
    — практически невозможно всё правильно спланировать с самого начала.
    — такие проекты тонут в чейндж реквестах и овертаймах.
    — более 80% таких проектов не вписываются в сроки и бюджет.
    — цена ошибки очень высокая.
    — очень высокий риск получить продукт, который не удовлетворяет бизнес-требованиям (и, следовательно, всех хром выставят на мороз).

    Скрам работает в случае зрелой команды и скраммастера. Иначе тоже много боли и сюрпризов.

    • disqus_ceyaWycrOU

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

      • ITPravda

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

        • Demidov.D

          Ну чистый скрам тоже уже давно не используют. Можно установить глобальные цели ( OKR в помощь) и не давать заказчику менять общее направление.

          • ITPravda

            Если не давать заказчику менять общее направление — он выберет другую команду. Более «гибкую».

        • Victor

          Неправда. Людям часто сложно точно оценить задачу для себя. А если задача включает работу нескольких людей — пиши пропало.

          Что делать с «ветренными» кастомерами — отдельная тема.

          • Demidov.D

            «Людям часто сложно точно оценить задачу для себя»- ну так для этого как раз и нужен скрам)))

    • У проектов могут и должны быть фазы несмотря на на аджайл со спринтами, особенно фаза анализа требований (т.н. дискавери): функциональных и нефункциональных, построение достаточно детальной архитектуры с возможностью масштабирования, над которой должны подумать люди поднявшие десятки таких проектов. То есть отправить человек 5 на онсайт недельки на две и выделить им эти две недели своего времени нон-стоп на всякий воркшопы-х%епы. После этого подписывают SLA и начинают хороводить скрамы и если кто-то этот SLA нарушает — сам себе злобный буратино и платит все ииздержки.

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

      • Victor

        У проектов могут и должны быть фазы

        Мой комментарий был не про фазы, а про то, что «waterfall» в том виде, в котором о нём говорят, мало где и когда применялся, и вообще понят неправильно.

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

        Это, в общем случае, лишнее и даже вредное занятие.

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

        А галерам «скрамы» и прочие «аджайлы» нужны для того, чтобы продавать тушки по T&M и нести минимальную ответственность за результат.

    • Yaroslav Kravets

      Как об Agile читаю:
      — мало кто точно представляет, что хочет получить в результате.
      — практически невозможно всё правильно спланировать с самого начала.
      — такие проекты тонут в чейндж реквестах и овертаймах.
      — более 80% таких проектов не вписываются в сроки и бюджет.

  • Надо просто научиться нормально оценивать работу с учетом оверхеда и тех-долга и не пропускать все хотелки в одни ворота. Проблема же не в методологии а в том что люди не ценят свое время и эстимейтят слишком оптимистично, пытаются конкурировать друг с другом на количество тасок, чтобы выслужиться перед менеджером, типа я так быстро закрыл таску костылем — какой я молодец — дайте лычку! Тем самым подосрав в общий котел. Остальные ленятся ревьювить и наказать негодяя, потому что каждый набрал тасок в три короба и теперь зашивается над вопросом «почему эта херня не работает?» и «кто это блять написал?», да твой коллега написал а вечно-уставший техлид смержил не глядя. И вот это вот все. Какой нахрен социализм-капитализм, о чем вы? Заветами Ильича — переводить все проблемы в политические? Дерьмо ваш социализм, он нежизнеспособен, так же как и ваш говнокод. 😀

    • Andrew

      Люто плюсую

    • ITPravda

      >> Дерьмо ваш социализм, он нежизнеспособен
      Скажите это социалистической Европе

      • Yaroslav Kravets

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

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

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

    Вот это реально паразиты-гуманитарии, которых надо гнать подальше, или бежать подальше от мест, где они уже победили. Это место заражено, его уже не спасти.

  • Михаил Симоненко

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

  • Andrew

    Батенька, да вы дыбилоид, а не айтишник

    • ITPravda

      Скорее плакать. Видимо, вы не способны хоть немного подумать о прочитанном. Открыли, прочитали заголовок, и вперед строчить комменты.

      • Andrew

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

        • ITPravda

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

  • Junkie

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

    • Yaroslav Kravets

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