Асхатология agile

Автор: | 25.07.2018

Я многого не знаю. Например, я не знаю, кто был тот мудак, который раз и навсегда перевёл термин agile как «гибкий». Имя есть?

Flexible — гибкий.

Agile — проворный, подвижный, верткий, живчик.

Тестирования ради, усядьтесь голым попом на горячую сковородку — вы моментально станете agile.

Впрочем, кое-что я знаю — Асхат Уразбаев первым мощно предложил опечатался про слоган внедрения agile в 2014-ом году.

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

А ещё я знаю следующее: agile не методология и не процесс. Это надстройка над уже существующей методологией и уже существующими процессами. И если их нет, то внедрять agile не на что.

То есть, у вас может не быть скрама и доски на стене, а agile может быть. У вас процесс производства может не меняться, а agile над ним — работает.

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

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

Не бывает так, что «вот раньше у нас был ватерфлоу, а сегодня аджайл», одно другое не заменяет. Waterflow навсегда.

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

Психиатрия человеческая выражается в том, что вы не умеете ни экспериментировать, ни думать. Вы умеете лихо исполнять ограниченный набор действий, за которые «вчера» вас хвалили. Отклонение от этого всего страшит, оно требует взрослости и большого commitment (в русском переводе это звучит очень глупо и травматично, поэтому оставим оригинал без перевода). Поэтому вам нужен однозначный менеджер, который скажет «Делать так и эдак», и дальше он только покусывает пряник, постёгивая плёткой тех, кто отклоняется от предписанного.

Пирамиды в Гизе строили по этому принципу, и ничо, нормально построили же.

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

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

Поэтому agile и приходится в вас внедрять, по заветам Асхата.

Асхатология agile: 3 комментария

  1. Roman Podolyan

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

  2. Алексей Лупан

    Регулярность диктуэ и не одобряэ, когда что-то вдруг не укладывается в сроки. Кого-то надо прогнуть.

  3. Roman Podolyan

    ) Работа в разработке софта местами приравнивается к research. Примерно как Джеймс Бах и Майкл Болтон говорят что “нет research кейзов”, так нет и “research спринтов”.
    Не может быть регулярности когда лезешь в нечто новое, и неизведанное либо сюрпризами чреватое.
    ) Поезда ходят по рельсам, и то, бывает, опаздывают — даже в развитых странах.
    По всей видимости, идея регулярности пошла от Прокруста ( https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%BA%D1%80%D1%83%D1%81%D1%82 ). Скорей бы нашелся какой-нибудь герой и убил эту гадину.
    Людей, которые верят в спринты, следует считать не иначе как мазохистами…Впрочем, раз уж пошло сравнение верующих в скрам с догматиками, то каких только сект не встречалось. То хлысты ( https://ru.wikipedia.org/wiki/%D0%A5%D0%BB%D1%8B%D1%81%D1%82%D1%8B ), то скопцы ( https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BE%D0%BF%D1%86%D1%8B ).

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.