Сравнивая разные подходы к организации и выполнению проектных работ, мы, так или иначе, сравниваем одно с другим и, иногда, становимся заложниками общепринятых, не всегда верно интерпретированных, или порой ошибочных клише. Обидно, когда выводы делаются из неверных посылов или, в случае правильных отправных точек, искажаются неверной интерпретацией мерила.
Проще и безопаснее всего сравнивать 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, обязательно должны показывать пальцем на противовес и объяснять, что его наличие – есть реальность, всего лишь уменьшающая первую букву Аджайла до строчной, но не меняющая ничего в сути! А то ведь смотрят люди на граненый Аджайл в белом золоте и думают, что он им не по карману, и идут дальше валить лес двуручными пилами.
Павел Веллер
