Методологии управления проектами

Многие из вас, конечно же, мечтают сделать собственную игру. Некоторые из многих даже обзавелись небольшой командой энтузиастов, которая готова заниматься разработкой вашей идеи. Но те из некоторых, кто реально хоть немного прикоснулся к процессу работы над игрой с нуля, уже, возможно, столкнулись с многочисленными сложностями, которые подстерегают геймдизайнера на каждом шагу. Дело в том, что геймдизайнер в небольшой команде во время разработки становится также и человеком, который управляет проектом и организовывает труд других людей. Но как это сделать, если зачастую даже свой собственный труд организовать довольно сложно? Часто можно столкнуться с тем, что схватиться хочется за все задачи сразу, или работа над задачами проекта откладывается на мифическое «завтра», или же кто-то в команде простаивает без дела, а кто-то наоборот, по уши завален работой, которую и за месяц не закончить. Одним словом, не хватает какой-то системы.

Работа коллектива над каким-то общим делом невозможна без следующих вещей:

1) четкого планирования;
2) последовательности и итеративности процесса;
3) распределения задач согласно возможностям каждого члена команды;
4) согласованности и слаженности работы над задачами и самой команды;
5) анализа качества проделанной работы и выявления недочетов с их последующим устранением.

Звучит все это очень сложно. Но хорошая новость в том, что здесь не нужно изобретать велосипеды — все уже давно придумали за вас.

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

1, Классический «водопадный» менеджмент

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

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

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

Итог:

Плюсы: последовательность.
Минусы: отсутствие гибкости.

2. Kanban

Это слово японское, потому что придумали этот метод работы японцы на заводе Toyota. Метод заключается в трех основных принципах:

1) Визуализация рабочего процесса

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

2) Ограничение количества задач в рамках одной итерации

Одновременно в работу в рамках каждой итерации разрешается брать только определенное количество задач, заранее установленное руководителем проекта. Самое удивительное, что не существует сроков для выполнения одной задачи, никто не рассчитывает и не прогнозирует время на задачу, руководитель просто ставит задачи в порядке приоритетности, а сотрудники стараются сделать как можно больше. В качестве регулирования здесь выступает принцип команды: если в столбце для тестировщиков максимум может быть 5 карточек, то программисту уже не перенести туда шестую — столбец забит. Значит, есть какая-то проблема с тестировщиками, и чтобы помочь, программист может взять на себя задачу из тестирования.

3) Оптимизация

Рабочий процесс по системе Kanban постоянно оптимизируется. Как в случае с примером из предыдущего пункта, скопление задач в итерации тестирования может быть сигналом о том, что отдел недостаточно укомплектован, или работу сотрудников нужно каким-то образом пересмотреть и улучшить.

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

Итог:

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

3. Lean Six Sigma

Lean 6 sigma — это довольно сложная система, которую не описать в двух словах — за более подробными характеристиками лучше обратиться к другим источникам, я попробую лишь описать самые ключевые ее характеристики, которые могут найти применение в геймдеве. Итак, это система, объединенная из двух: системы Lean, известной как «бережливое производство», ориентированной на сокращение финансовых и временных потерь в рамках рабочего процесса, и системы Six Sigma, или «шесть сигм», предназначенной создать такой рабочий процесс, который постоянно улучшает и оптимизирует себя таким образом, чтобы не решать проблемы в рабочем процессе, а устранять их превентивно.

Так как сама система состоит из двух частей, в ней можно выделить два основных аспекта.

Аспект первый — бережливость принципа Lean

Определение того, что действительно важно для вашего проекта. Для того, чтобы понять, что является ценностью, определите несколько параметров, один из которых, или все одновременно должны быть в любом аспекте вашей игры. Например, во free-to-play проектах это монетизация (фича приносит прибыль), виральность (фича требует совместной с другими игроками игры) и ретеншен (фича заставляет игрока снова вернуться в игру). В текстовом квесте это может быть оценка с позиции сюжета. Например: а) фича раскрывает персонажа, б) фича раскрывает игровой мир, в) фича создает якорь для будущих игровых событий. Таким образом, все что кажется «просто прикольным», или «а давайте добавим вот как у них» идет мимо кассы. Все добавляемые фичи должны проходить проверку на наличие ценности для самого проекта.

Второй аспект — совершенствование принципа Six Sigma.

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

1) Определение основных проблем проекта. Здесь может быть сформирована команда, которая будет заниматься выявлением подобных проблем.

2) Сбор данных. На этом этапе собираются все данные по проекту, формируются тезисы и предположения о проблемах, существующих на проекте.

3) Поиск решения. Все собранные данные и предположения анализируются, проверяются на правильность и прочность, из них уже формируются четкие выводы.

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

5) Контроль процессов. Стандартизация рабочего процесса. Документирование и фиксирование выявленных в итоге предыдущих четырех этапов принципов, чтобы они в итоге превратились в правило, руководство к действию.

Что можно сказать про Lean Six Sigma в сфере геймдева? Этот метод является слишком сложным для маленьких команд, в нем многовато бюрократии и формальностей, а его безусловная «стандартизация» делает его менее гибким в условиях постоянно меняющихся требований к проекту.

Итог:

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

А теперь я хочу рассказать вам о методе, который включает в себя все плюсы перечисленных выше методов и исключает их минусы. Это не инновационное решение, а тоже известная система, которая называется — та-дам — Scrum. Далее я попытаюсь рассказать о том, чем же эта система хороша и наглядно показать, как по ней работать.

Scrum

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

Для того, чтобы вам проще воспринималось то, что я буду писать далее, предлагаю вам перейти по ссылке в Trello, где я постаралась сделать максимально реалистичную доску для гипотетического проекта. Все карточки можно пооткрывать и посмотреть, там есть примеры наполнения. Я даже попыталась сделать реалистичную историю перемещения карточек по спискам. Что такое Trello? Это очень удобный и бесплатный сервис для ведения системы задач по методологиям семейства Agile. Такие доски со списками задач люди заводят даже иногда для себя лично, и создают себе карточки в духе «прочитать новую книгу», или «отложить деньги на отпуск». Визуализация подобного рода всегда удобна.

Алгоритм работы по системе Scrum

1, Составление списка задач по проекту (Project backlog)

Это вообще все задачи, которые нужно сделать, чтобы завершить проект. Этот список постоянно пополняется, модерируется, сортируется, актуализируется. Не обязательно пытаться вписать сюда за один день все задачи, от старта продакшена до релиза — это невозможно. Достаточно перечислить задачи обозримого будущего, которые, вы точно знаете, придется делать. Для того, чтобы такие задачи выявить, нужно сесть и расписать большие этапы работы над проектом, разбив его на несколько частей. Например, «часть 1 — прототипирование боевки», «часть 2 — разработка апгрейдов юнитов» и так далее.

2. Ведение списка задач для спринта (Sprint backlog)

Спринт, или Sprint — это и есть та самая итерация работы над проектом. Как правило это отрезок времени длиной в неделю, или две — длина спринта определяется каждой конкретной командой отдельно. Список задач для спринта — это самые приоритетные задачи, которые нужно сделать в ближайшее время. Приоритетность задач определяется отсортированностью списка Project backlog, то есть срочные задачи — наверху, минорные задачи — внизу списка. Так же стоит отсортировать задачи и в самом спринте.

3. Отбор задач в спринт.

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

4. Планирование.

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

Если вы вдруг решите погуглить дополнительную информацию про Scrum, то вы наткнетесь на то, что планирование задач в рамках этой методологии ведется не в часах, а в так называемых story points, которые являются некой абстрактной величиной, обозначающей не время, а сложность работы над задачей. При таком расчете 1 story point - это затраты, которые требуются на выполнение минимально сложной задачи на вашем проекте. Данный способ хорош тем, что он учитывает все риски, возникающие во время работы (перекуры, перерывы на кофе, отвлечения на другие задачи, вопросы коллег), а как показывает практика, сотрудникам при оценке задач учесть эти риски самостоятельно довольно трудно. Если у вас маленькая команда, или вы только начинаете разработку своего первого проекта, то я бы посоветовала вам не заморачиваться со story points и мерить все в человекочасах, делая скидку на издержки производства, а на story points переходить уже после того, как вы как следует освоитесь со Scrum методологией.

5. Работа над задачами спринта.

В процессе работы задачи перемещаются по спискам, проходя различные этапы.

1) Список «Спринт»
Здесь лежат все задачи на текущий спринт.

2) Список «В работе»
Сюда переходят задачи, над которыми в данный момент работают специалисты.

3) Список «Тестирование»
В этом списке находятся задачи, отправленные на тестирование. Задача не считается законченной до тех пор, пока тестировщик не подтвердит, что она действительно работает так, как это было задумано. Существует много примеров того, как нормально функционирующая в локальном билде программиста задача перестает работать на устройстве тестировщика, а также примеров того, как тестировщик умудряется найти новые способы «сломать» фичу, которую так старательно делал программист.

4) Список «Баг репорт»
Сюда попадают задачи, в процессе тестирования которых были выявлены неточности, или баги. Любая задача, фактическая реализация которой не соответствует тому, как данная задача была описана, после тестирования попадает в список «Баг репорт», и работа над ней не заканчивается до тех пор, пока она все-таки не попадет в список «Готовых» задач.

5) Список «Готово»
Здесь находятся задачи, которые являются полностью выполненными. Нетрудно догадаться, что главной целью каждого спринта является перемещение всех задач из списка «Спринт» в список «Готово».

6) Список «Заблокировано»
В этот список попадают задачи, за которые взялся специалист, но в процессе работы над ними он понял, что их невозможно выполнить без дополнительной смежной или параллельной работы другого специалиста. Пример: новый арт невозможно добавить в игру, потому что он еще не отрисован художником, а у художника на этот спринт другие задачи. Или программист UI сверстал интерфейс, а полностью внедрить его в игру для тестирования невозможно, так как отсутствует необходимый для этого функционал фичи. Такие накладки случаются, хотя их нужно стараться избегать. Появление задач в списке «Заблокировано» — это первый звоночек для вас о том, что вы что-то сделали не так при планировании.

6. Стендапы (Stand-up Meetings)

Стендап — это один из важнейших нюансов работы по системе Scrum. Он представляет собой ежедневное утреннее совещание всей команды разработчиков, которое проводится в режиме стоя (отсюда и название). Стоять нужно затем, чтобы никто не растекался мыслью по древу и не возникало долгих обсуждений. На стендапе каждый член команды кратко рассказывает чем он занимался вчера и что будет делать сегодня, упоминает трудности, с которыми столкнулся, обращается к коллеге, помощь которого по задаче ему потребуется сегодня. Выступление одного участника команды обычно не превышает 1-2 минут, но даже при такой емкой подаче информации стендапы несут в себе массу пользы.

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

2) Возможность быстро решить вопросы на месте
Иногда коммуникация между отделами и даже между отдельными сотрудниками налажена не так хорошо, как хотелось бы. Стендап — это идеальное место для быстрых обсуждений и согласований.

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

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

6. Ретроспектива

Один из самых важных этапов работы в методологии Scrum — процесс анализа прошедшего спринта. На каждый спринт у вас есть равное количество человекочасов, или оптимальное количество story points (в зависимости от того, в каком формате вы ведете измерения). Равное оно потому, что все спринты одной длины и в них участвует равное количество человек. Это самое оптимальное количество вычисляется путем поиска среднего арифметического после двух-трех спринтов. В конце спринта строится так называемая диаграмма сгорания задач (Burndown chart).

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

Роли в Scrum

Так кто и как несет ответственность за выполнение тех, или иных этапов работы? В системе Scrum выделяют следующие роли для участников процесса:

1, Product Owner.
По сути, это или руководитель проекта, или главный геймдизайнер, или продюсер — кто выполняет эту роль, зависит от команды. Product Owner формирует и сортирует по срочности задачи в списке Project Backlog и Sprint Backlog. Он же формулирует задачи и цели каждого спринта.

2. Scrum Master
Это человек, который следит за тем, чтобы принципы Scrum не нарушались и все процессы, связанные с организацией труда, протекали в штатном режиме. По сути это человек, который знает о Scrum методологии больше всех и разрешает споры, которые возникают насчет процесса ведения спринта и дает дополнительную мотивацию команде, устраняя все возможные препятствия, возникающие на ее пути. В маленькой команде для этой роли как правило не выделяют отдельного человека, а эту задачу берет на себя Product Owner.

3. Команда разработчиков.

Давайте суммируем все вышесказанное:

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

2. Количество задач в Scrum ограничено так же, как и в Kanban, но ограничено с учетом времени благодаря формированию общего значения человекочасов или story points. При этом задача является завершенной только после тестирования, что означает ее качественное выполнение: выбор между завершением всех задач спринта в срок и качеством их выполнения всегда падает в пользу последнего.

3. Scrum заимствует систему анализа проблем и их устранения у Lean Six Sigma. Она представлена в Scrum в виде ретроспективы и графика сгорания задач. При этом в Scrum отсутствует излишняя формализация: правило, которые было выявлено для задачи в конкретном спринте, в каком-то другом спринте для аналогичной задачи может не сработать, тогда система гибко подстроится под текущую ситуацию на проекте.

Немного о Trello

И напоследок, вкратце расскажу, чем мне нравится Trello, какие у него есть преимущества.

1, Простота использования
Существует великое множество различных программ для управления проектами, до Trello я пробовала только более сложные варианты (Unfuddle, Jira, Redmine). Программа, как и методология управления проектом, выбирается с оглядкой на каждый конкретный случай. Для больших и серьезных проектов функций Trello будет явно недостаточно. В крупных корпорациях подобного рода системы вообще зачастую пишутся отдельно и индивидуально. Но маленькой или начинающей команде, и даже команде из одного человека и Trello, и методология Scrum (пусть и в упрощенном виде) подойдут отлично.

2. Кастомизация списков
Возможность создавать свои списки, а также несколько досок на одном аккаунте (например, одна доска может быть с текущим спринтом, вторая — с архивами всех завершенных спринтов).

3. Кастомизация задач
Возможность настраивать кастомизированные метки (цветные отметки на задаче), добавлять участников в задачу, прикреплять файлы, прикреплять документы из Google Drive, делать, или не делать обложки для задач — все это можно настроить за 10 минут на ваш вкус.

4. Определение сроков
Возможность устанавливать сроки конкретной задаче.

5. Удобство управления
Карточки перетаскиваются из списка в список простым драг-н-дропом. В самой карточке хранится история всех ее изменений и перемещений между списками.

6. Различные дополнения
Большое количество платных и бесплатных дополнений для Trello, которые позволяют еще более детально настроить доску так, как вам хочется. Есть даже расширения, которые будут строить график сгорания задач за вас.