Вместо введения
Энтузиазм, оптимизм, слабоумие и отвага. Ни один классический инди-проект не обходится без этого.
- Без энтузиазма невозможно делать игру с людьми, которым не платят зарплату.
- Оптимизм придает сил команде. Позволяет не забросить все, а ломиться к своей цели невзирая на внешние и внутренние раздражители.
- Слабоумие…это конечно стеб. Тем не менее умные люди игрушки не делают, они в банке работают или на худой конец в НИИ 😊
- Отвага. Ну куда без нее. Нужно не бояться жить на дошираках и быть готовому, к тому, что дети будут спрашивать, что им кушать завтра, когда дошираки кончатся. Нужно иметь смелость показывать свою игрульку всем подряд и достойно встречать потоки лести, которые обязательно обрушатся на разработчика.
У нас все это было. Да и есть до сих пор.
Предыстория и предпосылки
Как работали в старом режиме
Так сложилось исторически, что в команде Rummy Games довольно много людей. Хоть мы и начинали вчетвером, но быстро выросли до 15, а потом еще быстрее до 30. И тут важно понимать, что имея штат сотрудников в количестве от 10 человек разработчику требуется какая-то система управления. Особенно если никому ни копейки не платят.
В нашей практике модель постановки и контроля задач складывалась на базе обычной водопадной системы. Так было проще рулить процессами. Сначала мы создали глобальный план по выпуску прототипа и архитектуры проекта, а потом каждый понедельник проводили общекомандный созвон, смотрели чего добились все вместе за прошедшую неделю и шли дальше.
В таком режиме мы существовали почти 2 года. Основная работа по поддержанию и обслуживанию такой системы ложилась на руководителя и проектных менеджеров (когда такие были). Но со временем стало понятно, что эффективность выполнения работ низкая. Хоть мы и делали еженедельные срезы, но результат работ мы не могли “пощупать”, билда чаще всего просто не было. Он не выпускался “постоянно”, а обновления видели только программисты.
Периодичность подготовки билда зависела конечно не только от системы планирования, были еще ограничения технического характера: иногда рабочего билда просто не было, так как шел рефакторинг кода. Собирать было просто не из чего.
Примерно вот на таких лыжах мы въехали в 2021 год.
Как сейчас
Сегодня в проектной системе управления больше от Scrum, чем от водопада.
Мы задаем себе глобальную цель и планируем примерно на 5-6 спринтов вперед. В каждой точке маршрута – билд с новым функционалом.
Один наш спринт длится 3 недели. Цифра выведенная опытным путем, за это время команда энтузиастов в свободное от работы время успевает внести какие-то более или менее ощутимые изменения в проект.
В начале спринта мы перетряхиваем существующий план (бэклог), актуализируем его и утверждаем. К концу спринта мы выпускаем билд. В идеале он должен содержать весь запланированный функционал. В основном у нас это получается. Ну по крайней мере процентов на 80 билд содержит те функции, которые мы в нем планировали. После чего он готов к тестированию и проверке «в бою».
Можете сами оценить результат последних 7 спринтов: загляните к нам на страницу плейтеста в Steam. Будем крайне признательны за обратную связь.
План и факт
Чего мы хотели добиться
При введении новой системы наши цели были просты:
- Получать постоянную обратную связь на свои действия. Это позволяет более гибко корректировать игру в процессе разработки. Когда у вас спринт в 3 недели, а не в 13, то результат виден быстрее. Тем не менее в разработке большого проекта неизбежно будет промежуток времени, когда вся команда трудится и не видит билда. Его просто не из чего пока собрать.
Кстати, до того, как вы сможете обновлять билд регулярно, я не вижу смысла в спринтовой системе. - Бодрить команду. Люди должны видеть результаты своей работы. Иначе они быстро заскучают и будут думать, что делают все «в стол». Да, не все из команды будут давать обратную связь по билду. Даже не все в него постоянно играют. Но результат должен демонстрироваться регулярно все равно. Это поднимает мораль и объединяет людей. Ведь они сделали это вместе.
Всегда нужна четкая и прозрачная цель. Достигая ее растет мотивация двигаться дальше. Появляется прозрачность в том, что мы на самом деле делаем. - Просто попробовать что-то новое. Мы много слышали о том, что другие команды работают в гибкой системе управления проектами. А мы 2 года работали без нее. Так почему бы не протестировать. Если не понравится, всегда сможем откатиться. Да и созвоны каждую неделю из понедельника в понедельник были не слишком информативными. Работы по подготовке к такому созвону много, а сути выполненных работ – мало.
Благодаря спринтам создание проекта становиться более гибким. Легче отказываться от лишних фичей или наоборот вводить новые, определять очередность работ. Становиться легче определить какие механики важны прямо сейчас, а какие можно сделать намного позже. Эта система отлично подходить командам без большого опыта.
Как мы это внедряли
К 2021 году в команде уже сложилось ядро самых активных и продуктивных людей, которые тратят на проект гораздо больше времени, чем остальные. Мы их внутри в шутку называем «совет директоров». Как раз этот круг людей совместно выбирает направление развития и то, как будет идти разработка.
В январе совет сел и составил план спринтов до майского DevGamm с небольшим аппендиксом до июньского Steam Fest. Всего получилось 7 трехнедельных спринтов с учетом праздников и прочих лагов.
План этот был составлен в табличном варианте в общих чертах (пример плана приложить ссылкой). Каждый из пунктов разбили на более мелкие, завели соответствующую доску в Трелло, разбили ее по столбцам, отражающим бэклог и текущий спринт. При этом мы не заводим в Трелло спринты наперед, только текущий. Так как его состав может сильно поменяться в момент актуализации на запуске.
Таким образом у нас был большой план спринтов с крупными задачами и доска в Трелло с наборами карточек под каждый спринт.
Так и живем до сих пор.
Промежуточные итоги и выводы
- Рекомендуем всем пересаживаться на спринтовую систему. Но каждый спринт должен строго оканчиваться обновленным билдом, именно в этом смысл.
- Имейте систему контроля версий. Всегда должна быть возможность откатиться к прежним версиям билда.
- Не внедряйте спринты, пока не готовы обновлять билд постоянно. Или будьте готовы собирать отчет для всей команды, показывая наглядно достигнутый результат. Но без билда это сложнее.
- Системой планирования надо управлять, актуализировать, всячески поддерживать и контролировать. В отсутствии ответственного за эту администраторскую часть, есть риск бросить все очень быстро, разочаровавшись в ней.