Agile мёртв

Автор: Алексей Александрович Самойлов

Agile продолжает шагать по стране, захватывая умы всё новых адептов и поддерживая своё влияние в головах старых. Различные компании и команды пробуют «внедрять Agile» (подход к управлению проектами) в меру своего понимания и с разной степенью успеха.

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

Но кто же следит за информацией по своей теме, тем более если она только на английском языке?

Специально для уважаемых Читателей канала VIKENT.RU мы разберем основные претензии Дэйва Томаса, одного из Авторов Agile-манифеста, к тому, что сейчас из себя представляет Agile.

Исходная проблема, которая возникла в конце 90-х годов — 99% проектов разработки ПО выглядело, как борьба на баррикадах в формате «сделай или умри». Хотя это было весело, но большая часть проектов умирала.

Разработка ПО была нестабильна, и возникло очень много людей, недовольных этой ситуацией, хотя нельзя сказать, что это было единое движение. Тут и там возникало много различных инициатив, которые пытались решить накопившиеся проблемы — экстремальное программирование, адаптивная разработка ПО, концепция программиста-прагматика, методологии семейства Crystal. Scrum тоже был где-то рядом ещё с 80-х.

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

Спустя 15 лет Дэйв Томас — один из Авторов манифеста, накопил ряд претензий к тому, во что последователи превратили исходную идею. Претензий всего 5, и давайте их разберём.

Эта ошибка заявлена, как исходная, которая в дальнейшем привела к искажению понимания принципов Agile, ведь точное название манифеста «Манифест гибкой разработки программного обеспечения», а люди стали сокращать его до «Agile манифест» (гибкий манифест — прим. Алексея Александровича Самойлова)., а надо было называть хотя бы «Манифест гибкости». Agile (гибкий) — это прилагательное и все, кто употребляет его, как существительное («я занимаюсь agile») делает ошибку. Например, нельзя при продаже сказать «купите у меня немного зелёного», это не работает. Можно сказать «зелёный рисунок» или «зелёные овощи». Можно продать существительное, но нельзя продавать прилагательное.

Хотя индустрия, возникшая вокруг этого манифеста, стремится продать вам — тренинги, консалтинг, книги и конференции и у них получается сформировать запрос именно в формате «взвесьте мне килограмм agile (гибкости), пожалуйста».

Но всё даже хуже.

Самое важное для бизнеса — это продажи. И индустрия, которая выросла вокруг этого, работает на страхе.

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

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

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

И главное, когда мы начинаем делать что-то новое, появляются сомнения, что мы делаем это правильно.

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

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

Например, Ruby-программисты очень сильно продвинулись в деле тестирования, чем кто-то другой в истории вычислений. У них развитая культура тестирования и проводится много экспериментов, разработано много методов тестирования, которые были перенесены потом в другие языки программирования. Но когда кто-нибудь не покрывает всё тестами на 100%, они смотрят на тебя презрительно и говорят: «А я думал, ты программист... Тогда не интересно, чем ты занимаешься, вали отсюда.»

Есть американская поговорка «не позволяй индюкам сломить тебя». Эти люди индюки. Не позволяйте им говорить Вам, что надо делать. Я тоже индюк.

С Agile происходит тоже самое — то, как мы делаем это и есть эталон, если ты делаешь по-другому, то ты второй сорт.

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

Иначе на Agile не заработаешь.

Нет универсальных правил (кроме этого).

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

Все правила завязаны на контексте. Любая книга «Как разрабатывать ПО» неправильная, т.к. написана не для вашей команды, компании, проекта, поэтому Авторы не знают точно, как конкретно Вам надо разрабатывать ПО.

Поэтому в Agile не может быть стандартов, подходящих всем.

Дэйв Томас считает, что выход из тупика может быть при использовании в проектах следующего цикла:

1. Определиться, где Вы находитесь.2. Сделать маленький шаг к Вашей цели.3. Оценить, что получилось.4. Вернуться на Шаг-1.

Пытливые умы могут сравнить его с циклом Шухарта-Деминга. А всем остальным рекомендуется ознакомиться в доп. материалах с ошибками изучения творчества, где разбирается метод проб и ошибок.

Но нам с Вами будут больше интересны выводы о совершённых ошибках в истории Agile.

Всем Разработчикам и Исследователям рекомендуется учиться на чужих примерах и не повторять этих ошибок.

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

Автору статьи неизвестно, где КАЧЕСТВЕННО учат (даже за деньги) созданию своих проектов, методик и иных разработок, кроме проекта VIKENT.RU. Если уважаемым Читателям известны такие примеры, то просьба привести их в комментариях.

А для более глубокого погружения в тему рекомендуется проработать дополнительные материалы:

1) (видео 8 мин.) #тестирование НОВЫХ ТВОРЧЕСКИХ ПРОДУКТОВ / РАЗРАБОТОК

2) (видео 12 мин.) Почему новые методики креатива будут похожи на ТРИЗ?

3) (видео 87 мин.) #консультация № 255 о создании авторских методик по принятию решений

4) (видео 46 мин.) ПРИНЯТИЕ ТВОРЧЕСКИХ РЕШЕНИЙ: ЭТАПЫ / СТАДИИ (ВИДЕОСЛОВАРЬ VIKENT.RU)

5) (видеозадача 3 мин.) Как исказили Waterfall?

Благодарю А. А. Морозова, А. И. Трушинского и И. Л. Викентьева за вычитку и рекомендации по усилению данной статьи. Отдельно А. А. Морозову за иллюстрации.

#vikent_ru #аджайл #скрам #канбан #спайк #agile