Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Кирилл Лебедев

Страницы: 1 2 »
1
История первая

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



Игровая компания немца разрабатывала 3 вида игр:

Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

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

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

Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.

На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.

На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.

Далее - https://habrahabr.ru/company/larian/blog/329032/

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

«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».

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

В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.

https://habrahabr.ru/post/315514/

4
Не понял, что Вы хотели сказать. Что разработку игры можно сопровождать разным набором документов (например, перечисленных), в зависимости от личных/отраслевых привязанностей и предпочтений? Даже не сомневаюсь. :)
Личные привязанности я бы здесь исключил. Более правильно, на мой взгляд, использовать словосочетание "отраслевые стандарты". Но дело не только в названии, но и в содержании документов, в их авторах (а они - разные) и тем, кому эти документы адресованы.

5
Алгоритмы в ТЗ могут быть достаточно сложные (или наоборот), а до игрока в геймплее или мануалах может доводиться их аппроксимация в тех форме и объеме, которые задуманы игровым дизайнером для того, чтобы игрокам было интересно.

При разработке игры ТЗ (в том понимании, в котором оно есть в ГОСТ) не пишется. А пишутся: CDD (Concept Design Document) -> GDD (Game Design Document) -> TDD (Technical Design Document). Алгоритмы никогда не пишутся в CDD и GDD - вместо этого геймдизайнер может описать конкретные ситуации, на примере которых видно, как должна себя вести игра в целом или конкретный ИИ. Т.е. описываются характерные ситуации. Алгоритмы могут быть описаны в TDD, но и то - вряд ли детально. По большей части, TDD служит в качестве перечня технических задач с указанием их оценки.

6
Таки да!
Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.

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

7
По поводу - я бы порекомендовал автору ознакомиться с ГОСТ34.602.89, не использовать целиком, а именно ознакомиться. Очень хорошо прочищает, позволяет понять сколько может быть неучтенного если подходить к этому вопросу "нахрапом".

ГОСТ как шаблон для требований гораздо лучше, чем отсутствие всякого шаблона, но при разработке игры он мало поможет. Потому что создание всякой игры начинается с идеи (а лучше - системы идей), которые затем формализовано излагаются в виде концепт-документа. А вот ГОСТа для изложения концепции игры не существует.

8
Я так понимаю что есть такой человек, по идеи, который занимается суто техническими документами.
Такой человек называется игровым дизайнером или продюсером. Пишет он не технические документы, а концепцию игры и дизайн-документ.

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

Но это пишется без сроков выполнения, без делайнов или "поддедлайной".
На подготовку и написание документов тоже есть сроки.

9
Почему используете два разных продукта?
DevTrack удобен в качестве баг-трекера, а также - feature tracker'а. С ним работают не только инженеры и менеджеры, но и продюсеры, и QA-инженеры, в том числе, из внешних команд. Hansoft удобен для планирования отслеживания технических задач, для распределения заданий между инженерами, оценки нагрузки, планирования спринтов и т.п.

Взаимодействуют ли они друг с другом?
Исключительно в ручном режиме. На этапе production в DevTrack вносятся фичи, которые формулируют продюсеры. В Hansoft же вносятся технические задачи, соответствующие этим фичам. Они формулируются ведущими инженерами на этапе технического планирования, а в ряде случаев - на этапе планирования спринта.

При работе инженер должен ориентироваться как на Hansoft, так и на DevTrack. Необходимо удостовериться, что в Hansoft занесены задачи, соответствующие закреплённым за данным инженером фичам. Там же надо регулярно отмечать время, изменять прогресс статус задач и т.п. Фичи нужно тоже обновлять, потому что после того, как они реализованы, они поступают для проверки продюсерам и QA-инженерам.

Насколько я знаю, было несколько попыток отказаться от одной из систем, по крайней мере, на время production'а. В одном из проектов это вроде даже удалось. Но, в целом, у каждой системы имеются свои преимущества, которые предопределяют использование их обеих.

Почему для планирования не используете что-то типа MS Project (SpiderProject, Primavera)?
По идее эти инструменты должны быть удобнее.
Подозреваю, что MS Project не используется из-за другой методологии планирования и ведения проектов. Например, у нас не используются диаграммы Ганта. Зависимости между задачами разрешаются в ручном режиме при помощи проактивной коммуникации между менеджерами, инженерами. При планировании считается, что все отобранные на майлстоун задачи можно распараллелить между исполнителями. Это, конечно, не означает, что из-за объективных трудностей (или зависимостей) какая-нибудь фича не может быть запланирована на более поздний майлстоун. К рекомендациям инженеров прислушиваются. Но чаще - ищут решения того, как можно избавиться от блокирующих зависимостей.

10
Какими инструментами вы пользуетесь для выполнения всех этих работ?

Для написания документации - Word и/или Confluence. Для рисования диаграмм - MS Visio. Для управления задачами - Hansoft, DevTrack. Для планирования - Excel с кучей готовых и проприетарных шаблонов.

11
Более детально написал в статье - http://megamozg.ru/post/11550/

12
Можно поподробнее про фасетную классификацию?
Как лучше классифицировать задачи?

На мой взгляд, нет наилучшей классификации вообще. Бывает наилучшая классификация для решения какой-то конкретной задачи. Какую задачу Вы хотите решить?

Приведу пример. Упомянутая мною классификация Feature -> Sub-Feature -> Sub-Feature Element упрощает оперирование фичами проекта и помогает составлять план версии и планы на майлстоун. Если различных sub-feature элементов может быть сотни или тысячи, то количество фич - несколько десятков или сотен. Благодаря иерархии сокращается количество элементов, которые нужно держать в поле зрения.

Аналогичным образом, при разработке приложения с большим количеством экранов уменьшить количество задач, которое нужно держать в "оперативной памяти", может помочь такая классификация: Mode -> Screen Flow -> Screen -> Screen Element.

13
Но ведь у вас же не тысяча исполнителей, вы же не можете сразу все задачи кому-то назначить.

Около сотни - программистов, художников, продюсеров, менеджеров и QA-инженеров.

И вот здесь начинается самое интересное, именно этого и касается мой вопрос.
Значит нужно из всех задач (как вы пишете - из десятков тысяч) выбрать именно те, которые наиболее актуальны на данный момент.
Как вы делаете этот отбор? По каким признакам вы отбираете первоочередные задачи? Вот это меня интересует.

Работа над задачами ведётся в рамках версии. Каждая версия приложения - отдельный продукт. У продукта есть концепция. Продукт предназначен для определённых рынков и сегментов. Поэтому из ключевых фич (100 - 200 штук) делается выбор в соответствии с пониманием того, на какой рынок будет выпущен продукт, и для каких сегментов он будет предназначен.

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

Feature - Sub-Feature - Sub-Feature Element.

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

По результатам оценки уточняется таймлайн проекта, даты майлстоунов. Делается распределение фич и подфич по спринтам. Уточняется количество ресурсов, которые необходимо привлечь на проект для выпуска продукта в срок.

Как вы распределяете нагрузку?
Есть какой-то подход? Или просто хаотично?

Выполняется нагрузочное планирование (capacity planning). Создаётся детальный план, который учитывает объём работы, имеющиеся ресурсы и длительность проекта. Имеющиеся технические задачи распределяются между сотрудниками. План обновляется для каждого майлстоуна, т.к. входе работы над проектом ситуация может меняться. Учитывается overhang для всей команды. Если сильно не успеваем, то некоторые фичи могут быть отменены.

14
Milstud,

Мы используем одновременно 2 системы управления задачами + Excel:

1. Hansoft - для управления девелоперскими задачами, для распределения нагрузки, планирования спринтов, контроля сроков.
2. DevTrack - для управления дефектами и фичами. Разница с Hansoft - выполнение задачи из DevTrack'а проверяется продюсерами и QA. В Hansoft заносятся технические задачи. Они особо никем не верифицируются, кроме самого девелопера.
3. Excel - для построения отчетов, графиков. А также - для управления рисками, продюсерскими задачами и прочим.

15
Сергей, о каком количестве задач идёт речь? Десятки? Сотни? Тысячи? Десятки тысяч?

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

1. Разбиваем задачи на несколько видов. Например:

- Feature (несколько десятков)
- Sub-Feature (несколько сотен)
- Sub-Feature Element (несколько тысяч)
- Milestone Deliverable - это Feature, Sub-Feature или Sub-Feature Element, который нужно реализовать к определённому майлстоуну (несколько тысяч)
- Development Task (как правило, техническая задача, которую нужно сделать и проверить её реализацию при помощи QA, несколько десятков или сотен)
- Problem Report - баг (несколько десятков тысяч)
- Localization Issue (баг, связанный с локализацией, несколько сотен)
- Техническая задача (проверяется другим инженером во время code review, QA проверяет в рамках feature, от нескольких сотен до нескольких тысяч)

2. Задачи вносятся в систему контроля задач в соответствии с их видом. Каждый вид имеет свой workflow.

3. Приложение "дробится" на области по разным основаниям. Мы используем одновременно две классификации: пользовательскую и техническую. Пользовательская классификация позволяет "раздробить" приложение на части с точки зрения пользователя. Техническая "дробит" приложение на технические части.

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

1) Карта.
2) Построение маршрута.
3) Навигация по маршруту.
4) Поиск адреса.
5) Поиск мест.

Та же самая навигационная система может быть разделена с технической точки зрения на такие части:

1) База данных.
2) Аудио.
3) Рисование карты.
4) Алгоритмы.
5) UI.

4. Каждая задача содержит маркеры - к какой области она относится. Одновременно используются 2 классификации - пользовательская и техническая.

5. Также в качестве маркера можно использовать и feature, к которой относится задача.

Страницы: 1 2 »