Планирование Странника

Содержание

1 Планирование Странника/Описание
2 Планирование Странника/Задачи
3 Планирование Странника/Деятельности
4 Планирование Странника/Проблемы
5 Планирование Странника/Родственные кейсы
6 Планирование Странника/Дополнительная информация
7 Планирование Странника/Оценка

Планирование Странника/Описание

(Краткое описание кейса)

В качестве проекта была выбрана разработка игры-аркады. В начале работы были собраны идеи и сформировано видение (Vision) проекта, включавшее в себя жанр игры, идеи внешнего вида персонажей, интерфейс управления.

Затем следовала стадия распределения ролей. В проекте были следующие роли:

главный программист,
программисты,
дизайнеры,
технические писатели.

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

После завершения проекта его участники провели процедуру, в RUP называемую Postmortem (вскрытие проекта). На нем обсуждаются:

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

Вскрытия помогают разработчику прицельно работать над своими недостатками и показывают его сильные стороны — что может быть важнее?

Планирование Странника/Задачи

Какие задачи решались в рамках кейса?

Планирование Странника/Задачи

Планирование Странника/Деятельности

Что делали участники?

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

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

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

Имело место не только обучение основам программирования, но и эффективное обучение процессу разработки.

Формальные процессы разработки ПО, такие как RUP или OpenUP включают в себя множество документов и подразумевает использование достаточно сложных инструментальных средств. При этом, эти процессов достаточно гибки, что позволяет приспосабливать их под имеющиеся условия и использовать только те средства, которые являются наиболее существенными и необходимыми для решение конкретной задачи.

Подходы унифицированного процесса для разработки проекта игры, а именно:

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

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