арт-дизайнеры и разработчики - два параллельных мира или все таки один?

[Alexey Krivitsky]

Привет геймерам!

Вернулись с Наташей с тренинга в гейм-конторе. Особый мир.

Уже не первый раз встречаем такого рода компании, и каждый раз похожая картина: арт-дизайнеры и разработчики работают асинхронно, в разрыве. 

Аргументация звучит обычно довольно логично: арт-дизайн занимает в 2-3 раза больше ресурсов, чем нарезка и программирование объектов, поэтому чтобы не простаивали разработчики им дают дизайны игр при 100%-готовности.

Теоретически, эта та же проблема что есть у разработки и тестирования. Можно тестировать после разработки, а можно параллельно, по ходу.

Кто сумел построить кросс-функциональные команды из артов и девелоперов? Отзовитесь. Интересен опыт и его путь.

Спасибо.

Alexey Krivitsky

Certified Scrum Trainer

SCRUMguides: Agile coach, Scrum Trainer & Executive

Agile Eastern Europe : Executive and Main Producer
AgileUkraine: Founder and Coordinator
LinkedIn | Twitter | CV | Blog | Skype: alexeykrv | +38.050.358.9212

Author of lego4scrum and outsourcing30.com

[Alexander Burdun]

Не сумел. В итоге у арта свой скрам с нардами и сотрудницами. С в целом аналогичным беклогом, но опережающим на пару недель девелоперский.

8 сентября 2012 г., 0:52 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Александр Бурдун

tel: +38 097 137 0443
skype:    a.burdun
AIM/ICQ: 307064073
http://burdun.com

[Alexey Krivitsky]

Ага. Есть какой-то канбан на стыке отделов, чтобы дизайнеры не рисовали "в стол" то, что нескоро (никогда) не будет сделано?

2012/9/8 Alexander Burdun <a.bu...@gmail.com>

[Alexander Burdun]

На текущем месте работы пока наш скрам в зачаточном состоянии, так что ничего конкретного не скажу.
Перед этим да, было что-то такое.
Просто есть пачка методов типа реиспользование арта и в таком духе. Примерно как с сайтами. Дизайнер рисует мокап и парочку полных интерфейсов, а потом 70-90% оставшегося интерфейса можно уже просто собрать из того что есть порезав правильно.
Что-то уникальное типа персонажей, игровых локаций, инентаря и прочих итемов игровых уже нуждается в каком-то контроле. Но, если честно, особых проблем не возникало с этим. Чаще наоборот. Пора уже реализовывать, а дизайн еще не готов.

8 сентября 2012 г., 10:43 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:

[Alexander Burdun]

Вообще тема эта поднялась очень в тему. Мне бы хотелось узнать как коллеги поступают.
Есть идея ввести не скрам а канбан. Дабы одна стори проходила этапы:
- идея
- описание
- арт
- сервер
- клиент
- тест
- баланс
- продакшен

Тогда бы и арт в общий процесс норм вписался. Но стремно как-то. Что скажете?

8 сентября 2012 г., 10:54 пользователь Alexander Burdun <a.bu...@gmail.com> написал:

[Nataliya Trenina]

Так а чего стремно-то?

Что такое баланс?

Ната

8 сентября 2012 г., 11:44 пользователь Alexander Burdun <a.bu...@gmail.com> написал:

--

Nataliya Trenina

Co-Owner & Agile coach @ SCRUMguides
Conference Producer      @ Agile Eastern Europe
Founder & Facilitator       @ InnovationFriends

Social profiles:    nattrenina
For urgent matters: +38 050 412 61 35

[Alexander Burdun]

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

Баланс - цифирьки всякие: че, как, когда, сколько. Математика игры.
Предварительный составляется на этапе составления описания фичи, но потом еще в несколько(иногда достаточно много) итераций корректируется.

8 сентября 2012 г., 12:20 пользователь Nataliya Trenina <nat.t...@gmail.com> написал:

[Alexander Burdun]

Ну и еще стремно что сейчас есть разнос по "отделам" арт, код, геймдизайнеры. Каждый занимается своим. Координация нужна только на стыке. И внутри отделов есть вариации на тему структуры работы.
А так придется причесать всех под одну гребенку. Думаю это будет на начальном этапе оч проблематично. Возможно когда команда (хотя бы код) научатся работать по скраму, и остальные посмотрят что это. Тогда уже можно будет двигаться куда-то дальше. С плеча рубить не охота.

К примеру в том же отделе АРТ-а тесно сотрудничают с фрилансерами. Там часто планировать не получается чтоб получалось всегда вовремя и в срок. И у них свой "канбан". Скетч, поиск образов, утверждение скетча, финальный дизайн, доводка.

Потому их не хочется в общую схему пихать.

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

8 сентября 2012 г., 12:25 пользователь Alexander Burdun <a.bu...@gmail.com> написал:

[Timofey Yevgrashyn]

Я сталкивался и с гейм конторами и просто с конторами у которых требования приходится долго описывать специальным бизнес-аналитикам.

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

Умные делают Lean-изацию процесса и выравнивают поток. Очень похожий подход описывали Хенрик Книберг и Матиас Скарин в своей Kanban and Scrum - making the most of both. У них там во второй части рассказ о реальном проекте (кстати, тоже гейм студии, имхо) - там тестировщики  (UAT) были отдельным отделом, который был в своем потоке и ловил работу от трех скрам команд.

По-моему, на больших проектах, которые выходят за рамки двух команд, нужно переходить к оптимизации на более высоком уровне. Нужно помнить об оптимизации всей системы, расставлять правильные размеры WIP и буферы для синхронизации, а внутри команд давать им организовать процесс как удобно.

Для начала, можно визуализировать на доске все все все этапы разработки и начать подбирать размер WIP лимита, чтобы устранить простои. Для вдохновения хорошо подойдут "10 канбан досок и их контекст".

Timofey Yevgrashyn,

Author at "The Improved Methods"

http://tim.com.ua
http://www.facebook.com/tim.com.ua 

Skype: spidertim
Phone: +380 67 408 53 30

2012/9/8 Alexey Krivitsky <alexeyk...@gmail.com>

[Alexey Krivitsky]

+1 к теории Тима

но интересен реальный опыт живых людей, лучше из украины :)

2012/9/8 Timofey Yevgrashyn <yevgr...@gmail.com>

[Bogdan]

5 лет менеджмента Гейм. Контор опыта, больше 10 проектов.

Самая удобная практика:

Гейм дизайнер == продает овнер, хоть это и нарушает саму логику овнерства; 

Скрам команды из прогов, геймдиза и Лид Арта / ui Арта. 

У художников / моделеров - вотерфол, т.к. Требования редко меняются.

Арт по итерируемым фичам делается в минимальном кол-ве, максимум плейсхолдеров.

Артисты могут отставать от дизайна и функциональности на спринт-два, это спасает от массового рефрактора контента. 

Стадии: 

Альфа == 100 % код комплит по формирующим гемплей фичам.

Бета == генерация маштабируемого контента (звуки, графика).

Релиз == интеграция всего контента, роадмап поддержки.

Методологии: agile для связки проги + дизайнер + эксперт от артов

Waterfall для художников.

Tools: perforce, svn, jira, git

Отдельные репозитории для Арта и кода.

Длинна итераций: неделя, лучше четверг для сдачи спринта.

Дизайн пишется в виде презентации игры + юзер стоит с конкретными фичами. По окончании фичи пишется итерация сразу же, описывающая методы и цели импрува данной фичи.

Скоуп (примерно):

Механика -> фичи для реализации -> задачи

Важно: не бояться сделать 10% от фичи, это всеравно показатель.  

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

Mobile

10 вер. 2012, в 23:55, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

[Alexey Krivitsky]

Спасибо, Богдан.

А какова роль game-продюссера? Чем он не Product Owner?

Еще ты написал

Артисты могут отставать от дизайна и функциональности на спринт-два, это спасает от массового рефрактора контента. 

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

Спасибо.

Леша

2012/9/11 Bogdan <bogd...@gmail.com>

[Bogdan]

Нет, не описка. На бета стадии (все фичи готовы) арты могут обгонять, но это не обязательно. Арт легко спрогнозировать, фичи - нет. Стоит использовать плейсхолдеры для функциональных фичей.

Продюсер - продакт овнер, но он должен пошарить дизам вижен и делегировать овнерство дизам. Дизы ему и сдают фичи / проект, но у него, как правило. Если тупо - прод это главный продакт овнер, но на коротких участках его ф-ции берут на себя дизы. Звучит странно?

Mobile

15 вер. 2012, в 20:32, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

[Alexey Krivitsky]

Звучит так, как будто это у вас работает )

2012/9/15 Bogdan <bogd...@gmail.com>

[Mihailoff]

Хорошая статья на тему отказа от фотошопа. Пример того как люди и их взаимодействие важнее конкретного инструмента.