В последнее время кажется, что Agile становится больше культом, а не инструментом, помогающим разработчикам создавать лучшие продукты. Это становится все более распространенным и начинает тормозить развитие. Вот 6 причин, по которым Agile больше похож на культ, и почему это вредит разработчикам.
1. Единственный путь к спасению - через кошелек.
Один из явных признаков секты - это то, что если вы не платите деньги, вы не можете делать это должным образом. В большинстве случаев, когда вы платите за что-то, вы обычно получаете взамен что-то не менее важное. Однако в этом случае вы на самом деле платите только за змеиное масло.
Некоторые из вас, читая это, попытаются представить это как «Есть много вещей, которые не являются культами, требующими годового членства», и вы будете правы. К сожалению, я не верю, что это один из тех случаев.
Абсолютно безумие, что нужно платить столько денег только за то, чтобы «должным образом» выполнять Agile. Однако поистине безумие то, что эти цены не так уж и плохи. Вы можете в конечном итоге заплатить многие тысячи долларов, чтобы стать «сертифицированным практиком / тренером Agile или Scrum». Если вы выполните поиск «Сертификация Agile» в Google, у вас не будет недостатка в компаниях, которые всю свою жизнь основывали на продаже Agile.
Почему это вредит разработчикам?
Одна пугающая вещь заключается в том, что большинство людей, которых выкачивают из этих курсов, не являются техническими людьми. Я работал по крайней мере в 5 разных командах, где Скрам-мастер, или Agile Messiah, был человеком, который никогда в своей жизни не касался ни одного фрагмента кода. Они думают, что это потому, что они посетили слишком дорогой двухнедельный курс по «Методологии гибкой разработки» и получили специальный сертификат, подтверждающий, что они знают, как разработчики должны писать код.
Это настолько пагубно для разработчиков, потому что нетехнические люди ничего не знают о написании кода или процессе написания кода. Их образ мышления заключен в коробку Agile, и они не могут мыслить вне его. Если возникает проблема и разработчик решает ее способом, который не следует тому, чему его учили на двухнедельном курсе, он ругает этого разработчика и говорит что-то вроде «Это недействительно, потому что Agile работает не так». Их исключительное знание Agile делает их неустойчивыми к изменениям и легко ломаются.
Я хочу прояснить, это не проблема, с которой я столкнулся в одиночку или даже в одной компании. Это проблема, с которой сталкиваются многие разработчики, и я столкнулся с ней в нескольких компаниях. Если вы лично никогда не сталкивались с этой проблемой, это здорово, но существует тревожное количество разработчиков, так что у вас должны быть причины для беспокойства.
2. Проворный евангелизм
Agile зарабатывает деньги, мы получили это по пункту 1. Они хотят и дальше зарабатывать деньги, поэтому им нужно привлекать больше людей, чтобы они посещали их курсы и семинары. Для этого они должны как можно больше пропагандировать Agile. Есть некоторые экстремисты Agile, которые продают Agile как единственное верное решение, серебряную пулю для решения любой проблемы, ваше окончательное спасение. Кроме того, есть модераторы Agile, которые говорят, что Agile - это не серебряная пуля, и вы можете делать то, что хотите. Однако их конечный посыл один и тот же: если вы не используете Agile, вы ошибаетесь. Евангелисты не хотят слышать, почему они могут быть неправы или почему Agile может быть неправильным, или даже о каких-то проблемах с Agile, они просто хотят продать это вам.
Я знаю, что есть люди, которые скажут: «Это неверно, потому что есть люди, которые практикуют Agile, но этого не делают». К сожалению, дело в том, что таких людей больше, и их чаще слышат.
Почему это вредит разработчикам?
Когда вы проповедуете какую-либо систему убеждений, подобную этой, или не желаете слышать иное мнение, вы отвергаете здравый смысл и исходные мысли. Разработка программного обеспечения - это возможность по-разному думать о проблемах и придумывать творческие решения, а не следовать жесткому шаблону T.
Я повторю это еще раз, это не основано на одном опыте, команде или даже на одном разработчике. Есть много разочарований по этому поводу, и я пытаюсь пролить на это свет.
3. Называть «другое»
Обычно, когда вы хотите взять людей и сделать их воинственными к другому образу мышления, вы обычно должны назвать, кто такие «Другие». В этом случае Agile-экстремисты, скорее всего, назовут меня и множество других людей FUD. Это стало сокращением для людей, которые сеют страх, неуверенность и сомнение в Agile.
Цель этой статьи - пролить свет на проблемы Agile и его культовых последователей. Я полностью осознаю, что не ВСЕ люди, практикующие Agile, такие, но подавляющее большинство, что является проблемой. Это проблема, потому что вы всегда слышите слова большинства больше, чем слова меньшинства. Если вы собираетесь прокомментировать и сказать: «Ну, на моем рабочем месте этого не делают», просто сохраните его, потому что вы находитесь в меньшинстве гибких рабочих мест. Доказательство тому - количество людей, выброшенных из этих мастерских, курсов и семинаров и возвращенных в свою компанию или отправленных в компанию для управления командой разработчиков.
Почему это вредит разработчикам?
Это одна из самых вредных вещей, которые вы можете сделать с человеком в целом. Ярким примером является преследование еретиков католической церковью в средние века. Если по какой-то причине был кто-то, кто вам нужен, вы можете просто заклеймить его как еретика, и на этом все. Этот человек или семья будут изгнаны из своего сообщества, и не потребуется никакого судебного разбирательства или надлежащей правовой процедуры, чтобы заклеймить кого-то еретиком.
Agile делает то же самое, когда называет людей, которые выходят за рамки FUD. Это используется для того, чтобы сделать из вас пример, а также чтобы дать другим право навалить вас сверху, чтобы заткнуть вам рот. Это наиболее эффективный способ прекратить критическое мышление при различных мнениях. Это также игнорирует тот факт, что люди, получившие ярлык FUD, пытаются бороться с невежеством, которое с радостью распространяется среди культа Agile.
Кто-то может сказать, что я продвигаю Agile таким же образом, и ошибетесь. Я полностью осознаю, что это не относится к тем, кто подписывается на Agile, и это нормально. Моя главная цель - пролить свет на проблемы, с которыми сталкиваются разработчики.
4. Сохранение контроля над своими предметами.
Я говорил об именовании «Другого» в моем последнем пункте и о том, почему это используется, чтобы заткнуть рот людям. Теперь я расскажу вам, как это позволяет гибким мессиям сохранять контроль над своими любимыми предметами.
Когда вы называете кого-то «Другим» или FUD в случае Agile, вы избегаете их участия в сообществе и маркируете этих людей как вредных для Agile, чтобы гарантировать воинственный ответ со стороны ваших последователей. Это служит тому, чтобы показать кого-то примером и показать доминирование вашего образа мышления. Это знак культа торговой марки, но это не единственный знак, который демонстрирует Agile.
Психолог Джон-Патрик Педерсен утверждает, что человеческое стремление к комфорту заставляет нас искать людей или вещи, которые могут успокоить наши страхи и тревоги, чтобы объяснить, почему люди присоединяются к культам. Лидеры сект используют это, выражая вашу тревогу, а затем предлагая вам постоянное спокойствие. На веб-сайте Agile Alliance в Agile 101 Agile описывается так:
Agile - это способность создавать изменения и реагировать на них. Это способ справиться с неопределенной и неспокойной средой и в конечном итоге преуспеть в ней.
Agile продается как решение для успеха в неопределенной среде. Просто следуйте Agile, и все будет в порядке. Просто наймите Agile Messiah, и все наладится. Заплатите нам немного денег, и вы получите душевное спокойствие, в котором вы нуждаетесь.
Заставлять людей бояться и беспокоиться и в то же время продавать им что-то для успокоения - это эффективный метод контроля над людьми. Как люди, мы не любим чувствовать себя неловко и часто выбираем путь наименьшего сопротивления, особенно когда кто-то вручает его нам на серебряном блюде.
Agile продвигает идею о том, что мы живем в неопределенные и неспокойные времена, чтобы усилить беспокойство и страх по поводу того, что мы делаем, и заставить нас сомневаться в себе. Однако они уверяют нас, что так быть не должно и что у Agile есть ответы, которые нам нужны, чтобы подавить наши страхи и тревоги. Они предлагают нам путь наименьшего сопротивления на серебряном блюде, если мы полностью на него соглашаемся в денежном и философском плане.
Почему это вредит разработчикам?
Это идет рука об руку с именованием другого, но идет еще дальше. Это создает токсичную среду, в которой новые идеи встречаются с воинственным поведением. Когда разработчиков избегают и ставят на их место в основном нетехнические Agile-мессии за то, что они думают вне рамок Agile, что-то очень не так.
Я хотел бы еще раз подчеркнуть, что это не относится ко всем Agile-рабочим местам, но существует подавляющее количество рабочих мест, которые работают таким образом. Я работал со многими из них, и у меня есть друзья, которые работали над многими другими. Я думаю, это здорово, если ваше рабочее место не такое, потому что я бы не хотел, чтобы кто-то работал в таком месте.
Что я скажу, так это то, что если вы критикуете эту статью так: «В моей команде этого не происходит», пожалуйста, не беспокойтесь. Это то же самое, что «Это работает на моей машине», что является ленивым отбрасыванием моих аргументов и уделяет реальное внимание тому факту, что он сломался в процессе производства.
5. Ритуальные встречи.
Какой лучший способ затопить людей процессом Agile / Scrum? Чтобы не зайти слишком далеко в другую крайность, я не говорю, что мы никогда не должны встречаться, но мы определенно не встречаемся каждый день или даже каждую неделю. Я считаю, что более асинхронная форма общения может быть столь же эффективной.
Вы когда-нибудь предлагали пропустить стойку, потому что мы находимся в разгаре чего-то важного, или ничего не изменилось настолько, чтобы заслужить стойкую встречу? Я так много раз работал в разных командах, и каждый раз получал один и тот же ответ: «Agile делается не так». период полная остановка конец обсуждения. Кто-нибудь еще встречал такой ответ, когда предлагал что-то изменить с помощью текущего Agile-процесса? Это такой простой ответ от человека, который не желает думать о текущем процессе, потому что текущий процесс удобен, и, как мы знаем, люди ненавидят дискомфорт.
Почему это вредит разработчикам?
Это еще одна атака на наши способности критического мышления и здравый смысл с целью внушить нам Agile. Заставлять всех проводить одни и те же унылые собрания снова и снова без всяких рифм и поводов - это совершенно бесполезная трата времени. Если подумать об этом иначе, у вас есть команда из 5 разработчиков, каждый из которых проводит 3-5 часов в неделю на собраниях. Это означает, что ваша команда тратит 15–25 часов времени каждую неделю. Это 15–20 часов, которые вы платите разработчикам, которые должны писать код, чтобы продукт работал.
Если вы хотите думать об этом с точки зрения денег, давайте сделаем это. Средняя зарплата инженеров-программистов в США составляет от 60 до 140 тысяч в год. Давайте посередине и предположим, что каждый разработчик зарабатывает 100 тысяч долларов в год. Это равносильно тому, что каждый разработчик зарабатывает около 50 долларов в час (за 40-часовую рабочую неделю и до вычета налогов). Итак, теперь вы тратите от 750 до 1250 долларов в неделю на разработчика. Для вашей команды из 5 разработчиков это от 3750 до 6250 долларов в неделю. Я работал с командами, которые находились на низком уровне, и командами, которые были далеко позади. Я думаю, что все мы можем согласиться с тем, что это огромная трата ресурсов. Если вы чувствуете, что НЕОБХОДИМО проводить все эти встречи, возможно, что-то еще не так, и нужно исправить это, потому что это вопиющее.
Подчеркну еще раз, что если ваша команда этого не делает, это прекрасно, а есть много команд, которые этого не делают. Если вы один из тех, кто думает: «Эта статья глупая, потому что моя команда не делает этого», то я хочу, чтобы вы подумали обо всех командах, которые этим занимаются. Подумайте о количестве времени и денег, которые тратятся впустую, и вы можете задаться вопросом, зачем кому-то вообще это нужно.
6. Никаких вопросов или критического мышления.
Я думаю, что другие мои соображения достаточно ясно проиллюстрировали это, но я хочу указать на это еще раз. Самое опасное для Agile - это критическое мышление Agile. Настоящая сила Agile заключается в том, что он дает вам достаточно свободы, чтобы вы почувствовали, что все под контролем, используя такие термины, как «самоорганизующиеся» команды. Хорошее слово, если мы будем следовать Agile, мы сможем самоорганизоваться! Это красиво звучащая фраза, которая мало что значит.
Самоорганизация - это ярлык, который нам дают менеджеры для поддержания иллюзии свободы воли. Еще раз процитирую сайт Agile Alliance:
Это не значит, что менеджеров нет. Это означает, что команды могут самостоятельно определять, как они собираются подходить к делу.
Это означает, что эти команды кросс-функциональны. Этим командам не обязательно должны быть задействованы определенные роли, просто, когда вы собираете команду, вы убедитесь, что у вас есть все необходимые навыки в команде.
Еще есть место для менеджеров. Менеджеры следят за тем, чтобы члены команды имели или приобрели правильный набор навыков. Менеджеры создают среду, которая позволяет команде быть успешной. Менеджеры в основном отступают и позволяют своей команде выяснить, как они собираются выпускать продукты, но они вмешиваются, когда команды пытаются, но не могут решить проблемы.
Если команда самоорганизуется, разве это не сделает ее независимой от контроля менеджера? Это означает, что команда может организовать себя так, как сочтет нужным? За исключением этого отрывка, менеджер отвечает за назначение навыков членов команды. Одна вещь, на которую я хочу пролить свет, - это тот факт, что Agile полностью ориентирован на менеджеров. Менеджер отвечает за то, чтобы каждый был просто винтиком в машине разработки программного обеспечения и что всех можно было заменить.
Хотя это имеет смысл для бизнеса, это также ужасный способ обращения с вашими сотрудниками. Я никоим образом не призываю к тому, чтобы у компаний был продукт, основанный на одном разработчике, потому что это также несправедливо по отношению ко всем участникам.
Почему это вредит разработчикам?
Я хочу сказать, что с Agile нет места для развития или специализации в качестве разработчика. Вы просто должны делать свою работу и находитесь во власти Верховного Повелителя Agile. Если вы хотите получить более широкую картину, чтобы быть более эффективным в своей работе, это просто плохо. Agile Overlord передает вам ваши истории, и вы должны просто быть благодарны за то, что у вас есть работа.
Мне повезло, что я работал только в одном месте в течение очень короткого времени, но я слышал несколько настоящих ужасов. Я не думаю, что справедливо думать о ваших разработчиках или любом сотруднике как о винтике в более крупной машине.
Заключение
Я понимаю, что эта статья может быть весьма поляризующей по своей формулировке, но я думаю, что важно привлечь больше внимания к этим проблемам. Я думаю, что Agile начинает слишком полагаться на догмы, что вызывает много разочарований. Я думаю, что слишком многие люди на самом деле не думают критически о том, как они применяют Agile. Если вы собираетесь использовать Agile, подумайте об этом и измените его в соответствии с требованиями вашей команды, я говорю вам больше возможностей.
Суть моего аргумента заключается в том, что большая часть культуры, окружающей Agile, стала более культовой по своей природе и заглушила голоса слишком большого количества разработчиков, которые хотели бы изменить определенные аспекты, чтобы лучше соответствовать своей команде.
В этой статье я постоянно повторял одну вещь, а именно, что эти ловушки не применимы к каждой Agile-команде. Если вы чувствуете, что ваша команда отлично справляется с Agile, что все в порядке, это не о вас. Речь идет о том, как философия Agile превратилась в культовый процесс, позволяющий бизнес-менеджерам утверждать доминирование и контроль над разработчиками программного обеспечения, и как это распространилось повсеместно.
Если вы не думаете, что это происходит, и не думаете, что это проблема, то вы либо слепой, либо кровно заинтересованы в том, чтобы Agile оставался незамеченным. Если вы хорошо зарабатываете на Agile, я понимаю, почему вы испытываете недовольство по поводу этой статьи. Однако если ваш главный источник прибыли - это продажа змеиного масла Agile, вы действительно являетесь частью проблемы, на которую я пытаюсь пролить свет. Я не думаю, что методологии разработки следует превращать в отдельный бизнес или пропагандировать, как это сделал Agile.
Я хочу, чтобы все вынесли из этого то, что нам нужно критически относиться к процессу, который мы внедрили. Если есть что-то, что сломано или нужно изменить, вы должны высказаться против. Я не думаю, что компетентной команде разработчиков нужен scrum-мастер, пользовательские истории, стикеры, планирование покера или любые другие нелепые вещи, которые Agile пытается нам навязывать. Если вы хотите быть эффективным менеджером, ваша основная цель должна заключаться в поддержке ваших разработчиков, убедившись, что у них есть все необходимое для работы. Убедитесь, что у них есть требования, и оставьте их на усмотрение.
Если вы хотите читать дальше, попробуйте книгу «Agile! Хорошее, обманчивое и уродливое »Бертрана Мейера. Он очень внимательно и честно рассматривает недостатки Agile, а также некоторые вещи, которые, возможно, стоит сохранить.
