Фанатичная уверенность в своей правоте и агрессивный рекламный напор Agile-евангелистов оставили после себя поля заваленных проектов, руины бизнес-начинаний и заблудших неофитов, всё ещё блеющих избитые истины забытых пророков. Индустрия разработки игр не исключение в данном случае и также ещё только начинает осознавать масштаб фантасмагории и её результаты.
Конечно, всегда были более осознанные разработчики, которые не поддались уговорам и влиянию никуда негодных "консультантов", даже если они предлагали громкие сертификаты и все прочее. Сейчас среди прогрессивных специалистов часто говорят о так называемых post-agile практиках, ранее известных как здравый смысл.
Но распространяется этот самый здравый смысл пока ещё медленно. Если мне придётся ещё раз просидеть на митинге с каким-нибудь очередным agile неудачником, упорно защищающим свой подход к разработке катящегося в бездну проекта, это всё приведёт к принудительному канбану (японская система синхронизации работы на заводах с раздачей карточек с требованиями), где никаким scrum'ом и не пахнет. И не то чтобы я имел что-то против agile, скорее совсем наоборот, но в конце дня мне надо сделать поставку, а не бороться с ветряными мельницами.
Опыт управления проектами в индустрии, которая только выходит из подросткового возраста, набирается методом проб и ошибок. Прежде чем делать какие-то выводы о современном состоянии дел в гейм-индустрии, стоит сделать шаг назад и рассмотреть подробнее саму agile методику, разобраться, что она из себя представляет.
Я работаю техническим директором большой студии, и поэтому под моим контролем находятся все проекты компании. Кроме того мне приходится и вплотную общаться и тесно взаимодействовать с издателями и коллегами по отрасли. Неудивительно, что у меня по долгу службы хватает возможностей увидеть всевозможные стили управления разработкой, так сказать, ”в живую”. Agile стал одним основным трендом в последние годы, но кроме него самого стоит уделить внимание другим, сопутствующим данной методике трендам.
В первую очередь многие уверены, что слова agile и scrum взаимозаменяемы, и мысль о том, что это два независимых понятия кажется им совершенно чужеродной и инопланетной. Несмотря на распространённость scrum'а, ощущается недостаток чёткого понимания scrum-отношений во многих командах. Если проследить, что собственно делают команды день за днём, можно заметить, что "scrum" на удивление разнообразен и вариативен. Иногда, даже сложно найти связь между тем, что команды делают и тем, что в моём понимании они должны были бы делать.
Другим распространённым мнением является то, что альтернативой agile является waterfall. Многие действительно так думают. В результате, если ты не приверженец agile, то ты — ретроград, застрявший в прошлом, и отчаянно за это самое прошлое цепляющийся. Тебе нужно прозреть, просветлиться, или, что ещё хуже, как оказывается, ты просто не способен понять, как на самом деле надо действовать.
Мы все с вами, наверное, в какой-то момент испытали на себе все прелести плохого менеджмента и поэтому прекрасно пониманием тоску девелоперов в таких случаях, и их стенания по поводу организации более человеческого и вменяемого рабочего процесса, а agile как раз выглядит такой симпатичной альтернативой традиционным правилам и распорядку. В то же самое время менеджмент самого себя постоянно жалеет, сетуя на то, какие же всё-таки наивные девелоперы, и как они мало понимают реальности ведения бизнеса.
Существует общее недопонимание того, что из себя в действительности представляет agile, какие вопросы данная методика ставит перед командой и как вписывается в общую картину создания какого-либо решения. К сожалению, подобное неведение, а иногда и даже невежество, не позволяет многим вести конструктивный диалог и мне зачастую приходится тратить довольно много времени, чтобы сломать, наконец, бесполезные философские барьеры в сознании собеседника, прежде чем перейти к обсуждению актуальных проблем. А это, откровенно говоря, весьма раздражает, ведь всё самое важное часто остаётся не раскрытым за всеми этими разглагольствованиями.
Многие думают, что agile это какая-то исключительно новая практика и посвящена решению каких-то совсем свежих вопросов, буквально только сейчас ставших актуальными. Вообще-то, менеджмент проектов насчитывает в своей истории сотни лет, да и в сфере разработке ПО его история идёт не один десяток лет. Если брать за основу идеи о реализации как можно более эффективного производства, то тогда agile мышление существует как минимум с 40-ых годов прошлого века. В любом случае, agile родился в результате обобщения большого количества знаний, эмпирических данных и практического опыта, на основе которых, и были сделаны некоторые осмысленные заключения и придуманы правила.
Если же возвращаться обратно к разработке ПО, то если приглядеться, то можно заметить, что существует не так уж и мало формализованных методик ведения разработки, а не только Scrum или Waterfall. Вот несколько, навскидку:
Некоторые из них считаются преимущественно agile методиками, некоторые нет. Все из них имеют своих приверженцев, и на каждой из них было успешно реализовано множество проектов, что вызывает естественно возникающие вопросы:
Если они все успешны, то почему так важно, какую из них в конкретном случае надо использовать? Может некоторые из них более эффективны, чем другие? Тогда почему и чем? Если есть больше чем один подход к agile, то почему именно scrum так популярен? Он действительно лучший в своём классе или у него просто более звучный пиар?
Разумеется, мы не первые, кто задаётся подобными вопросами в попытках оценить эффективность различных техник менеджмента проекта. Например, американское министерство обороны, разработало Capability Maturity Model (CMM) специально для оценки способностей разработки и управления проектами у потенциальных военных подрядчиков.
Но, так или иначе, начнём с менее глобального вопроса.
Из перечисленных выше методологий, какие более соответствуют принципам agile, а какие менее?
Простой вопрос, но для ответа для него нам нужно напомнить формальное значение термина "agile". К счастью разногласий здесь быть особо не должно, поскольку Agile Манифест приводит нам достаточно ясную формулировку. Вообще мне нравится манифест, поскольку он показывает ясное понимание что такое, процесс разработки ПО и предлагает хорошо продуманную систему ценностей. Он содержит важные идеи, которые никто не должен пропустить.
Рассмотрим первый принцип: Люди и их взаимодействие важнее, чем процессы и средства. Смелое заявление от авторов манифеста (не зря оно и первым идёт), ставящее личное взаимодействие выше процессо-ориентированных аспектов разработки.
Оно даёт нам более чёткий способ ранжирования методик по соответствию их agile принципам. Техники, сфокусированные на самих разработчиках более agile, чем процессо-ориентированные. Конечно, это только один пункт для сравнения и подобная классификация методик будет слишком грубой и сырой, но взять её на заметку стоит.
Уточним, что подразумевается под терминами "человеко-ориентированный" и "процессо-ориентированный".
Идея процесса имеет явно "политический" подтекст и поэтому люди так эмоционально реагируют, когда слышат о "методологиях" управления проектом. Ведёт данная идея к более фундаментальным и при этом более общим концепциям.
Процесс — это инструмент власти. Процесс — это утверждение о том, что как и в каком порядке надо делать. Процесс консервативен, иерархичен и формализован. Процесс устанавливает статус-кво в игре. С его помощью менеджмент наводит порядок сверху вниз. Если бы процесс был политической партией, он бы принадлежал к правому гегелевскому лагерю.
Альтернативой процессу является делегирование ответственности, доверие лицам на местах должным образом организовать себя, поскольку они лучше знают конкретные задачи, и поэтому так будет эффективнее, а сама разработка соответственно продуктивнее. Самоорганизация либеральна, "коммунальна", неформальна и даёт шанс каждому проявить свои способности. Она зарождается и идёт снизу вверх. Если продолжать политические метафоры, то самоорганизация — это партия хиппи в одежде из конопли и левацкими убеждениями.
Если говорить более конкретно и попытаться материализовать столь общие слова, будем считать процесс принадлежностью и чертой традиционного типа разработки ПО, а самоорганизацию своеобразной софтварной вольницей-партизанщиной.
М-да, не особо получилось материализовать, поэтому совсем неудивительно, что вокруг данного дискурса постоянно ведутся эмоциональные дискуссии. Подобная условность и неопределённость — плодородная почва для агитации и слепой веры в свою правоту. Не спрашивали себя, почему существует именно манифест agile? Это по сути как раз какое-то воззвание, можно сказать политическая позиция, а не какая-то объективная позиция.
Я не партизан, но и к другому лагерю также не принадлежу. Я просто заинтересован в получении конечного результата, и у меня нет времени защищать какую-то конкретную точку зрения. А для эффективного получения результата и вовремя необходимо быть гибким (хотя и не всегда, я бы добавил), так что главное понимать правильно, чего полезного можно получить от обоих подходов.
Итак, что же хорошего в процессах?
Повторяющиеся и предсказуемые результаты
Гарантии качества (за счёт предсказуемости)
Экономия средств за счет возможности оптимизировать рабочие процессы
Определённый конкретизированный поток работ позволяет нам использовать дешевый труд
Возможность распространения передового опыта и сохранение концептуальной целостности проекта
Возможность масштабирования
Возможность эффективного отслеживания прогресса согласно поставленным целям
McDonalds является прекрасным примером успешного процесса. Неважно, где вы находитесь в мире, вы знаете, что вы получите, и что вы получите это быстро и дешево. Этот процесс успешно масштабируется до тысяч ресторанов. В независимости от того нравится вам фастфуд или нет, но с результатами спорить трудно.
Тем не менее, разработка программного обеспечения намного сложнее, чем жарка бургеров. Процесс в случае ПО может быть неподходящим или неконструктивным.
Процесс может:
Увеличить расходы и снизить производительность через бюрократические издержки и потерю времени
Мешать нашей способности изменятся и адаптироваться к новой ситуации
Задушить нашу тягу к новаторству и творчеству
Требуют дисциплины и подготовки
Эффективно применим только для известных величин
Вполне логично, что данные утверждения обратны для человеко-ориентированного подхода.
Если доводить до крайностей, то в случае процесса проект начнёт задыхаться от бюрократической волокиты, заполнения бесконечных отчётов и форм (как это бывает, когда чем-то занимается государство). В обратном случае — при отсутствии процесса в принципе, проект превратится в хаотический беспорядок нескоординированных действий, приводящих к потере энергии впустую и крохами на выходе (э, ну да, это как когда чем-то занимается государство).
Разумеется, это всё крайности и никогда не бывает так в реальности, что был только жёсткий процесс или только анархичная вольница. Хитрость состоит в том, что надо уметь определять когда нам необходим чёткий процесс, а на каком этапе можно расслабить обстановку и снизить строгость требований. Хороший менеджмент — это, прежде всего гибкость расстановки приоритетов и понимания, когда применять тот или иной подход. Множество проектов было завалено только по тому, что на них пытались применить целиком и не меняя набор действий и техник, которые себя успешно зарекомендовали в предыдущий раз, не понимая толком того, что в действительности привело предыдущий проект к успеху.
Все проекты имеют свои важные моменты, различные критерии, которым необходимо соответствовать и удовлетворять, чтобы соблюдать баланс. Когда я сажусь в 747-й для трансатлантического перелёта, для меня всё-таки действительно важно долететь до места назначения, а не грохнуться где-нибудь посреди океана, поскольку какой-то клоун точку с запятой не поставил. Это несколько проблематично перезапустить самолёт после крушения, чтобы посмотреть "не будет ли он ещё падать". Критически важные с точки зрения безопасности системы требуют гарантий того, что они будут корректно работать в рамках чётко прописанных параметров и условий. Безопасность в данном случае куда важнее стоимости и скорости разработки, и именно процесс нам может дать необходимые гарантии.
С другой стороны обновлять e-commerce сайт информацией и материалами о новых скидках или ещё чего-нибудь требует реагировать быстро, и здесь вольница agile даёт нам возможность сделать это быстр и избежав рутины.
Не будем ударяться в крайности — даже для очень похожих проектов цели могут быть разными. В гейм-девелопменте, к примеру, сохранить бюджет под контролем и при этом успеть попасть на полки к Рождеству может быть критически важным для проекта. Поскольку создание нового бренда может быть важнее качества.
Давайте закончим с представлением и рассуждениями, время расставить наши методы, согласно тому, насколько они процессо или человеко-ориентированы.
Вы, наверное, хотите спросить, почему я решил, что какой-то конкретный метод более или менее процессо-ориентирован, чем другой. Всё субъективно, и вы вполне можете не согласиться с моей позицией, и вполне возможно будете правы.
Проблема в том, что каждый конкретный метод содержит микс из различных (и вполне вероятно пересекающихся) практик. Кроме того уровень строгости и степень формализованности процесса могут меняться в зависимости от конкретного случая использования
Рассмотрим Scrum. Прежде всего, Scrum это:
Спринты
Scrum роли
Митинг по планированию спринта (sprint planning meeting)
Ретроспектива спринта
Демонстрационный митинг (Sprint Review Meeting)
Истории (user stories)
Ежедневный митинг (Daily scrums)
Предварительный cписок запросов на выполнение работ (Estimated Backlog)
Burn Down Charts
Планирование релиза (Release Planning)
Стэйкхолдеры (Stakeholders Collaboration)
Кроме того в понятие Scrum включают такие практики как:
Task Boards (канбан)
Test Driven Design (TDD)
Очевидно, что некоторые из этих понятий скорее человеко-ориентированные, например daily scrums, а вот TDD и Burn Down Charts, на мой взгляд, скорее относятся к характеристикам процессного подхода.
Майкрософт опубликовал данные, полученные эмпирическим путём, о том, что TDD техника разработки увеличивает размер затрачиваемых усилий на 15-35%. Несмотря на все выгоды от применения TDD, мы не можем себе позволять себе тратить дополнительно 35 процентов времени на артефакты, которые заказчик никогда не увидит. Удивительно, но при этом люди всё ещё пытаются связать данную технику с agile разработкой.
Чтобы получить более точную картину, мы должны рассматривать каждую методологию, как динамичный диапазон действий, охватывающий все мероприятия, которое выполняются в соответствии с фактической реальной практикой.
Я хотел бы подчеркнуть, что когда мы переходим к деталям, определяя, что agile, а что не agile, нельзя прямо и чётко сказать, что это надо использовать, а это не надо. Agile является необходимым и важным контрапунктом традиционного мышления разработки программного обеспечения, но при этом является лишь малой частью общей картины.
Я видел очень успешные agile команды, но и много других, которые терпели неудачу за неудачей. Точно также есть команды, которые успешно работают по процессной методике, а есть постоянно неуспевающие к дедлайну. Очевидно, что успешность проекта далеко не определяется каким-то конкретным подходом к управлению разработкой, и проблема куда сложнее, чем мы могли подумать сначала.
Есть много вещей, которые вносят вклад в будущий успех проекта и не все они определяются только нами. Хотя и гарантий давать нельзя, но, всё же, если мы тщательно разложим всё по полочкам до деталей, шансов на успех у нас будет больше.
Возможно слова о том, что надо для начала подобрать наиболее подходящие техники-инструменты разработки, не несут в себе какой-то новой истины и глубины. Но, так или иначе, мне кажется, что некоторым людям действительно надо это лишний раз услышать, и эти самые слова важны.
Когда мы пришли к выводу о том, что agile это всего лишь один инструмент из многих, всё стало только интереснее. Как я узнаю, какой инструмент будет наиболее эффективным для решения данной задачи? Какой выбор инструментов у меня собственно есть? Какие базовые и основные характеристики различных задач? Человек и процесс — это удобная конструкция для иллюстрации идеи, но она только открывает игру.
Чтобы ответить на все эти вопросы мы должны спуститься в самый низ и рассмотреть все мелкие подробности и особенности, стоящей перед нами задачи. Каждая игра, каждая команда, каждая компания — уникальна, и существует много факторов способных повлиять на ход разработки — размер команды, корпоративная культура, внутренняя политика, лимит на бюджет, физические ограничения и так далее.
Есть, конечно, какие-то общие моменты среди всех эти уникальных проектов. Есть много книг, которые рассказывают о каких-то базовых принципах, поэтому я лучше выберу те пять моментов, которые мне кажутся важными и определяющими в гейм-девелопменте.
Люди.
Я уверен, что важнейшим фактором успеха в управлении проектом являются люди. Талантливые мотивированные опытные разработчики сделают поставку, несмотря на огрехи менеджмента. Они найдут способ обойти процессы, которые мешают и смогут создать правильную структуру там, где царит хаос.
"Окружите себя лучшими людьми, которых только сможете найти, распределите обязанности и полномочия, и не вмешивайтесь", Рональд Рейган
Эта идея лежит в основе agile девелопмента, и является фундаментальной для нелинейного менеджмента. Чтобы добиться успеха, вы должны приложить максимум усилий, чтобы нанять хороших разработчиков, тщательно отсеять зёрна от плевел. Весь остальной менеджмент в таком случае особой роли не играет, это так, глазурь на торт.
Разумеется, рассчитывать на то, что вы набираете всегда только лучших, наивно. Вот несколько факторов, которые надо учитывать:
Если вам потребуется существенно увеличить команду, то будьте уверены, что проблемы с наймом ещё одних лучших у вас возникнут.
Опыт — штука дорогая, ваш бюджет вряд ли потянет команду исключительно элитных разработчиков.
Определение зон ответственности. Понимание того, где мы можем нанять не сильно опытного человека, помогает перекинуть бюджет на другую зону или же просто сэкономить и тем самым увеличить коммерческую состоятельность вашего проекта. (Вы не будут набирать в Макдональдс исключительно кандидатов наук на все должности, хотя попробовать было бы интересно).
Слишком много ведущих разработчиков — путь к появлению проблем. Кто будет главным, и станут ли опытные разработчики играть вторые скрипки? Неясное распределение полномочий ведёт к разрушению концептуальной целостности проекта.
В то же самое время, тот факт, что вам приходится часто работать банально с тем, что есть, приводит к тому, что понимание способностей и склонностей человека, и то, как они реагируют на те или иные ситуации, становится ключевым качеством хорошего менеджера. Некоторым больше по душе свобода, а кому-то нравится больше работать в чёткой структурированном окружении, к примеру.
Большинство agile методик предполагает, что у вас под началом великолепная, опытная и сверхмотивированная команда. Многие такие методики могут и вполне хорошо работать с командой обычных, юных или апатичных разработчиков, а могут и с оглушительным треском провалиться.
Опыт в данном случае имеет большое значение. К примеру, я могу взять своего лучшего девелопера, поставить перед ним какую-то сложную техническую задачу, дать всё, что ему требуется, и сесть на стул, сложив руки в ожидании чуда. А вот если всё то же самое проделать перед только пришедшим из университета свежеиспечённым разработчиком чуда можно даже и не начинать ждать. Большинству начинающих нужно наставничество, постоянный контроль и чёткие структурированные задачи, пока он сам не встанет на ноги.
Из этого следует, что процессо-ориентированный подход больше подходит для джуниоров, а для опытных разработчиков лучше как раз человеко-ориентированный. соответственно мы видим, что компоновка команды по принципу уровня опытности определяет и подход, который должен лучше сработать.
Конечно, люди куда более сложны и идиосинкратичны, чтобы было достаточно выбора методики по опытности девелоперов. Но главное, что я хотел сказать, это просто то, что разные люди откликаются на разные подходы, и что опыт и скиллы команды обязательно надо принимать во внимание, прежде чем выбирать подход к разработке — плановый или agile.
Креативность vs. Продакшн
Есть два фундаментальных понятия, лежащие в основе гейм девелопмента — креативность и продакшн (прим. – перевод слова "продакшн", как "производство" или "производственный процесс", будет вносить сумятицу, поэтому оставлю такой, более понятный людям в теме вариант)
Давление продакшна на разработку это обычное условие ведения бизнеса — необходимость совершить поставку согласно бюджету ни в срок. Чтобы сделать это, нам необходимо просчитать масштаб работ и риски, а это значит заняться планированием и составлением графиков работ. Это несомненно сложная работа, требующая немало усилий и времени, но необходимая для того чтобы ответить на эти извечные два вопроса — когда это будет готово и сколько это будет стоить?
Чтобы план был точным и аккуратным, в идеале нам надо работать с известными величинами. Продакшн, таким образом, отправляет нас в сторону техник, работающих от процесса.
Креативность, с другой стороны, это сердце и душа гейм девелопмента, которая заставляет нас делать лучшие игры. Это увлекательный путь познания и искреннего любопытства. Здесь нет гарантированного выхода или удобных сроков, и это разочаровывающий путь, с точки зрения перспективы выпуска продукта. Наличие креативности у разработчиков часто приводит к попыткам менеджмента управлять всем этим хаосом, которые, впрочем, не могут сдержать творческий процесс, а менеджеры потом только удивляются уменьшению количества "я не знаю что это" ошибок.
Поэтому не удивительно, что некоторые наиболее инновационные и продвинутые игры, получившие высокую оценку от самых взыскательных критиков, выходят из студий, чей менеджмент можно, прости господи, назвать беспорядочным. Точно также "корпоративные" студии со зрелым и опытным менеджментом, выпускают банальные и стандартные продукты.
Но не стоит торопиться с выводами. Это всё не значит, что креативность это прерогатива хаоса, а своевременная поставка игры и попадание в бюджет означает отказ от инноваций. Нам необходим баланс между обеими крайностями, чтобы достичь желанной цели.
Понятие креативность окружено мистически ореолом, особенно в том, что касается компьютерных игр. Это на самом деле важная и большая тема, но она выходит за пределы этого эссе. Тем не менее, люди изучают так называемую креативность годами, и существуют наработанные эффективные практики и техники, пригодные к использованию.
Креативность — это навык, которому можно научиться, воспитать и развить в себе. Это куда меньше чем какой-то проблеск гениальности, это скорее умение создать вокруг себя условия, стимулирующие появление и развитие идей. Если вам это интересно, советую прочитать книгу Гордона Маккензи (Gordon Mackenzie) "Orbiting the Giant Hairball", которая рассказывает о его опыте креативной работы в корпоративной среде.
Повторяющаяся и при этом постоянно изменчивая натура креативного процесса ведёт к самопроизвольному принятию agile-ориентированного стиля менеджмента. Тем не менее, наивно применять scrum в надежде, что это магически сделает разработку более креативной. Гибкость менеджмента необходима, но не определяет итог разработки.
Сочетать в гармонии креативность и продакшн нелегко, тем более что далеко не все проекты в данном плане похожи. Как бы мне не хотелось работать всегда над инновационными и креативными задачами, такого никогда не будет. В реальной жизни бизнес показатели и характеристики, в том числе пресловутый продакшн, являются наиважнейшими для большинства компаний. Устойчивый и успешный бизнес должен быть всегда прибыльным. Если мы хотим всегда обеспечивать сотрудников студии работой и продолжать разрабатывать игры, мы должны быть прибыльным бизнесом.
Для примера, пропуск платежа за очередной майлстоун проекта может быть фатальным для стартапа, живущего "от получки до получки", так что своевременная поставка (синоним — выживание) в данном случае куда важнее всего остального для проекта. Или, к примеру, крупный издатель может захотеть получить не просто игру, а новый бренд, который воздастся им в будущем большей прибылью. И для проекта у них будет куда больше желания подождать и вложить больше денег в креатив разработчиков и в них самих.
Портфолио продуктов — ещё одна вещь, которую необходимо учитывать — большая студия может работать над одним проектом "для оплаты расходов" (то есть бизнес-ориентированный, в котором важнее всего своевременная поставка), а вторым заниматься для поддержания престижа студии (креативным и инновационным). Понимание контекста бизнес-реалий для данной игры, её возможностей и амбиций, определяет лучший путь для её разработки и развития.
Некоторые люди склонны считать, что коммерческий успех, так или иначе, последует за выпуском хорошей игры. Это конечно вполне возможно, а для идеального мира "где всем воздаётся по заслугам" будет истинно верным. Но, так или иначе, мы живём в несколько ином мире, который совсем не так прост. Это правда, что некоторые студии нашли себе нишу и открыли новые сегменты рынка за счёт своей креативности и продвинутости, и это привело их к коммерческому успеху и интересу инвесторов. Но, к сожалению, это работает не для всех, и проблему у многих начинают возникать, когда им оказывается необходимым оставаться креативными и инновационными на протяжении долгого срока, а не одного-двух проектов. Вообще, я желаю всем им удачи, однако только рынок станет всем судьёй.
Этапы продакшна
Ещё один момент, свойственный индустрии разработки игр (а также любому фактически конечному продукту), это разбивка проекта на три этапа — преподакшн, продакшн и постпродакшн. Точные определения данных вех в разработке могут меняться в зависимости от проекта, но в общем виде я их представлю так:
Препродакшн — это период, в который мы работаем над тем, какой должна быть игра, и как мы собираемся её делать
Продакшн — период, в который, мы собственно, делаем игру.
Постпродакшн — период, в который мы заканчиваем разработку и превращаем проект в нормальный, готовый к доставке пользователю продукт. Данный этап делится на две фазы — альфа (полировка игровых моментов, отработка баланса игровых качеств и процесса) и бета (чистка от багов).
Забавно, но даже самый ярый приверженец agile методик, которого я когда-либо встречал, всё равно ссылается на существование данных этапов разработки, несмотря на то, что они практически полностью повторяют стадии waterfall подхода — дизайн, реализация, тестирование. Так уж получилось, что данная разбивка на этапы является фундаментальной для индустрии.
Agile методики предпочитают итерации разработке согласно структурированному плану. Такой подход работает, когда условия и требования постоянно меняются и перестройка плана каждый раз отнимает слишком много усилий и времени. В гейм-девелопменте требования меняются постоянно, и в данном случае вполне логично, что итерационный подход является естественным.
Мы можем применить данный подход к проекту в целом, заменив тем самые стандартные пре, продакшн и постпродакшн этапы и получим что-то вроде этого:
Так или иначе, проблема заключается в росте количества изменений, которые необходимо производить на высоких стадиях развития проекта. Скажем, мы решили изменить длину прыжка героя, достаточно невинное изменение, влекущее, однако за собой серьёзную переделку дизайна уровней и потенциально ещё энного количества систем и контента. Чем больше уровней мы сделали, тем дороже нам обходятся изменения.
Выше представлен график традиционной стоимости изменений, который вы можете найти во многих книгах, посвящённых разработке софта. Чем раньше мы делаем изменения, тем дешевле они нам обходятся. Применяя итеративный подход к полному циклу разработки, мы потенциально наращиваем стоимость последующих изменений.
В идеале, нам бы хотелось ответить на все фундаментальные вопросы в самом начале разработки, чтоб потом не пришлось вносить дорогостоящие изменения. И препродакшн как раз нацелен именно на это.
Препродакшн — наиболее креативный период создания любой игры. Начальные этапы препродакшна на редкость свободны и органичны, в них есть элемент творчества и изобретательства. Более поздние стадии данного периода разработки сфокусированы на решение специфических вопросов и выбора технологий, чтобы последующая разработка была эффективной и правильно размеренной. В целом, если и есть когда период времени, когда вы эффективно работаете по agile и ведете процесс разработки по итерациям — это будет называться препродакшеном.
Продакшн — это период, когда мы создаём основной контент, и в который мы тратим больше всего денег. Нам необходимо удержать расходы под контролем, и чем лучше процесс организован и детерминирован, тем лучше. Мы всё ещё должны реагировать на фидбэк и вносить изменения, однако мы должны держать всё это под контролем.
В альфе мы возвращаемся обратно в итерационный цикл — уточняем, полируем, настраиваем. После альфы, каждый работает уже из базы багов, процесс, на мой взгляд, органичный и самоподдерживающийся.
Мы можем изменять подход к разработке на протяжении всего жизненного цикла проекта, мы не должны всегда придерживаться одних и тех же принципов.
Навыки
Другим отличным моментом игровой индустрии по сравнению с другими средами разработки являются необходимые навыки — в гейм-девелопменте сплетаются три фундаментальные стихии: кодинг, искусство и дизайн.
Различные виды задач и их реализация, сложная система взаимопроникновения и взаимодействия дисциплин — тема которую нельзя не оставить без внимания. Анализируя метрики с наших внутренних проектов, я выделил несколько общих трендов:
Искусство претендует на то чтобы называться детерминированной дисциплиной. Как только мы сгенерировали список необходимых элементов и объектов, а также соответствующий антураж, мы можем с большой долей вероятности предсказать, как много времени займёт реализация всего этого, и какого качества результат мы сможем получить. Кроме того данный тип работ легко распределять на несколько людей и можно без проблем для ускорения работ внедрят в команду новых специалистов.
Кодирование куда более эклектично и имеет массу непредсказуемых моментов, влияющих на процесс разработки. Для сравнения — данные исследований показывают, что программисты тратят существенную часть времени в работе (20-40 процентов) на незапланированные задачи. Это происходит потому, что им приходится реагировать на возникающие в процессе разработки запросы куда чаще, им приходится работать над багами или сражаться со скрытыми сложностями и огрехами дизайна функционала. Кроме того сложные системы куда хуже распределяются и масштабируются, и поэтому введение новых людей в коллектив не всегда приводит к улучшению результата и ускорению работ.
Из этого следует то, что одни и те же методы управления, успешно применённые к художникам и дизайнерам, далеко не всегда подойдет программистам и стоит дифференцировать ваш подход к менеджменту в зависимости от подчинённых и выполняемых ими задач. К примеру, вы можете вести кодеров по agile принципам, а к работникам визуального искусства применять более плановый подход, особенно во время продакшена.
Клиент
Ещё один интересный момент в agile разработке — это желательное вовлечение в процесс заказчика. В нашем случае для простоты возьмём в качестве заказчика представителей компании, выпускающей игры в печать. В гейм-девелопменте у нас всегда наблюдается участие заказчика в процессе разработки в виде внешнего продюсера игры, который играет роль телеграфа, передаёт слова заинтересованных сторон со стороны паблишера (маркетологов, юристов, QA и т.д.).
Это выглядит правильно и даже благородно вовлекать в сотрудничество заказчика в процессе разработки, однако далеко не все заказчики и их представители одинаковы. Есть множество сложных вопросов и принципиальных моментов в данном сотрудничестве — сколько доверия и свободы в решения они готовы вам предоставить? Какого уровня вмешательства в процесс разработки вам стоит ожидать? Какой вес представитель заказчика имеет в его бизнесе? Приведём совет, который может поспособствовать созданию на проекте тех условий, которые помогут и проекту выжить, и понять, как внешние силы могут вам помочь в планировании стратегии реализации проекта, а также стиля применяемого на проекте менеджмента.
Говоря утрированно, если у вас клиент-живчик, постоянно меняющий и добавляющий цели и задачи, то ваш лучший друг — agile. Если же вам попался клиент, который не сильно увлечён непосредственно качествами результата разработки, а требует, чтобы всё было сделано в срок и в бюджет, то тогда вам поможет только хорошее планирование и размеренная работа.
Спор насчёт agile и waterfall на самом деле прост. Моё мнение — agile не плох, просто он слишком часто используется в качестве оправдания для плохого менеджмента на проекте. Разработка софта — сложная штука, а разработка игр в особенности. Достаточно только бросить взгляд на поле разработки ПО, чтобы увидеть там ряды могилок загубленных проектов, чтобы подтвердить данное утверждение. С другой стороны, если бы разработка ПО была простой, она бы не была такой интересной.
Пока мы закрываем глаза на принципиальные фундаментальные вопросы, у различного рода шарлатанов есть непаханое поле для активной деятельности по продажам живой воды для проектов и философского камня для управления разработкой. Оглядывайтесь назад, чтобы пересматривать свои собственные убеждения, вырабатывайте свою собственную позицию. При этом чтобы успешно развивать свои навыки управления проектами, не бойтесь пробовать новые методики, экспериментируйте. Но самое главное, не забывайте, что от своей работы вы должны получать удовольствие. В конце концов, ведь именно поэтому мы занимаемся разработкой игр.
И помните, не бывает двух одинаковых проектов (если вы, конечно, не занимаетесь разработкой гоночных симуляторов :).
7 курсов для будущих и практикующих разработчиков игр на Unity (июнь 2023)
Вместе с Digitaldefynd составили список полезных курсов, сертификаций и тренингов, которые помогут освоить профессию разработчика игр на Unity с нуля, а также прокачать свои навыки тем, кто уже работает в гейм-индустрии.
8 актуальных и интересных курсов по Rust (июнь 2023) + бонус от GitHub
Рассмотрели преимущества и особенности языка Rust, а также сделали подборку курсов по нему, которые будут интересны как новичкам, так и опытным программистам.
Фанатичная уверенность в своей правоте и агрессивный рекламный напор Agile-евангелистов оставили после себя поля заваленных проектов, руины бизнес-начинаний и заблудших неофитов, всё ещё блеющих избитые истины забытых пророков. Индустрия разработки игр не исключение в данном случае и также ещё только начинает осознавать масштаб фантасмагории и её результаты.
Конечно, всегда были более осознанные разработчики, которые не поддались уговорам и влиянию никуда негодных "консультантов", даже если они предлагали громкие сертификаты и все прочее. Сейчас среди прогрессивных специалистов часто говорят о так называемых post-agile практиках, ранее известных как здравый смысл.
Но распространяется этот самый здравый смысл пока ещё медленно. Если мне придётся ещё раз просидеть на митинге с каким-нибудь очередным agile неудачником, упорно защищающим свой подход к разработке катящегося в бездну проекта, это всё приведёт к принудительному канбану (японская система синхронизации работы на заводах с раздачей карточек с требованиями), где никаким scrum'ом и не пахнет. И не то чтобы я имел что-то против agile, скорее совсем наоборот, но в конце дня мне надо сделать поставку, а не бороться с ветряными мельницами.
Простой вопрос, но для ответа для него нам нужно напомнить формальное значение термина "agile". К счастью разногласий здесь быть особо не должно, поскольку Agile Манифест приводит нам достаточно ясную формулировку. Вообще мне нравится манифест, поскольку он показывает ясное понимание что такое, процесс разработки ПО и предлагает хорошо продуманную систему ценностей. Он содержит важные идеи, которые никто не должен пропустить.
Рассмотрим первый принцип: Люди и их взаимодействие важнее, чем процессы и средства. Смелое заявление от авторов манифеста (не зря оно и первым идёт), ставящее личное взаимодействие выше процессо-ориентированных аспектов разработки.
Оно даёт нам более чёткий способ ранжирования методик по соответствию их agile принципам. Техники, сфокусированные на самих разработчиках более agile, чем процессо-ориентированные. Конечно, это только один пункт для сравнения и подобная классификация методик будет слишком грубой и сырой, но взять её на заметку стоит.
Уточним, что подразумевается под терминами "человеко-ориентированный" и "процессо-ориентированный".
Идея процесса имеет явно "политический" подтекст и поэтому люди так эмоционально реагируют, когда слышат о "методологиях" управления проектом. Ведёт данная идея к более фундаментальным и при этом более общим концепциям.
Процесс — это инструмент власти. Процесс — это утверждение о том, что как и в каком порядке надо делать. Процесс консервативен, иерархичен и формализован. Процесс устанавливает статус-кво в игре. С его помощью менеджмент наводит порядок сверху вниз. Если бы процесс был политической партией, он бы принадлежал к правому гегелевскому лагерю.
Альтернативой процессу является делегирование ответственности, доверие лицам на местах должным образом организовать себя, поскольку они лучше знают конкретные задачи, и поэтому так будет эффективнее, а сама разработка соответственно продуктивнее. Самоорганизация либеральна, "коммунальна", неформальна и даёт шанс каждому проявить свои способности. Она зарождается и идёт снизу вверх. Если продолжать политические метафоры, то самоорганизация — это партия хиппи в одежде из конопли и левацкими убеждениями.
Если говорить более конкретно и попытаться материализовать столь общие слова, будем считать процесс принадлежностью и чертой традиционного типа разработки ПО, а самоорганизацию своеобразной софтварной вольницей-партизанщиной.
М-да, не особо получилось материализовать, поэтому совсем неудивительно, что вокруг данного дискурса постоянно ведутся эмоциональные дискуссии. Подобная условность и неопределённость — плодородная почва для агитации и слепой веры в свою правоту. Не спрашивали себя, почему существует именно манифест agile? Это по сути как раз какое-то воззвание, можно сказать политическая позиция, а не какая-то объективная позиция.
Я не партизан, но и к другому лагерю также не принадлежу. Я просто заинтересован в получении конечного результата, и у меня нет времени защищать какую-то конкретную точку зрения. А для эффективного получения результата и вовремя необходимо быть гибким (хотя и не всегда, я бы добавил), так что главное понимать правильно, чего полезного можно получить от обоих подходов.
Вы, наверное, хотите спросить, почему я решил, что какой-то конкретный метод более или менее процессо-ориентирован, чем другой. Всё субъективно, и вы вполне можете не согласиться с моей позицией, и вполне возможно будете правы.
Проблема в том, что каждый конкретный метод содержит микс из различных (и вполне вероятно пересекающихся) практик. Кроме того уровень строгости и степень формализованности процесса могут меняться в зависимости от конкретного случая использования
Я хотел бы подчеркнуть, что когда мы переходим к деталям, определяя, что agile, а что не agile, нельзя прямо и чётко сказать, что это надо использовать, а это не надо. Agile является необходимым и важным контрапунктом традиционного мышления разработки программного обеспечения, но при этом является лишь малой частью общей картины.
Я видел очень успешные agile команды, но и много других, которые терпели неудачу за неудачей. Точно также есть команды, которые успешно работают по процессной методике, а есть постоянно неуспевающие к дедлайну. Очевидно, что успешность проекта далеко не определяется каким-то конкретным подходом к управлению разработкой, и проблема куда сложнее, чем мы могли подумать сначала.
Есть много вещей, которые вносят вклад в будущий успех проекта и не все они определяются только нами. Хотя и гарантий давать нельзя, но, всё же, если мы тщательно разложим всё по полочкам до деталей, шансов на успех у нас будет больше.
Возможно слова о том, что надо для начала подобрать наиболее подходящие техники-инструменты разработки, не несут в себе какой-то новой истины и глубины. Но, так или иначе, мне кажется, что некоторым людям действительно надо это лишний раз услышать, и эти самые слова важны.
Когда мы пришли к выводу о том, что agile это всего лишь один инструмент из многих, всё стало только интереснее. Как я узнаю, какой инструмент будет наиболее эффективным для решения данной задачи? Какой выбор инструментов у меня собственно есть? Какие базовые и основные характеристики различных задач? Человек и процесс — это удобная конструкция для иллюстрации идеи, но она только открывает игру.
Чтобы ответить на все эти вопросы мы должны спуститься в самый низ и рассмотреть все мелкие подробности и особенности, стоящей перед нами задачи. Каждая игра, каждая команда, каждая компания — уникальна, и существует много факторов способных повлиять на ход разработки — размер команды, корпоративная культура, внутренняя политика, лимит на бюджет, физические ограничения и так далее.
Есть, конечно, какие-то общие моменты среди всех эти уникальных проектов. Есть много книг, которые рассказывают о каких-то базовых принципах, поэтому я лучше выберу те пять моментов, которые мне кажутся важными и определяющими в гейм-девелопменте.
Так или иначе, проблема заключается в росте количества изменений, которые необходимо производить на высоких стадиях развития проекта. Скажем, мы решили изменить длину прыжка героя, достаточно невинное изменение, влекущее, однако за собой серьёзную переделку дизайна уровней и потенциально ещё энного количества систем и контента. Чем больше уровней мы сделали, тем дороже нам обходятся изменения.
Выше представлен график традиционной стоимости изменений, который вы можете найти во многих книгах, посвящённых разработке софта. Чем раньше мы делаем изменения, тем дешевле они нам обходятся. Применяя итеративный подход к полному циклу разработки, мы потенциально наращиваем стоимость последующих изменений.
В идеале, нам бы хотелось ответить на все фундаментальные вопросы в самом начале разработки, чтоб потом не пришлось вносить дорогостоящие изменения. И препродакшн как раз нацелен именно на это.
Препродакшн — наиболее креативный период создания любой игры. Начальные этапы препродакшна на редкость свободны и органичны, в них есть элемент творчества и изобретательства. Более поздние стадии данного периода разработки сфокусированы на решение специфических вопросов и выбора технологий, чтобы последующая разработка была эффективной и правильно размеренной. В целом, если и есть когда период времени, когда вы эффективно работаете по agile и ведете процесс разработки по итерациям — это будет называться препродакшеном.
Продакшн — это период, когда мы создаём основной контент, и в который мы тратим больше всего денег. Нам необходимо удержать расходы под контролем, и чем лучше процесс организован и детерминирован, тем лучше. Мы всё ещё должны реагировать на фидбэк и вносить изменения, однако мы должны держать всё это под контролем.
В альфе мы возвращаемся обратно в итерационный цикл — уточняем, полируем, настраиваем. После альфы, каждый работает уже из базы багов, процесс, на мой взгляд, органичный и самоподдерживающийся.
Мы можем изменять подход к разработке на протяжении всего жизненного цикла проекта, мы не должны всегда придерживаться одних и тех же принципов.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.