Why Agile

Вынесу из комментов, как говорится. Раз в год кто-то с пеной у рта начинает рассказывать окружающим, что «agile говно».
Совпадения, если что, случайны.

Логичный ответ всегда на подобное — готовить не умеете.
Эт понятно. Но есть нюанс.

Как и любая другая методология.

Все равно что спорить, какая отвертка лучше: плоская или крестовая.
Нравиться может любая, а брать ты будешь ту, которая подходит.

С точки зрения «планирования и предсказуемости» процесса разработки, наиболее выигрышный и стабильный вариант для самого процесса — это waterfall, конвенциональная модель. Написали план в начале и «на берегу», посмотрели взаимозависимости, прикинули бюджет и сроки, гантт вырисовался, го пилить. Единственное, что спросят с исполнителей — сроки и результат. Затраты на план вот такие, через полгода родят.

С веской оговоркой.
Если через полгода родят не то, что было реально нужно бизнесу — включай кризис-менеджмент.

Можете работать по waterfall, позволяет вам задача и заказчик — работайте конечно. Кто ж вам запретит. Спокойно, предсказуемо, здорово и вечно.

Agile, как концепция — или правильнее сказать, винегрет из подходов, «гибкие методологии» — сложился не сам по себе. Жизнь заставила. Отчасти поэтому и винегрет такой, немного полужопый и не очень консистентный.

Гибкость подходов (планов, оценок, самой работы) это именно то, за что традиционно на agile выливают ведро говен, заслуженно либо не очень.

Ребята, agile для этого и создавался.

В реальном мире чаще всего перед бизнесом стоит океан неопределенности.

• Будет ли рынок на том же месте — хз, скорее всего нет.
• Будет ли ситуация соответствовать ожидаемой? Вряд ли.
• Будет ли видение продукта, оффера, приоритетов разработки статичным — неа. Практически точно будет корректироваться (а возможно вплоть до противоположной версии).
• Есть шансы, что на рынке поменяется расклад сил, например стараниями конкурентов? Да запросто.

И через полгода ватерфолла получившееся можно будет с грустью выкинуть в утиль. Или запланировать еще один цикл разработки (еще на полгода).
Думаю, понимаете наглядную коллизию.

Исполнителям прикольно пилить проект по стабильным требованиям, и жечь ФОТ. Вот только нет тех стабильных требований — ситуация не та.
Значит, заказчик выбирает гибкие методологии — или тех, кто способен по ним работать, и выдавать продукт. Другого варианта просто нет в рассмотрении. Не нравится, щито поделать.

Напомню, что основная идея agile как подхода и методики — в том, что план можно и нужно менять. Всё остальное — механики и следствия.

Перед вами стоит задача: родить продукт / решение / бизнес. И вы реально не знаете, как оно будет пилиться и взаимодействовать с реальным миром. По мере разработки, внедрения, тестов, обкаток итд итп.

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

Вот на эти две недели вы план и пишете. И целей у вас фундаментальных (для этого плана, или для любого другого) всего несколько:

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

Ключевое слово здесь, понятно, итерация.
Слона нужно кушать по частям.

План на итерацию — не единственный ваш план. Будут и побольше, и поменьше. И глобальный план приёмки, OKR + Definition of Done. И локальные, и по-фичам, и бюджетирование, и интеграции. Главное всё еще остается в силе: планы можно и нужно менять. Корректировать по обратной связи на земле.

Отдельный момент есть в том, что «управления требованиями в agile нет» как почему-то считает русскоязычная тусовочка. Не, котаны, это заблуждение: википедия вам говорит, что управления требованиями внутри agile нет. Не включено в винегрет. А у вас оно есть. Выбирайте любое, хоть все сразу (на разные части продукта, например).

Agile не рестриктивная методология, это тупо сборник практик. Добавляйте любые подходящие по вкусу, никто вам не запрещает.

Дальше для рукопахарей и малых команд вы имеете и согласовываете план на итерацию. Итерация классическая 2 недели (спринт), можете хоть неделю взять, или месяц, или 3 дня — дело ваше. Внутри итерации план менять не принято, чисто ради того, чтобы люди не бегали в пересогласовывании планов, а имели возможность спокойно предсказуемо работать.

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

Не надо их бросаться делать. Их надо записать.

А делать надо то, что лучше всего вписывается в цели тактического плана (см выше). Вы не впихнёте все хотелки в 2 недели, очевидно, вы не впихнёте их и в год, с риском получить неподъемный план и дорогущий комбайн. Ваша задача — выбрать то, что приближает вас к релизу, убирает неопределенность и прорабатывает риски.

В тёрках «agile или не agile» бывает полезно вспомнить, что кроме «гибкого и негибкого» подходов есть промежуточные идеи, концепции, методологии. Начиная с RUP (rational unified), где — кстати — есть итерации.

Как-то же люди поднимали проекты, задолго до появления относительно молодого agile.

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