OpenQuality.ru

(Предупреждение: Консультанты по Agile разрушили группу программистов, в которой я работаю). Создавать хорошее ПО непросто. Каждый обладатель волшебного зелья, гарантирующего выпуск хорошего программного продукта, есть шарлатан, продающий средство от всех болезней. Я понимаю ваше желание подхалтурить, но буду очень признателен, если кроме разработки ПО у вас найдется другая отрасль, где можно напортачить.

[Мы] стали работать над [гибкой методологией Х], когда [знаменитая книга] [автора] существовала только в черновике. Я принимал в этом участие и работал в agile-проектах на протяжении десяти лет. (При следующей встрече со [знаменитым парнем] спросите обо мне. Только что закончил рецензировать его грядущую [знаменитую книгу]. Я один из учредителей Организации по Agile в [место] и организовывал конференции по гибким методологиям. Вдобавок, присутствовал на конференции по XP. Возможно, я работал в большем количестве agile-проектов, чем вы (не сказать, что это особенно важно). Поэтому давайте прежде всего обойдемся без представлений о том, что ваше мнение о «правильных» agile-методиках и примкнувших жуликах является единственным критерием…

Будете ли вы отрицать, что вся идея о Scrum-мастерах есть афера в стенах Agile-лагеря?

Жулик? Ron Jeffries, гуру/основатель Agile, за пять недель не смог запрограммировать Судоку с помощью своей излюбленной техники TDD и рефакторинга. Мошенничество.

Robert Martin (еще один «гуру» и agile-консультант) называет код, написанный без TDD, кодом «каменного века», включая Unix и код таких людей как Norvig, Linus и Zawinski, которые написали больше кода, чем он может себе вообразить. Dalke нашел дыры в его приемах TDD и не получил никакого отпора. Мошенничество.

Я могу продолжать и продолжать. И это гуру. Но дело не в этом. Я «вижу» эволюцию agile-консультантов: от в меру наивных, но благонамеренных специалистов (скажем, Kent) в жуликов, подобных «X и компания». И это люди на вершине пирамиды. Практически каждый «Scrum-мастер» – мошенник. Наиболее разумные из них признают, что два дня прослушивания проныры высокого уровня ничему не научaт, и это лишь средство для тупых менеджеров повысить свои шансы на получение проекта. И все же они продолжают идти вперед. По-моему, это жулики наподобие хиропрактиков и апологетов рейки, возомнивших себя врачами. Движение Agile было основано жуликами и распространялось большей частью ими.

• Придуманные истории успеха. Люди думают, что можно взять несложный, почти завершенный проект, добавить немного Agile и заявить, как это было круто. Да ладно, ребята, никого так провести не удастся. Все точно знают, что это пропаганда. Хуже того, вовлеченные эксперты оказываются последними, кто узнает о тщетности таких действий на публику. На своем опыте они «обучаются» неправильным вещам и «делятся» своим знанием с новыми командами, продолжая дерьмовый цикл.
• Тренеры, которые не могут выполнить работу. У меня есть хорошие друзья, преподающие Agile, которые годами не программировали и не руководили командой, поэтому у них я прошу прощения. Если вы собираетесь обучать чему-либо, вы должны уметь это делать. На очень высоком уровне компетенции. Agile-тренер должен уметь программировать, выполнять анализ, руководить проектом, тестировать – все необходимое для ведения проекта. Если вы не можете, то как с вами можно разговаривать о специфических ситуациях? Если ваш agile-тренер получил степень бакалавра на прошлой неделе или не написал ни строчки кода или является профессиональным тренером или – давайте будем по настоящему честными – приносит меньше пользы чем члены команды, он бесполезен. В этом виден здравый смысл, но лучше повторить: вы не можете обучать тому, что не делали. И «делание» означает «многократно», а не один пилотный проект. Одна компания пригласила меня подготовить нескольких agile-тренеров. Эти люди ничего не знали про Agile две недели назад, когда я побывал у них первый раз. Блин, если бы я смог, то был бы завален деньгами, но так не бывает. Ходит ли кто-нибудь в школу для того чтобы стать тренером по бейсболу? Или сначала они учатся играть в бейсбол, а потом лишь часть из них осознает, что у них есть талант к преподаванию? Девять женщин не смогут за месяц родить одного ребенка, и неважно, как сильно вы этого хотите.
• Негибкость в стане сторонников. Я работал с дамой, которая в своей статье спрашивала: «Почему мы недовольны неуспешными Scrum-командами, если на самом деле они не следуют принципам Scrum?» Проповедовать список действий, которые надо выполнить идеально, и считать неудачу следствием их невыполнения – это, по существу, религиозная установка. Никогда не удастся сделать достаточно. Команда провалилась? Не было достаточного Agile. Вздор, вот что это. Много прекрасных agile-команд терпят неудачу. И много команд успешны без Agile.
• Agile «хорошего самочувствия». Одна из моих коллег посетила agile-конференцию. По ее словам, она ушла из класса, где говорилось о «применении хайку в построении команд». Я люблю поэзию, но это не звучит убедительно ни для меня, ни для моей коллеги. У меня есть несколько друзей-хиппи, Бог их любит. Зайки, плывущие облака, гармоники и карма могут играть важную роль в жизни, но я не хочу петь Kumbaya. Я хочу веселья и эффективной команды. Поймите меня правильно: я люблю необычные, оригинальные методики. Но agile-сообщество порой выходит за границы нормы. Жестоко вызывать на сцену скрупулезных людей с аналитическим складом ума и заставлять их общаться друг с другом. Они не марионетки, а их случаи – не спектакль. Это мост в никуда, нужно остановиться.
• Синдром волшебной пули. Одна из первых истин, которой учат в Scrum-классах: Scrum – не волшебная пуля. Оставшуюся часть времени вам говорят, что это лучшее изобретение человечества после нарезного хлеба. Все мы встречались и работали с парнями, у которых всегда есть ответ на любой вопрос – нужно только спросить. Решения уже приняты для любой задачи, которая у вас может быть. Такие люди чрезвычайно раздражают. Все равно что говорить со стеной. Плохо, плохо. Я знавал одного парня (еще одна знаменитость), который любил со страстью заявлять, как крут Scrum. Что бы ни произошло, в какой бы ситуациии вы ни оказались, вы всегда можете рассчитывать на его разглагольствования о Scrum – не только бесполезные, но и раздражающие. И вы не знаете, плакать или смеяться.
• Отказ от доминирующей роли команды. Я знаю немало ребят, которые преподают Agile. К сожалению, многие из них навязывают Agile командам, а не обучают их. Вы входите с большой указкой и шпыняете людей до тех пор пока они не «подчинятся». Выходит движение наоборот: во главе процесса оказывается постороннее лицо, а не команда. Один парень (и вновь знаменитость), по сути, высказал нечто подобное в ответ на мое замечание о неуспешности команды: «Я нахожусь здесь для демонстрации определенных методик и показываю, как они работают. Я не могу все бросить и участвовать в том, с чем команда имеет дело сегодня». К сожалению, вышестоящие управленцы поощряют такое поведение. Много клиентов просят меня предоставить расписание и чеклист, описывающие, как я собираюсь сделать «гибкими» их команды. Я говорю им: «Послушайте, я могу предоставить информацию, могу обучать людей работе над задачами, но у проблем большей частью человеческая, а не технологическая составляющая. И знаете что? Люди не очень любят, когда с ними обходятся как с машинами».
• Культ Карго в Agile. Есть немало команд, поклоняющихся культу Карго в Agile. Так называемый театральный Agile. Здесь каждый знает свои границы, свой ритуал, где стоять и что делать. Нечто вроде срежиссированной постановки. Ужасно, безжизненно. Фу.
• Нет ответов на вопросы. Работает ли Agile для распределенных команд? Смотря по обстоятельствам. Можно ли использовать двухнедельные отметки для оценки проектов? Смотря по обстоятельствам. Работает ли Agile в проектах по разработке встроенного ПО? Смотря по обстоятельствам. Черт! Всё зависит от обстоятельств. Порой как бы сильно я ни пытался быть вежливым, честным и открытым, я становлюсь похожим на тех ребят из Матрицы, когда вы смотрели ее первый раз. Они говорят много, но на самом деле это мало что значит. Звучит напыщенно, но по сути чепуха. Ненавижу давать такие советы. Знаю ребят, которые ненавидят их слушать.
• Противоречивые советы. Можно или нет в условиях Agile проектировать систему до начала кодирования? Как насчет требований? Можно ли работать над требованиями, запланированными на спринт, который следует после текущего? Можно ли несколько проектов представить метриками, удобными для управления? Я мог бы привести дюжину других вопросов, на которые возможны разные ответы в зависимости от того, с кем вы говорите. Один парень говорит делать так, другой – делать сяк. Достаточно, чтобы свести с ума кого хочешь.
• Жулики. В 2009 году, выступая на Agile-конференции, я начал свое выступление так: «Я не читаю книг по Agile. Это трата времени». Вау! Вы могли бы услышать чуть ли не стоны! Но я говорю серьезно: 99% изданных книг по Agile представляют собой истории людей, рассказывающих о всякой всячине. Истории великолепны, люблю их слушать. Но я не могу поверить тому, что авторы большинства этих книг рассказывают правдивые истории, извлекая из них правдивые уроки. Вместо этого у них есть лейтмотив, довод, точка зрения. И все в этой книге направлено на поддержку этого довода, этой точки зрения. Черт побери, это просто хороший текст. Но проблема в том, что в реальной жизни нет лейтмотива. И даже если он есть, было бы изумительно неправдоподобно и невероятно до абсурда, если ситуация в вашей книге совпадет с тем, что творится в моей организации. Первые книги по Agile были настолько забавными, что я не мог их читать, потому что всегда начинал слишком громко смеяться. Когда Bob Martin стал поносить разработчиков, не использовавших TDD, я осознал, что многие «agile-эксперты» катятся вниз с пика популярности. Да, есть немало людей, продающих вам нечто, что вам не нужно, убеждая, что оно вам нужно. Точный эпитет для них: жулики.
• Это то же самое, только другое. Больше всего в Agile я ненавижу случаи, когда управленцы решают «быть гибкими» и при этом не хотят ничего менять. Вы говорите команде, находящейся в их подчинении, о том, что они отвечают за важные решения по объему работ в каждой итерации и способах ее выполнения. Только ответственность они не принимают. Это разрушает моральный климат быстрее чем любой другой фактор. Не так давно я свернул обучение TDD в одной команде. Почему? Потому что кто-то сверху решил, что команда будет внедрять TDD. Решала не команда. Получалось, что три дня мне пришлось бы делитьсяя знаниями, которые команда не хотела усваивать и не собиралась применять. Немало других трениров – вероятно, большинство – взялось бы за дело, но я не собираюсь быть частью проблемы. Смелость – не только для команд.
• Синдром маленьких золотых медалей. Двухдневный курс и маленькая золотая медаль, или ваше имя на каком-либо web-сайте не говорят ровным счетом ничего о том, что вам по плечу. Давайте просто будем честными в этом вопросе. Курс обучения может быть великолепным, но нелепа сама идея о том, что маленькая золотая медаль на вашей шее делает вас существенно лучше.

Что такое итеративная разработка?
Что такое инкрементальная разработка?
Что такое Scrum?
Что такое Agile?