Инди-команда познает agile

Мы — инди-команда, разрабатываем браузерную MMORPG Ligmar, интегрированную в мини-приложение Telegram. Как и многие другие инди-разработчики, мы сталкиваемся с ситуациями, когда амбиции расходятся с реальными возможностями. Например, внедрение функции Orbs отлично показало, как ошибки в управлении разработкой могут создать непредвиденные проблемы — хотя изначально казалось, что это небольшая задача, не требующая много времени.

Что такое орбы? В популярной игре Path of Exile божественные орбы используются для пересчёта значений случайных модификаторов на редких предметах. Но орбы как механика давно стали неотъемлемой частью большинства MMORPG. Они ускоряют прогресс, помогают добыть нужные предметы и дают тактические преимущества.

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

Мы планировали добавить в игру три магические сферы, временно усиливающие персонажа: увеличение опыта, серебра и количества добываемых предметов. Концепция понятная, механика — полезная. Мы быстро согласовали идею, написали ТЗ и приступили к работе. Но, как часто бывает, дьявол скрылся в мелочах.

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

В результате простая идея «купить, использовать, продать» разрослась в целый пласт дополнительных задач, затронувших механику инвентаря, торговли и взаимодействия с предметами. Каждая упущенная деталь на этапе проектирования значительно усложнила изначальную задачу.

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

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

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

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