Сравнение подходов к организации разработки (Автор: Павел Веллер)

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

Проще и безопаснее всего сравнивать agile с водопадом: во многом диаметрально противоположные основы, контрастирующая стержневая культура, да и вообще – agile был сформулирован как наш ответ Чемберлену, так что отличить белое от черного легко и вряд ли кто-то в здравом уме станет спорить. Сложности начинаются, когда по обе стороны неравенства оказываются не настолько взаимно отталкивающие определения. Например, RUP противопоставляется agile, или XP противопоставляется RUP, или SCRUM противопоставляется XP, или вообще agile (с маленькой буквы) подразумевает нечто отличное от Agile (с большой буквы). Да что там далеко ходить, наличие или отсутствие какой-то конкретной техники (юнит тестов, парного программирования, peer review, историй, ретроспективы, статус репорта, документации, проектного менеджера, календарного плана) часто считается крамолой, недостойной носить гордое имя agile.

А давайте проверим. Только, чур, сразу подготовим правильный инструмент. Мух от котлет по принципу «это – не методология, это – фрэймворк» мы отделять не будем. Оттенки в определениях есть, но сводятся оба термина воедино легко, и это с успехом делает заглавная статья о software development methodology на en.wikipedia, бОльшая степень свободы, ощущаемая в слове «фрэймворк» и более строгие указания к действию, ощущаемые в слове «методология», скорее стали следствием частого размежевания этих двух терминов. Мы, короче, сами это придумали, и потому без четкого объяснения «а что конкретно ты имела ввиду» пользоваться таким сравнением не очень конструктивно.

Первый тест. RUP и agile. Часто прошу кандидатов на интервью (позиция технического менеджера или, как Денис любит называть, – джедая), порассуждать на тему, является ли RUP agile методологией. Большинство не спрашивает деталей и отвечает очень коротко – нет, забывая даже подумать, поскольку ответ для многих (к сожалению, реально не знакомых с деталями и истоками RUP) – очевиден.

А вот один из моих доводов в пользу ответа Да: AUP от Скота Амблера – есть agile кастомизация RUP-а, отвечающая двенадцати принципам Agile Manifesto и обратно совместимая с RUP. Скот это декларирует в определении, и я ему доверяю, но можем и проверить, если есть сомневающиеся.

И RUP и agile во главу угла ставят итеративность, противопоставляемую водопаду, что, по всей видимости, может претендовать на первое
необходимое условие agility. RUP,
в руках Скота Амблера, несложно превратился в чистый agile инструмент. Вы спросите, как же так? Ну, все достаточно просто. RUP задуман был как конструктор, который надо выстраивать (собственно, как и agile: принципы и ценности манифеста не повесишь на ремень и в пулемет не зарядишь – надо включать голову и работать). Не умея и не понимая, можно построить себе такой итеративный водопадик, где в каждой фазе и итерации – старые песни о главном, и это не будет работать, а можно сделать так, как сделал Скот Амблер.

Вот так и получается, что и RUP и Agile на одной стороне фронта против водопада. Только RUP тяжело дается, а Agile – легче и натуральнее. Но уверенно объявлять RUP не agile методологий не корректно. Надо рассматривать конкретную имплементацию RUP-а, тогда получатся яблоки с яблоками. А с водопадом RUP не имеет ничего общего, хотя многими именно так и интерпретируется (и я был грешен когда-то – очень больно было, кстати, но об этом как-нибудь в другой раз).

Второй тест. Agile и agile. Давайте, в поисках определения, вернемся на секунду к Скоту Амблеру, который определяет agility своего AUP, как соответствие принципам agile alliance, где де в bylaws (я тут поясню, термин этот знаком американскому домовладельцу как описывающий правила поведения в своем жилищном кооперативе) приведены четыре ценности и двенадцать принципов agile manifesto.

Спорить с манифестом глупо – там все написано верно. С итеративностью мы определились уже. Авторы PMBOK, живущего вне конкретной индустрии, в третьем издании согласились, что изменения неизбежны. Это я апеллирую к одной из четырех ценностей про желание и умение принимать изменения, как, наверное, самой непросто осмысляемой – ведь так легко скинуть все на злого заказчика, который не знает, что хочет, и все время меняет требования. Похоже, что готовность к изменениям – есть второе необходимое условие agility. Все остальные постулаты аджайла – разумны, продиктованы здравым смыслом и опытом, и направлены на быстрое достижение качественного результата, который удовлетворяет клиента и доставляет удовольствие команде, его производящей.

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

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

Ну, а чтобы как-то все-таки раскрасить шкалу от agile до Agile, предлагаю вот такую градацию:

  • Agile (который с Большой Буквы) – идеальная само-организованная среда, полностью выстроенная по ценностям и принципам agile manifesto). В пределе – чистые медихлорианы и непорочное зачатие (грань между Дартом Вейдером и Спасителем стирается…)
  • agile (который с маленькой буквы) – “жидкая” (fluid) среда, приветствующая изменения, частые итерации и здравый смысл с вектором с сторону Agile (с Большой Буквы), но с хорошим противовесом в виде осознанной реальности бытия.

Делаем мы все с вами, практики аджайла, – agile, стремимся – к Agile. А когда учим других делать Agile, обязательно должны показывать пальцем на противовес и объяснять, что его наличие – есть реальность, всего лишь уменьшающая первую букву Аджайла до строчной, но не меняющая ничего в сути! А то ведь смотрят люди на граненый Аджайл в белом золоте и думают, что он им не по карману, и идут дальше валить лес двуручными пилами.

Павел Веллер

Post Author

This post was written by who has written 21 posts on Agile.by.

  • http://thetorch.ru/ Денис Петелин

    Методология и фрэймворк довольно сильно отличаются, что бы не говорила по этому поводу википедия (на нее вообще лучше не ссылаться – сам принцип “вики” для системы такого размера не очень хорош: ввиду очевидной дурости множества писателей и википедии и частой однобокости подачи информациии она например запрещена к цитированию в американских университетах. Почему? Сам суди – вот тебе выдержка из статьи про МГУ: “Правит Университетом – наимудрейший и наиблагочестивейший старец – ректор Садовничий. Дивные покои его располагаются внутри преогромной звезды из чистейшего золота, богато украшенной яхонтами, алмазами, аметистами, изумрудами, рубинами, топазами, сердоликами, хризолитами и высокочастотными передатчиками”.)

    Если ты возьмешь в руки более толковые источники, типа толкового или энциклопедического словаря, ты легко увидишь различия:
    Методология – это учение об организации деятельности; учение о структуре, логической организации, методах и средствах деятельности (CЭС).
    Framework (слово буржуйское, поэтому толкование из буржуйского словаря) is a real or conceptual structure intended to serve as a support or guide for the building or constructionsystem (SETD).

    Таким образом, методология – она тебе тебе дает принципы + описание методов и средств деятельности, объединенные в логическую структуру. Если ты вспомнишь структуру RUPа, то сразу поймешь почему это методология – там есть четкие описания шагов с разделами (методы) и кучей шаблонов + Rational Enterprise Suite (средства).

    Фрэймворк – это такая куцая методология – чисто направлющие принципы, практически ничего об их реализации. То есть принципы ты должен реализовать, но вот методы реализации – на твое полное усмотрение.
    Если RUP тебе говорит – “должен быть написан юзкейс, вот правила его написания, вот шаблон для заполнения”, то agile говорит – “чувак, надо получить требования от пользователя – суть вот такая, вот можно на бумажке, вот можно в экселе, вот можно в онтайме, тээфэсе и акуноте, а можешь придумать свой способ.” Но реализация принципов – она обязательная, понимаешь?

    В чем же прорыв аджайл-фрэймворков? В том, что методологии эволюционировали и разрослись до неприемлемых размеров, там уже не разобраться без поллитры. Именно формат записи этих инструкций “на входе то, сначала должны быть выполнены те и те действия, на выходе вот это” – приводит к тому, что для конечных пользователей RUP выглядит как водопад. Соответственно аджайл просто обнулил эти тонны инструкций – сказал “ребята, давайте вспомним про то, зачем это все делалось – про принципы!”

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

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

    Тогда возникает необходимость в “тэйлоринге”. Например. “Команда состоит из людей, которым начхать на проект? Давайте затейлорим – поставим парня с плетью, который будет трахать по утрам на скрам митинге! Чтобы получить больше прибыли надо поставить на проект людей, которые подешевле? Давайте затейлорим – вместо профессионалов поставим на проект людей без опыта и начхать что они ничерта не смыслят в OOD! Говнокод задизайнен так, что он в принципе не testable? Давайте затейлорим – выкинем к едрене фене юнит тесты! Ой, смотрите какой у нас славный аджайл получился! И затейлорен в полном соответствии с реальностью! Кто тут будет спорить?!! У меня мега-аргумент – ведь это работает!!!

    Да, чувак, это работает, но это – не аджайл. Понятно, что у тебя такие люди, что их надо трахать по утрам чтоб работали, и висеть на телефоне по 2 часа объясняя что надо сделать и что ты с ними сделаешь если они не сделают – твой рецепт работает, но не называй ты блин это аджайлом!!! Оттого что утренний трах у тебя называется “daily scrum”, а adhoc полуexploratory тестирование – agile testing, слепленная тобой поделка на станет аджайлом! Потому что суть у тебя – совсем другая.

    Если хочешь назвать это красивым словом – выбери другое. Например, девелоперы в “классическом” RUP делятся на Designer (думает и трахает реализущих) и Implementer (трахаем и реализует). Это будет гораздо ближе к сути.

    Почему меня так заботят твои ошибки, дружище?
    Потому что после твоего “аджайла” людей надо в санаторий отправлять, и еще долго они потом будут пугать твоим “аджайлом” джуниор девелоперов – как чертом маленьких детей, и когда они слышат слово agile – они его уже боятся.
    Потому что твои рассуждения о аэродинамике самолетов на материалах богатого опыта езды на телегах – они сами по себе смешны, но с предложением “практических способов” которые кто-то по неопытности попробует – просто вредны.
    Поэтому лучше пусть люди лучше пилят лес двуручными пилами, затем придумают распилочную яму, лесопилку с водяным приводом, наконец эволюционируют к бензопилам, циркуляркам и каттерам – чем затэйлорят технику безопасности, личную жизнь и наловят в лесу рабов – чтоб значит производительность повысить…

  • Konstantin Razumovsky

    Я согласен с Павлом в том, что в agile есть несколько принципиальных идей, а есть более вторичные.

    Если почитать Фоулера http://martinfowler.com/articles/newMethodology.html то в качестве основных идей он выделяет 2: адаптивность (реализуемую через итерационную разработку) и человеческий фактор. Я про это как-то писал здесь http://www.agile.by/2008/08/05/agile_is_good_for_all.html

    Единственное, что мне не понравилось – это разделение agile и Agile. Мы действительно подменяем понятия. Я лично про свои проекты предпочитаю говорить, что в них используются “некоторые принципы и практики agile”. По-моему, это более честно 🙂

    • http://thetorch.ru/ Денис Петелин

      А скажи мне, что в самолете первично – крылья или двигатель? От чего можно отказаться? А, вот шасси в принципе вторичны – их можно выкинуть! И самолет летать не прекратит, кстати – правда, после посадки “на брюхо” будет грудой мятого железа, но в принципе – да, шасси вторичны 🙂 ну и антиобледенители – в принципе дурь, летали без них 🙂 кстати, кабину герметизировать тоже необязательно – кислородная маска + меховой комбинезон выручат 🙂 Без всего это можно жить – не вопрос, но с определенного момента самолет станет крайне неприятен и пилоту, и пассажирам. А если слишком много повыкидывать – вообще не взлетит 🙂

      Поэтому мой тебе респект – за то, что четко различаешь дефиниции, и честно говоришь “элементы аджайла”. Но так делают далеко не все 🙂

  • http://www.targetprocess.com firefalcon

    Что такое аджайл, что не является аджайл, бла бла бла

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

    Прочитал. Блин, зря время потратил. Автору надо углубиться в истоки аджайл движения и сделать экскурсный заход на их связь с CAS.

  • http://www.targetprocess.com firefalcon

    Да. Целиком и полностью согласен с длинным комментарием Дениса (респект, не пожалел времени 🙂

  • Konstantin Razumovsky

    2Денис: Кстати, шасси есть не у всех самолетов. У гидросамолетов нету шасси. Но они самолеты :). Так что да, получается, у самолетов есть принципиальные возможности (летать, прежде всего), а есть опциональные, которые можно заменить чем-то другим (оставаясь при этом скорее самолетом, нежели чем-то другим) :).

  • http://thetorch.ru/ Денис Петелин

    @Konstantin Razumovskу: в точку, камрад, в точку! Практики (шасси) может и не быть, но принцип (имеется способ посадки) соблюден – введена другая практика (днище + поплавки).
    Так – настраивай хоть до посинения, но принципы – они остаются, я ж про это и пишу 🙂

  • http://pveller.blogspot.com/ Pavel Veller

    И я про то же самое, только в другой ветке. Давайте там продалжать, раз уж Денис ответил полноценным постом