Сравнивая разные подходы к организации и выполнению проектных работ, мы, так или иначе, сравниваем одно с другим и, иногда, становимся заложниками общепринятых, не всегда верно интерпретированных, или порой ошибочных клише. Обидно, когда выводы делаются из неверных посылов или, в случае правильных отправных точек, искажаются неверной интерпретацией мерила.
Проще и безопаснее всего сравнивать 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, обязательно должны показывать пальцем на противовес и объяснять, что его наличие – есть реальность, всего лишь уменьшающая первую букву Аджайла до строчной, но не меняющая ничего в сути! А то ведь смотрят люди на граненый Аджайл в белом золоте и думают, что он им не по карману, и идут дальше валить лес двуручными пилами.
Павел Веллер
Методология и фрэймворк довольно сильно отличаются, что бы не говорила по этому поводу википедия (на нее вообще лучше не ссылаться - сам принцип “вики” для системы такого размера не очень хорош: ввиду очевидной дурости множества писателей и википедии и частой однобокости подачи информациии она например запрещена к цитированию в американских университетах. Почему? Сам суди - вот тебе выдержка из статьи про МГУ: “Правит Университетом - наимудрейший и наиблагочестивейший старец - ректор Садовничий. Дивные покои его располагаются внутри преогромной звезды из чистейшего золота, богато украшенной яхонтами, алмазами, аметистами, изумрудами, рубинами, топазами, сердоликами, хризолитами и высокочастотными передатчиками”.)
Если ты возьмешь в руки более толковые источники, типа толкового или энциклопедического словаря, ты легко увидишь различия:
Методология – это учение об организации деятельности; учение о структуре, логической организации, методах и средствах деятельности (CЭС).
Framework (слово буржуйское, поэтому толкование из буржуйского словаря) is a real or conceptual structure intended to serve as a support or guide for the building or construction\system (SETD).
Таким образом, методология - она тебе тебе дает принципы + описание методов и средств деятельности, объединенные в логическую структуру. Если ты вспомнишь структуру RUPа, то сразу поймешь почему это методология - там есть четкие описания шагов с разделами (методы) и кучей шаблонов + Rational Enterprise Suite (средства).
Фрэймворк - это такая куцая методология - чисто направлющие принципы, практически ничего об их реализации. То есть принципы ты должен реализовать, но вот методы реализации - на твое полное усмотрение.
Если RUP тебе говорит - “должен быть написан юзкейс, вот правила его написания, вот шаблон для заполнения”, то agile говорит - “чувак, надо получить требования от пользователя - суть вот такая, вот можно на бумажке, вот можно в экселе, вот можно в онтайме, тээфэсе и акуноте, а можешь придумать свой способ.” Но реализация принципов - она обязательная, понимаешь?
В чем же прорыв аджайл-фрэймворков? В том, что методологии эволюционировали и разрослись до неприемлемых размеров, там уже не разобраться без поллитры. Именно формат записи этих инструкций “на входе то, сначала должны быть выполнены те и те действия, на выходе вот это” - приводит к тому, что для конечных пользователей RUP выглядит как водопад. Соответственно аджайл просто обнулил эти тонны инструкций - сказал “ребята, давайте вспомним про то, зачем это все делалось - про принципы!”
Сила аджайла заключается в наборе принципов, который обеспечивает гибкость. Именно реализация этих принципов - обеспечивает гибкость, а не произвольный отказ от принципов - это гибкость.
Набор принципов и сложность их реализации - накладывает определенные ограничения на применение. Жадность - накладывает кучу ограничений на применение. Тупость - делает его невозможным.
Тогда возникает необходимость в “тэйлоринге”. Например. “Команда состоит из людей, которым начхать на проект? Давайте затейлорим - поставим парня с плетью, который будет трахать по утрам на скрам митинге! Чтобы получить больше прибыли надо поставить на проект людей, которые подешевле? Давайте затейлорим - вместо профессионалов поставим на проект людей без опыта и начхать что они ничерта не смыслят в OOD! Говнокод задизайнен так, что он в принципе не testable? Давайте затейлорим - выкинем к едрене фене юнит тесты! Ой, смотрите какой у нас славный аджайл получился! И затейлорен в полном соответствии с реальностью! Кто тут будет спорить?!! У меня мега-аргумент - ведь это работает!!!”
Да, чувак, это работает, но это - не аджайл. Понятно, что у тебя такие люди, что их надо трахать по утрам чтоб работали, и висеть на телефоне по 2 часа объясняя что надо сделать и что ты с ними сделаешь если они не сделают - твой рецепт работает, но не называй ты блин это аджайлом!!! Оттого что утренний трах у тебя называется “daily scrum”, а adhoc полуexploratory тестирование - agile testing, слепленная тобой поделка на станет аджайлом! Потому что суть у тебя - совсем другая.
Если хочешь назвать это красивым словом - выбери другое. Например, девелоперы в “классическом” RUP делятся на Designer (думает и трахает реализущих) и Implementer (трахаем и реализует). Это будет гораздо ближе к сути.
Почему меня так заботят твои ошибки, дружище?
Потому что после твоего “аджайла” людей надо в санаторий отправлять, и еще долго они потом будут пугать твоим “аджайлом” джуниор девелоперов - как чертом маленьких детей, и когда они слышат слово agile - они его уже боятся.
Потому что твои рассуждения о аэродинамике самолетов на материалах богатого опыта езды на телегах - они сами по себе смешны, но с предложением “практических способов” которые кто-то по неопытности попробует - просто вредны.
Поэтому лучше пусть люди лучше пилят лес двуручными пилами, затем придумают распилочную яму, лесопилку с водяным приводом, наконец эволюционируют к бензопилам, циркуляркам и каттерам - чем затэйлорят технику безопасности, личную жизнь и наловят в лесу рабов - чтоб значит производительность повысить…