Не знаю, как в других странах, а у нас любят увлекаться идеей использовать какой-то, довольно узкий, инструмент, как панацею.
Получилось забить гвоздь молотком – получилось. Давайте попробуем с помощью молотка почистить фарфоровую посуду от налета. Ну очевидно же!
Не избежал этой участи и пресловутый Agile. Так называемые гибкие методологии разработки. Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности, в обучении – всюду, куда фантазии хватит его вставить.
А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Тезис: agile – только для простых проектов!
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Простыми словами – заказчику не нужно напрягать голову в момент согласования заказа – приходи хоть через месяц, хоть через год, и говори: «Ой, я забыл совсем – вот тут нужно еще добавить вот это, а вот это должно быть не зеленым, а коричневым». И команда-исполнитель это должна принимать.
Выгодно это заказчику? Конечно, заказчику это выгодно. Выгодно это исполнителю? Очевидно, что нет. Лишняя работа за бесплатно.
Но проблема, на самом деле, еще глубже, чем дополнительные нагрузки на исполнителей. Дело в том, что гибкие методологии можно использовать только на простых проектах. И категорически противопоказано их использовать на сложных.
Два простых примера
Первый пример
Приходит заказчик (мэрия города) в артель, занимающуюся изготовлением уличного инвентаря, и говорит: «Мы открываем новый парк в N-ском районе, нам нужно для парка 20 лавок, каждая лавка должна быть рассчитана на 3-х человек».
Артельщики говорят: «Не вопрос – у лавки будет одна секция и две опорные металлические стойки. Вот дизайн, вот стоимость, срок – 3 недели».
Мэрия говорит: «По рукам».
Второй пример
Приходит какой-нибудь умник с мешком денег в аэрокосмическое агентство условной страны Y и говорит: «Хочу организовать туристический маршрут на орбиту – нужна ракета, способная брать на борт 3-х человек».
В агентстве умнику говорят: «Хорошо, вот вам смета, вот сроки – 5 лет».
А теперь применим правило гибких методологий – прием изменений в проект на любых стадиях проекта.
В первом примере.
Приходит заказчик (мэрия города) в артель через две недели после начала работы и говорит: «Вы знаете, мы просчитались, в N-ском районе живет в два раза больше людей, поэтому нам нужно для парка 20 лавок не по 3 человека на лавку, а по 6».
Артельщики говорят: «Не вопрос – нам нужно будет для лавки 2 секции, вместо одной, и 3 стойки вместо двух. Мы уже купили короткие доски, а нам теперь нужны длинные. Оплачивайте дополнительные стойки, уже купленные короткие доски и новые длинные и все сделаем».
Т.е. стоимость проекта вырастет более чем на 50% от первоначальной сметы, но, во всяком случае, проект может быть выполнен и будет выполнен в заявленные сроки – никаких существенных препятствий для этого нет.
А теперь посмотрим, что произойдет во втором примере.
Приходит умник в аэрокосмическое агентство через 2 года после начала проекта и говорит: «Вы знаете, я пересчитал бизнес-план, мне мало 3-х человек, мне нужно выводить на орбиту минимум шесть, чтобы проект был рентабельным».
Ракетчики смотрят на умника как на идиота и говорят: «Вы понимаете, что это совсем другая задача? Если будет не 3 человека, а 6 – это не только увеличение выводимой на орбиту массы в два раза, это еще и дополнительный запас кислорода, это увеличение жилого пространства в ракете в 2 раза, это увеличение топливных баков, это другая обшивка – это совершенно новый проект! Более того, сейчас не только таких двигателей может не быть, может еще просто не существовать технологий, чтобы их строить.
Итого, что в итоге – простые проекты по гибкой методологии делать можно. Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ изначально.
У всех методов есть рамки применения. Они не универсальны. Нужно об этом всегда помнить.