Почему мне не нравится манифест agile?

26 November 2019

Моя любимая тема. Любимее чем история и общественные отношения вместе взятые. По Agile сейчас, наверное, работает подавляющее число компаний и команд. На этой методологии основывается весь современный рынок ПО. Все же знают про эти постоянные обновления с припиской «bug fixes»? Вот это как раз регулярная и ранняя поставка, о чем чуть ниже. Давайте я возьму основополагающие принципы Agile-манифеста и озвучу свое мнение об этом. В очередной раз оговорюсь - мнение (!!!) , моё(!!!). Вы лично не согласны? Ну ради бога, я не против. Я не прав? Покажите где и почему. Итак, начинаем.

Сразу хочу сказать общую проблему. Весь манифест переполнен терминологией без определений. Следовательно, каждый может под этими словами понимать всё, что захочет в меру своей испорченности и образованности. Что видимо, дает еще одну степень «гибкости».

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

Тут на мой взгляд сразу 3 слабых места.

1) Кто заказчик? Руководитель, желающий создать новый продукт? Конечный клиент? Ну так вот удовлетворение руководителя и удовлетворение конечного клиента – не одно и тоже. Более того – я считаю что порой они прямо противоположны.

2) Регулярная и ранняя поставка. Не, это конечно классно. Но это с гарантией порождает баги. Я уже однажды писал что это нормальное явление для Agile. Практика показывает что, например, в отрасли игровых проектов выпустить на рынок забагованный продукт и полгода накатывать обновления для их исправления – вполне нормальное явление.

3) Ценное программное обеспечение. А кто определяет ценность? Заказчик? Ну, так он не конкретен, как я только что написал. И ценность тут не может быть точно описанной.

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

Сложный вопрос. Тут уже немного уточняется, что заказчик это ваш руководитель. Тут, я думаю, следует немного оговориться. Манифест и его принципы опубликованы в 2001 году. Прошло без малого 20 лет. В 2001, может быть, идея сферической конкуренции в вакууме еще теплилась в умах, но сегодня вроде как очевидно, что чуть ли не половина рынка ПО – монополии. Да, есть островки мелких рыночков, где вроде что-то похожее на конкуренцию еще живет. Но где конкуренция на рынке операционных систем? Серверного ПО? Мобильных операционных систем? Скажите, что Android и iOS серьезно конкурируют друг с другом? Как там дела с конкуренцией социальных сетей? Если кто-то сможет привести пример реального конкурентного рынка – напишите, пожалуйста.

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Что такое работающий продукт? Выведенный, в промышленную эксплуатацию? А что мешает вывести в промышленную эксплуатацию забагованную ерунду и раз в 2 недели фиксить баги? Ну т.е. примерно так как сейчас происходит повсеместно. Кстати, что можно сделать за 2 недели на крупном проекте, кроме как пофиксить горсть багов и небольшое декоративное улучшение – я не уверен и, наверное, напишу об этом отдельную статью.

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Вот это надо написать на флаге и гордо нести на демонстрации. Желательно сделав максимально целеустремленный и максимально непонимающий взгляд. Что значит вместе? В одной компании? В одном кабинете? Постоянно общаться? А когда разработкой заниматься?

Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

Мотивированные чем? Профессионалы в чем? Приведу ссылки: 1, 2, 3, 4, 5, 6. Эти компании, наверное, не следуют методологии Agile? Или следуют? Или следуют, но кроме этого пункта? Поиск названий компании в паре со словом Agile без проблем находят статьи о том как они успешно ее используют. К сожалению не могу искать по списку подписавших манифест. Кстати, обратите внимание, продукты получились хорошие.

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Да, согласен. С парой оговорок.

1) Каков размер команды? Если больше 10, то обмен информации быстро превратится в галдеж и понадобится твердая рука руководителя.

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

Работающий продукт — основной показатель прогресса.

Снова возвращаемся к определению «работающего продукта». Правда, в этот раз подмешиваем слово прогресс. Прогресс в чем? Звучит как оправдание. Вроде как запустили продукт в пром и всё, значит поработали. Продукт никто не приобрел? Оказался убыточен? Пфф, он работающий – у нас прогресс.

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

Тут я даже растерялся. Пошел читать текст принципа в оригинале, может перевод подвел. В оригинале использовалось слово pace (шаг/темп). Постоянный ритм/темп чего? Ну предположим работы. Это логично и я с этим согласен. Но при чем здесь пользователи? Они что должны поддерживать? Постоянно обновлять продукт, чтоли? Я своей маме теперь должен объяснить принципы Agile?

Простота — искусство минимизации лишней работы — крайне необходима.

Согласен. Простота это хорошо. Простой, краткий код это отлично. Вопрос – причем тут Agile? Это как заявление что за миролюбие выступают только христиане. Нет, это не так. Принцип хороший, но он не может быть отнесен к конкретной методологии. Он должен быть немного выше их.

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

Это кто вам сказал? Авторы сами себе это заявили? Или собирали статистику какую-то? Я вообще думал, что требования формирует заказчик и согласовывает с исполнителем. А оказывается - требования рождаются в команде. Обращаю внимание – «рождаются».

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

Это что называется – проведение ретроспективы. Согласен, но тут есть небольшое противоречие. Невозможно бесконечно «улучшать эффективность». Следовательно, она проседает. А если она не проседает? Тогда можно не проводить эти встречи? Тогда мы снова, получается, вступаем в противоречие с принципами. Поддерживать высокий уровень эффективности? С этим согласен полностью, но это немного другой принцип.

Что в итоге? Плох ли Agile – нет, не плох. Можно ли по этим принципам работать? Да, можно. Однако хочется провести немного странную аналогию. Вот есть 10 библейских заповедей, и есть тонны книг религиозной направленности. Являются ли эти книги каноном, решает вселенский собор. А теперь у нас есть 12 заповедей Agile, где сомнительных, неоднозначных мест гораздо больше и есть стопки книг и статей с пояснениями. Вопрос – кто решает, какие из этих статей будут каноном, а какие ересью? Каждый сам за себя? С гарантией получится полное непонимание сути методологии. Ну и даже если утвердится некий более конкретный список принципов с определениями – всегда будут люди, которые будут относиться к этому принципу как к религиозному, и в итоге, следование принципам превратится в процесс ради процесса. Думаете, я сгущаю краски? Ну, может быть. Согласился бы полностью – если бы не знал лично руководителей, пытающихся насильно ввести «покер планирования» с лицом «вот сейчас введем и все сразу зацветёт».