OpenQuality.ru

Качество программного обеспечения

Качество программного обеспечения: в главных ролях

Лента  Радар  Блог  Опыт  
Разум  Видео  Заметки  Эпизоды


 

Agile разрушил мою жизнь

Daniel Markham | 08.10.2010

Я прочел грустный ответ на свой комментарий, размещенный на хакерском форуме:

(Предупреждение: Консультанты по 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, которые годами не программировали и не руководили командой, поэтому у них я прошу прощения. Если вы собираетесь обучать чему-либо, вы должны уметь это делать. На очень высоком уровне компетенции. 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-сайте не говорят ровным счетом ничего о том, что вам по плечу. Давайте просто будем честными в этом вопросе. Курс обучения может быть великолепным, но нелепа сама идея о том, что маленькая золотая медаль на вашей шее делает вас существенно лучше.

Обучая Agile, я в первую очередь начинаю с определений.

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

Интересны ответы – те, что даю я, и те, что звучат в классе.

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

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

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

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

Наш финальный вопрос: что такое Agile. Обычно у пары человек есть идеи. Один скажет: «Это TDD». Другой: «Я думаю, что это манифест».

После долгой паузы я говорю классу (звучит как шутка, но шутки в сторону):

У Agile нет определений.

Истинно. Дуля с маком. Никаких.

Нет стандартной доски, нет теста, нет утвержденных учебных пособий, нет чеклистов.

У Agile нет ничего общего со Scrum. Лично я думаю, что это хорошо.

Agile – это набор устоявшихся методик,относящихся к итеративной и инкрементальной разработке. Это маркетинговый термин. Конечно, есть манифест, есть эксперты (я один из них), есть конференции, книги, курсы, и Бог знает что еще. Но это всего лишь устоявшиеся методики.

Agile базируется на трех вещах: 1) принципы, не методики; 2) внимание к людям и 3) всегда приспосабливайся

Кому-то такая формулировака может показаться размытой и не означать ничего. В таком случае прошу прощения. Уверяю вас, в обучении Agile есть систематизация и прогресс. Могу также заверить, что команды, «внедряющие Agile», более счастливы и намного более продуктивны чем команды без Agile.

Но ЭТО искусство, не наука. У вас не получится просто прочесть книгу, пройти курс и внезапно стать «гибким». Это больше похоже на игру на джазовом фортепиано. Немного изучили, немного применяете, честно оцениваете, что работает, а что нет. Затем изучаете еще чуть-чуть. И так далее. Действия, размышления, приспособление – вот что самое важное. Вы же не учитесь играть на фортепиано по фильму, где кто-нибудь на нем играет. И не обучаетесь в процессе чтения книги или при посещении конференции. И вы не превращаете себя в робота, который следует своду правил без исключений. Будете ли вы учиться играть на фортепиаоно, одевшись как пианист, арендовав Carnegie Hall и как можно точнее имитируя действия великого пианиста? И тем не менее, каждый день бедные тупицы сидят на часовых занятиях, которые больше похожи на отвратительные дневные отчеты, чем на совместную работу. И мы называем это Agile.

Вчера один из комментаторов рассказал, что он работал в группе, которая была счастлива и эффективна. Затем их купила большая фирма, решившая «насадить им Agile». Эффективность пошла вниз, моральный климат пострадал, людям сказали либо приспособиться, либо обломаться.

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

Конечно, мои критерии Agile не универсальны, но я очень рад обучать устоявшимся методикам итеративной и инкрементальной разработки. Вы можете называть это Agile, я могу называть это как угодно. Как бы то ни было, помогать людям увидеть всю картину и попробовать что-то новое, а затем позволить им решать, насколько им это подходит – стоящее дело. Но в этом деле есть МНОГО проблем. Если закрывать на них глаза, они не исчезнут. Временами могут возникать ситуации «мы против них», когда две группы людей могут оказаться по разные стороны. Нужно всегда быть начеку. Если вы не служите команде, вам не место в комнате. Вот так, начистоту. Проблемы, перечисленные выше, присущи всем нам, и наша задача – бороться с ними как можно лучше.

Оригинальная публикация и комментарии (1, 2).

Комментарии (16)

Another view on the topic.
http://testobsessed.com/2010/09/08/agile-backlash/

Albert Gareev | 01.11.2010 | 1:29 пп. Ответить #

Альберт, спасибо!

Интересный взгляд. Я не уверен, что все контраргументы, изложенные Элизабет, можно адресовать автору статьи. Возможно, Элизабет в какой-то мере придумала некую точку зрения, которую ассоциировала с Даниэлем, и стремится эту точку зрения опровергнуть. Но, возможно, Даниэль вовсе не высказывал эту точку зрения и даже согласен со всеми аргументами Элизабет. Вот я, например, вижу разумное зерно и у того, и у другого…

Кормчий | 01.11.2010 | 5:22 пп. Ответить #

Возможно, Элизабет в какой-то мере придумала некую точку зрения, которую ассоциировала с Даниэлем, и стремится эту точку зрения опровергнуть.

Я даже знаю, почему ;)

Albert Gareev | 02.11.2010 | 12:57 пп. Ответить #

Ох уж эти Agile-коучи :)

Кормчий | 02.11.2010 | 2:23 пп. Ответить #

[...] прочитать. Многие Некоторые люди смело могут сказать «Agile разрушил мою жизнь» и будут в какой-то мере [...]

Статьи: Agile разрушил мою жизнь | The Improved Methods | 13.11.2010 | 11:54 дп. Ответить #

Буквально сегодня в офисе тоже самое обсуждали.

Очень все правильно и четко расписано. Спасибо!

Александр Бындю | 16.11.2010 | 8:02 дп. Ответить #

По-моему здесь не правильный перевод

«Люди думают, что можно взять увечный проект, который уже не жилец, добавить немного Agile и заявить, как это было круто. »
В оригинале
«People think they can take some lame project that’s mostly done, apply a little agile, then proclaim how great it was? »
Я думаю он имел ввиду взять какой-то неважный или не сложный проект, практически завершенный, добавить аджайла и рассказать как аджайл помог. Это делают консультатны с целью пропаганды. То есть проект выбирается так чтобы он мог быть удачным и без аджайла. Mostly done!=mostly died :)

Vook | 24.11.2010 | 4:01 пп. Ответить #

Vook, спасибо за комментарий!

Признаться, на вариант «не жилец» для «mostly done» меня натолкнуло выражение «lame project». Значения для lame: 1. a)хромой; увечный; парализованный; б) неправильный; 2. неубедительный, неудовлетворительный. Я перевел как «увечный». То есть, в моей интерпретации речь идет не о том, что проект неважный или несложный, а именно увечный, все наперекосяк.

Далее, о выражении «that’s mostly done». На мой взгляд, здесь речь может идти не столько о практически завершенном проекте, сколько о том, что он приказал долго жить. Вот пример (http://www.multitran.ru/c/m.exe?t=3272580_1_2): I’m done to a frazzle – я дошёл до полного изнеможения. В нашем случае, проект мог дойти до хромоты и увечья.

Не настаиваю на своей трактовке. Думаю, что и ваш, и мой вариант имеют право на жизнь…

Кормчий | 24.11.2010 | 5:32 пп. Ответить #

Перевод Vook верный.

prohozhiy | 21.12.2010 | 3:25 пп. Ответить #

Готов согласиться. И все же терзают сомнения: можно ли удачно завершить lame project?

Кормчий | 21.12.2010 | 3:29 пп. Ответить #

Согласна, что mostly done – это про почти полное завершение, если бы «done» использовалось в значении «не жилец», было бы скорее «almost done»

Olga | 20.02.2014 | 6:27 дп. #

Ольга, спасибо за комментарий! Меня по-прежнему смущает сочетание lame project и mostly done, но, поскольку три внимательных читателя высказались за перевод в контексте почти полного завершения проекта, то склоняюсь к мнению большинства и внесу исправление в перевод: «Люди думают, что можно взять несложный, почти завершенный проект, добавить немного Agile и заявить, как это было круто. »

Кормчий | 20.02.2014 | 9:10 дп. #

[...] Lean-разработка программного обеспечения Agile разрушил мою жизньавтоматизация тестирования причины провалов старых [...]

Agile.Применение «Бережливой разработки ПО» – Блог Романа Василевича | 03.08.2011 | 10:19 дп. Ответить #

Дерзко:) И отчасти правдиво:) Но, в конечном счёте, проекты делают не Agile и не Scrum, а люди. От их трезвого решения всегда больше толку, чем от каких-то парадигм.

Анатолий | 28.11.2011 | 3:31 пп. Ответить #

Анатолий, воистину так.

Кормчий | 29.11.2011 | 9:01 дп. Ответить #

[...] показателем “живучести” продукта, Agile-технологии с гиком и свистом пробивают себе дорогу. “Надо быть гибким, отвечать [...]

Список паттернов искаженного мышления « OpenQuality.ru | Качество программного обеспечения | Опыт экспертов | 17.02.2013 | 6:33 пп. Ответить #

Оставьте комментарий

Required.

(будет спрятан за семью замками)

(будет открыт, если это не спам)

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