Agile — это ценности, а не методология

Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:

1. Люди и взаимодействие важнее процессов и инструментов.

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

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

   Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.

Waterfall: миф о жестком подходе

Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.

Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)

5. Внедрение (Подготовка и передача программы)

Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:

1. Устранение ошибок.

2. Развитие и усовершенствование продукта.

Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.

Почему возникает миф о несовместимости?

Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».

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

Однако в реальности:

Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками.
Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum.
Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.

Синтез вместо конфронтации: гибридные подходы

На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например:
Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.

Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.

Как же выбирать методологию? Нужно опираться на критерии, а не догмы
Выбор между Waterfall и итерационными методами зависит от четырёх факторов:

1. Предсказуемость требований.
   Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.

2. Стоимость изменений.
   В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.

3. Регуляторные ограничения.
   В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.

4. Культура команды и заказчика.
   Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.

Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum

Заключение: за пределами маркетинговых мифов

Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:

1. Какова степень неопределённости требований?

2. Какие ограничения накладывают регуляторы или бюджет?

3. Насколько команда и заказчик готовы к гибкости?

Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:

1. Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».

2. Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).

3. Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.

Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.

- Настройка событий. Этот этап происходит одновременно со сборкой блокаута и является его неотъемлемой частью. События влияют на то, какие ощущения испытывает игрок во время прохождения, какие механики и действия ему доступны. Сюда можно отнести расстановку чек-поинтов в гоночном режиме, расставление ловушек и “абилок”, добавление интерактивности: взрывающиеся двери, сбивающие насмерть поезда, ломающиеся от удара предметы, запуск примитивных анимаций и кат-сцен.

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

- Конечный вариант. Он подводит итоги всей проделанной ранее работы. В нём объединяются концепт, основная идея, референсы и наброски, а затем серые кубы блокаута заменяются на готовые модели. Окружение прорабатывается, настраивается освещение, проводится оптимизация.

И на этом всё. Карта готова! Хотя ещё предстоит финальное тестирование и полировка отдельных моментов, но это уже мелочи жизни :)

Про каждый из пунктов создания уровня на самом деле можно было бы расписать по целому посту. Есть очень много технических моментов, разных инструментов и прочего, здесь же мы лишь кратко описали основные моменты. Так что, если интересно, обязательно маякните в комментариях!

Наш Steam

Актуальные новости в Telegram

1 Битва. Prosody не видит токены. Видишь токены? и я не вижу, а он есть.
в логах пишет:
modulemanager: Unable to load module 'auth_token': /usr/lib/prosody/.../mod_auth_token.lua: No such file or directory modulemanager: Error initializing module 'auth_token': module 'inspect' not found:
Суть оказалась проста, Prosody искал плагины не там, где они были. так же ему не хватало библиотеки из Lua, которая нужна для работы в jwt. Собственно, через luarocks поставил inspect.
так же в конфигах нужно прописать путь к плагинам : plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }, кто поймет, тот поймет, а кто не поймет, тот не поймет. Да, я капитан очевидность. И..... Prosody таки увидел плагины и начал их грузить!

2 Битва. Пользователи таки стали проходить аутентификацию, но когда подключается второй клиент - давай до свидания, вылетают тут же оба. Client disconnected: connection closed. Сразу оба два.

В настройках : c2s_require_encryption = true а было false, не помогло, если что, это это настройка Prosody XMPP сервера, опять же, кто то понял, кто то нет. да и какая разница. А, ну да, эта настройка определяет обязательно ли шифрование или нет. Вскрытие показало что пациент умер от вскрытия. По любому этот параметр тоже влиял, но, как могла подумать моя многоуважаемая публика, а может и не влиял. Скорее всего да. Но, визуально ничего не поменялось, ошибки все те же самые.

Хм..... хмыкнул я, но и это не помогло. а вдруг права доступа к файлам не права доступа к файлам? а вдруг все под рутом? А у Prosody и пользователь prosody. Права установил, но и это не помогло! Хотя, вскрытие показало что все файлы были под правами рута. При этом Jicofo очень даже молодец, видит, принимает. Если что, он отвечает за управление, фокусировку, координацию участников.

Но вылеты при коннекте продолжаются.

3 Битва. Финал. Порты.

Ну по логике, когда подключение без токенов, оно работает, ну значит и машина не виновата же? А вот Фиг Вам, называется, привет, Шарик. Вскрытие в очередной раз показало что без токенов коннектится по порту 443/TCP, а с токенами используются чуть чуть другие порты, которые для медиа более эффективны: 10000/UDP и 4443/TCP.

Ну а поскольку я брал облачный vps в timeweb (ни в коем случае не реклама) то стало быть настройки где то там в панели. И, в кое то веки вскрытие показало что пациент ожил от вскрытия!!! Оно стало работать!

после выхода с конференции перекидывает на главную страницу

Да, у меня два монитора, очень удобно,

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

Как то так, всем спасибо за внимание!