Проходя собеседование на должность руководителя разработки в некоторых компаниях, автору в ходе разговора приходилось выслушивать одну и ту же историю:
Странность ситуации заключается в том, что вроде бы умные и опытные руководители компаний задумываются об организации процесса разработки не в начале работы над проектом, а лишь только тогда, когда набранная команда терпит неудачу. Между тем, над процессом следует задумываться в самом начале.
В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.
Larian Studios — это небольшая компания с количеством сотрудников чуть более 100 человек разрабатывает серию ролевых игр Divinity. Компания состоит из нескольких студий, расположенных в разных странах. Одна из студий находится в Санкт-Петербурге. Игры выпускаются под разные платформы, среди которых Windows, Linux, Mac OS X, Xbox ONE и PlayStation 4.
Для разработки игр компания использует свой 3D движок и свою интегрированную среду разработки. Несмотря на то, что движок портирован под разные платформы, разработка ведется на платформе Windows. Это связано с тем, что среда разработки написана с использованием технологий WinForms и WPF и работает под управлением среды .NET Framework.
Интегрированная среда разработки представляет собой приложение, внутри которого можно запустить игру, как целиком, так и отдельный игровой режим или уровень. Можно сказать, что это своего рода контейнер для запуска игры, который снабжен различными инструментами для создания уровней, редактирования поверхности, расстановки объектов, создания и редактирования скриптов, диалогов между персонажами и т.д. и т.п.
Несмотря на то, что среда разработки выглядит внушительно, а множество UI-элементов обеспечивает доступ к обширной функциональности, однако, удобство ее использования оставляет желать лучшего как из-за перегруженности самого интерфейса, так и из-за того, что отдельные его части не согласованы друг с другом. В этом и состоит основная проблема.
Основные требования к инструментарию можно выразить 3-мя условиями:
Инструменты разрабатываются для внутренних заказчиков. К ним относятся все те люди, которые непосредственно делают игру. Это и дизайнеры визуальных эффектов, и 3D-аниматоры, и игровые дизайнеры, и скриптеры и т.д. и т.п.
Отдел разработки инструментария является небольшим. Его состав:
Чтобы организовать работу отдела, необходимо поставить процесс разработки. Поставленный процесс поможет сдавать проекты в срок и с заданным качеством. Поскольку команда небольшая, и все друг друга знают, то мы используем не тяжеловесный и зарегулированный всякими правилами, а легкий процесс разработки. Многие вещи в нем не формализованы, а другие — основываются на устных договоренностях. Однако есть и четко структурированные вещи, о которых мне и хочется рассказать.
Процесс разработки в отделе инструментария можно разделить на 4 этапа:
Работа над новым инструментом начинается с разработки концепции. Этим занимаются наши внутренние Заказчики такие, как дизайнеры визуальных эффектов, 3D-аниматоры, игровые скриптеры и т.д.
Процесс создания концепции состоит из нескольких стадий:
Во время планирования команде важно выполнить три вещи:
На этом шаге важно понять, что будет собой представлять альфа-версия продукта. В нашем случае, альфа-версия — это версия программы, которая получается по окончанию третьего этапа — разработка, о котором подробнее мы будем говорить ниже. Альфа-версия может включать в себя далеко не все требования, которые Заказчики сформулировали в концепции, а только лишь некоторое подмножество. Почему?
Дело в том, что концепция включает в себя многие “хотелки” Заказчиков. Некоторые из них не проверены практикой, и могут в реальности не пригодиться. И, наоборот, может потребоваться реализовать что-то другое, о чем Заказчики не подумали, когда писали концепцию.
Поэтому мы стараемся сделать так, чтобы Заказчики начали пользоваться нашей программой как можно быстрее. Пусть не в рабочем, но хотя бы тестовом режиме. Только реальный опыт использования может показать, какие требования важны, а какие — несущественны.
Чтобы достичь этой цели, мы пытаемся понять, что должна включать минимальная рабочая версия. И из всех требований — по согласованию с Заказчиками — выбираем только те, без реализации которых действительно невозможно обойтись.
Минимальная рабочая версия и является альфа-версией. На ее выпуске заканчивается этап разработки.
После того, как наши Заказчики начинают использовать нашу программу, выявляются баги и различные шероховатости. Кроме того, появляется и опыт использования сначала в тестовых, а затем — и в “боевых” условиях. Этот опыт позволяет оценить остальные требования: какие из них важны, а какие — несущественны.
Мы устраняем шероховатости, реализуем переоцененные требования и исправляем баги на этапе сопровождения.
Чтобы составить план проекта, нужно:
По моему мнению, существуют два вида оценки проекта:
Предварительная оценка является достаточно грубой. Она использует упрощенную декомпозицию, но по этой причине не требует слишком много времени.
Детальная оценка является более точной. Но для того, чтобы ее получить, необходимо выполнить проектирование и сделать декомпозицию работ.
Чтобы сэкономить время, мы делаем грубую оценку проекта. Однако и при использовании “грубых моделей” можно получить точный результат. Как мы этого добиваемся? Для оценки проекта вместо одной модели мы используем три:
Функциональная модель представляет разрабатываемую программу в виде набора полезных функций. Она отражает точку зрения пользователя.
Компонентная модель представляет приложение в виде набора модулей. Она отражает взгляд инженера.
Процессная модель представляет собой взгляд на программу, как на проект, который имеет некоторую протяженность во времени и состоит из последовательности этапов. Каждый этап имеет свои задачи (часто организационные или управленческие) и, как результат, его длительность может быть оценена, как суперпозиция времени, необходимого для выполнения каждой из задач. Процессная модель отражает точку зрения менеджера.
Будучи объединенными, эти три точки зрения представляют собой комплексный взгляд на один и тот же продукт. Какие-то вещи лучше оценить через функции, какие-то — через модули, какие-то — через процесс. В результате, получается сбалансированная оценка.
Возможно, более детально данная тема будет раскрыта в отдельной статье.
Чтобы правильно учесть имеющиеся ресурсы, нужно понять, что ни один работник не тратит 100% своего времени на выполнение задач. Обязательно, какую-то часть своего времени программист будет тратить на общение с коллегами и небольшой отдых.
Конечно, если в команде только 2 человека, и они работают с примерно одинаковой производительностью, то непроизводительными тратами времени можно пренебречь и считать, что один рабочий человеко-день составляет 8 часов. В самом деле, при таком размере команды время на согласование каких-то вопросов не будет слишком значительным.
Однако если в команде уже 4 человека, то следует учитывать как время на коммуникацию, так и разную производительность труда разных людей.
При оценке имеющихся ресурсов мы используем такую таблицу производительности труда:
Ведущий инженер, помимо программирования, тратит часть своего времени на планирование, распределение задач, общение с Заказчиками, введение в курс дела новеньких, если такие есть, и на обучение неопытных. Поэтому мы считаем, что он может тратить на программирование лишь половину своего времени.
Обычный инженер должен работать с 85-ю процентной производительностью. Остальные 15% своего времени он тратит на коммуникацию с остальными членами команды, общение с Заказчиками и написание отчетов.
Как известно, подключение к проекту новых людей поначалу не ускоряет, а замедляет разработку. Это связано с тем, что члены команды вынуждены отвлекаться от работы на обучение нового сотрудника. Да и у самого новичка производительность труда в первое время невелика: мы считаем, что он тратит на обучение до половины своего рабочего времени. Со временем производительность должна расти. Если она не растет, то это повод задуматься о целесообразности его пребывания в команде.
Неопытный новичок поначалу вынужден тратить на обучение больше времени, чем просто новичок. Поэтому производительность в 25% в самом начале не должна выглядеть чем-то страшным. Однако со временем она тоже должна расти.
Используя эти цифры, можно оценить реальную производительность труда всей команды.
Предположим, команда состоит из 4-х человек:
Тогда производительность всей команды будет равна:
1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2,1 человеко-дня
Это в два раза меньше, чем при простом подходе, когда считается, что каждый человек работает со 100-процентной производительностью.
При планировании нужно распределить всю работу по нескольким этапам. Каждый этап заканчивается майлстоуном. Майлстоун — это некоторая точка во времени, когда оцениваются результаты проделанной работы.
При планировании майлстоунов необходимо решить две задачи. Во-первых, нужно распределить пользовательские требования по майлстоунам. Во-вторых, необходимо оценить длительность каждого майлстоуна. При этом, важно добиться, чтобы длительность майлстоунов была примерно одинаковая.
Для распределения работ по майлстоунам мы используем несколько критериев:
Чтобы работа над проектом продвигалась успешно, необходимо подумать о том, как будет строиться общение внутри команды между отдельными разработчиками, а также между командой и Заказчиками.
Мы у себя в компании используем несколько практик, которые оказались — в нашем случае! — весьма успешными.
При старте нового проекта мы создаем пространство проекта в “облаке”. В качестве облачного хранилища мы используем Google Drive. Но можно использовать и другие сервисы: Яндекс Диск, Mail.Ru, One Drive от компании Microsoft и другие.
Если требования конфиденциальности или просто личные предпочтения не позволяют использовать облачный сервис, то можно установить Sharepoint на локальном сервере, или использовать систему контроля версий типа svn, git или perforce, или завести папку проекта на обычном файловом сервере. Вариантов — от простых до экзотических — масса.
Единое пространство проекта позволяет сконцентрировать все документы, относящиеся к проекту, в одном месте. А использование “облака” позволяет открыть доступ к ним всем членам команды: каждому — со своего рабочего места.
Что представляет собой пространство проекта? Это обычная папка в облачном хранилище, к которой настроены права доступа. Внутри себя она содержит другие папки, каждая из которых концентрирует в себе документы, относящиеся к определенной дисциплине.
Например, в нашем случае папка проекта обычно содержит в себе 4 такие подпапки:
Список контактов представляет собой документ, в котором содержатся имена всех людей, так или иначе связанных с проектом, а также — способы связаться с ними: телефоны, адреса электронной почты, аккаунты в скайпе и т.п.
Список контактов позволяет довольно быстро найти нужного человека. Менеджеры, пренебрегающие составлением подобного списка, потом напрасно тратят свое время и свои нервы, чтобы найти своего ведущего программиста, дизайнера или инженера по качеству в каком-нибудь экстренном случае.
Список контактов лучше всего оформлять в виде примерно такой таблицы:
Каждый день наша небольшая команда (4 программиста и 1 QA-инженер) собирается на короткое совещание, чтобы обсудить текущий ход работы над проектом. Обычно такое совещание занимает 10 — 15 минут и позволяет всем членам команды быть в курсе дел.
Формат совещания на протяжении длительного времени остается неизменным и состоит из трех частей:
В первой части менеджер проекта (или ведущий программист, выполняющий менеджерские функции) информирует команду о каких-то новостях, связанных с проектом. Это могут быть какие-то управленческие решения кураторов проекта, просьбы со стороны внутренних Заказчиков, положительные или отрицательные отзывы по разрабатываемому приложению или по работе команды.
Затем наступает черед отчетов. На этом этапе каждый член команды отчитывается о своей работе, отвечая на три следующих вопроса:
Такой формат отчета позволяет менеджеру проекта (или ведущему инженеру, выполняющему часть менеджерских функций) быть в курсе того, как двигается проект и какого прогресса достигла команда. А поскольку каждый член команды должен рассказать о задаче, над которой работает в данный момент и назвать имеющиеся проблемы, то это помогает другим членам команды вовремя узнавать о зависимостях между своей задачей и задачей своего коллеги и, при необходимости, эти зависимости разрулить, скорректировав свои действия.
Еще один плюс публичных отчетов заключается в том, что работа каждого члена команды оказывается на виду. Невозможно скрыть отсутствие результатов. Это является дополнительным стимулирующим фактором как для самого человека, который не сумел продвинуться по своей задаче, так и для команды: кто-то может дать подсказку или предложить взять часть работы по задаче на себя.
После отчетов наступает очередь обсуждений. Если имеются какие-либо проблемы, то они кратко обсуждаются и вырабатываются подходы к их решению.
Практика работы нашей команды подтвердила высокую полезность таких совещаний. А чтобы польза сохранялась и в дальнейшем, важно, чтобы совещания не перерастали в длительные и безрезультатные обсуждения всех имеющихся проблем.
Перед началом работы по проекту мы также создаем “обсуждение” в программе-коммуникаторе. Наша компания использует для этой цели slack. Но можно использовать и другие программы такие, как HipChat, skype и т.п.
Такое “обсуждение” (“разговор”, “группа” или “конференция”) позволяет состыковать команду с людьми, которые работают над проектом удаленно, например, с внутренними Заказчиками, которые могут находиться в другом офисе или даже в другой стране, или с некоторыми удаленными сотрудниками.
В нашей компании “обсуждение” в коммуникаторе активно используется как разработчиками, так и Заказчиками. Разработчики используют его для задания коротких вопросов к Заказчикам и для информирования их о новых возможностях выпущенной версии приложения. Заказчики оставляют в “обсуждении” свои отзывы и просьбы исправить какой-либо критичный баг, если это надо сделать срочно.
Процесс разработки состоит из последовательности майлстоунов. Каждый майлстоун заканчивается выпуском версии приложения, которая поддерживает запланированную функциональность. Последний майлстоун этапа разработки заканчивается выпуском альфа-версии.
Под альфа-версией понимается приложение, которым можно пользоваться, хотя оно и содержит баги.
В течение каждого майлстоуна выполняются такие работы:
Во время планирования майлстоуна работа, которую нужно сделать к окончанию майлстоуна, разбивается на задачи. Выполняется оценка задач, а сами задачи вносятся в систему контроля задач. В качестве такой системы мы используем JIRA, но это не имеет существенного значения. Вместо нее можно использовать любую другую систему контроля задач: от бесплатного Redmine до дорогущего DevTrack.
Все задачи условно можно подразделить на две категории, каждая из которых отражает определенный взгляд на планируемую работу. В нашем случае это:
Пользовательские задачи определяются по конечному результату, который необходимо достичь. Этот результат хорошо виден конечному пользователю, и поэтому пользовательские задачи легко верифицируются QA-инженером: результат либо есть, либо его нет.
Примеры таких задач:
Однако, наряду с преимуществами пользовательские задачи обладают и недостатками: их сложно оценить, они могут обладать циклическими зависимостями (например, для выполнения задачи Б необходимо сначала выполнить задачу А, а для выполнения задачи А, в свою очередь, необходимо выполнить задачу Б).
Пользовательские задачи можно разделить на две категории:
Задачи-критерии — это своего рода пункты чек-листа. QA-инженер может пройтись по нему, условно поставить галочки (если пункты выполняются) и закрыть родительскую задачу, если все “галочки” проставлены.
Примечание: Следует отметить, что задачи-критерии оформляются в виде подзадач для задач первой категории.
Существуют 3 вида критериев:
Технические задачи отражают взгляд программиста на работу, связанную с реализацией того или иного требования или той или иной группы требований. Они представляют собой элементы плана действий и выражаются в технических терминах или, по крайней мере, лексиконом программиста.
ПРИМЕРЫ технических задач:
Технические задачи легче оценить, а полученная оценка — более точна. Также из них можно сформировать поток работ, и легче учесть и разрулить зависимости между ними.
Тем не менее, они сложнее поддаются верификации. Часто результат выполнения технической задачи не виден конечному пользователю. Чтобы он был заметен, бывает необходимо выполнить серию технических задач.
Одновременное использование технических и пользовательских задач оправдано, когда команда состоит из более 6-ти человек. В этом случае, сроки и потраченное время оцениваются по техническим задачам, а результат — по пользовательским задачам. Однако такой подход требует выделенного на полную ставку менеджера, в обязанности которого входит распределение и технических, и пользовательских задач между членами команды и на установления соответствия между пользовательскими и техническими задачами.
В нашем случае команда не такая большая. Поэтому мы используем только пользовательские задачи, т.к. они легко могут быть проверены QA-инженером. Все технические тонкости и подходы к реализации мы обсуждаем на словах. Точно также мы разруливаем зависимости между различными пользовательскими задачами, если они есть.
При занесении задачи в JIRA мы маркируем ее метками. Метки позволяют настраивать различные фильтры, а также — собирать и анализировать статистику.
В качестве меток мы используем:
Перед отправки написанного кода в общий репозиторий необходимо пройти процедуру ревью. Поначалу ревью кода делают более опытные разработчики. Но и новичков следует привлекать к ревью чужих изменений как можно раньше. Это позволит им ознакомиться с кодом приложения и лучше понять стиль, принятый в команде.
Наиболее распространенными ошибками, которые находятся во время процедуры ревью кода, являются такие:
Тестирование приложения происходит параллельно с разработкой. Для этого в отделе имеется QA-инженер, который занимается только тестированием разрабатываемых инструментов.
Каждое утро QA-инженер забирает обновленный исходный код из системы контроля версий и самостоятельно собирает его. Это входит в его обязанности. Таким образом, QA-инженер всегда работает с обновленной версией и не просит программиста собрать очередной билд для него. Программист привлекается только в том случае, если во время сборки или во время запуска произошла какая-то ошибка.
По мере выполнения задач QA-инженер смотрит, как они выполнены. Если он находит какой-то баг, то сразу же заводит его в системе контроля багов. Наше правило — проводить все найденные баги через баг-трекер. Даже если баг обнаруживает программист, то не бросается его исправлять сразу, а просит QA-инженера его повторить и, если он воспроизведется, то завести его в системе контроля багов. Почему это важно?
Во-первых, потому что в лице QA-инженера появляется независимая сторона, которая сможет проконтролировать, что баг исправлен.
Во-вторых, потому что зарегистрированный в баг-трекере баг попадает в статистику, которую впоследствии можно анализировать на предмет наиболее распространенных ошибок или наиболее “бажных” подсистем.
При регистрации бага в системе контроля багов рекомендуется использовать метки. Наиболее важные из них:
Такие метки позволяют проанализировать статистику по багам должным образом.
Процесс сопровождения, как и процесс разработки, состоит из последовательности майлстоунов. Каждый майлстоун заканчивается выпуском очередной версии программы. Только, в отличие от версий, выпускаемых на этапе разработки, версии приложения, поставляемые на этапе сопровождения, можно полноценно использовать в работе.
Условно процесс сопровождения можно представить последовательностью альфа-версий, которая заканчивается выпуском бета-версии, а затем — финальной версии.
Только в реальной жизни до выпуска окончательной версии дело никогда не доходит. Практика использования приложения вносит свои коррективы, и заказчики предъявляют к приложению все новые и новые требования, которые реализуются в ходе очередного майлстоуна. Возможно, в будущем мы подумаем над системой нумерации версий продукта, но пока этого не требуется.
Длительность майлстоуна на этапе сопровождения обычно составляет 3-4 недели. Это меньше, чем средняя продолжительность майлстоуна во время этапа разработки. Объясняется это уменьшением количества задач, которые необходимо реализовать. Это понятно, т.к. основная функциональность была реализована во время разработки.
Задачи, которые выполняются в ходе этапа сопровождения, условно можно отнести к одному из двух видов:
Одна из важных целей, которую мы преследуем на этапе сопровождения — это сделать инструмент чрезвычайно удобным в использовании. Чтобы достичь этой цели, мы стараемся устранить все препятствия, которые мешают нормальному использованию.
Как мы выявляем такие препятствия? Просто даем версию приложения заказчикам и просим поработать с ней в полевых условиях. По результатам работы спрашиваем:
Полученные ответы анализируем и разрабатываем варианты решений, которые и устраняют проблемы.
Опыт использования приложения в реальной деятельности позволяет приоритезировать еще не реализованные требования. Если, рассуждая абстрактно, в отрыве от реальной практики, заказчики склонны фантазировать или запрашивать features, которые они где-то подсмотрели, то при регулярной работе с приложением сразу становится понятно, чего не хватает прямо сейчас, а что — может и подождать.
Опыт реального использования приложения позволяет сформулировать новые требования и переоценить уже существующие.
В статье рассматривается процесс разработки в отделе инструментария игровой студии. Предложенный процесс применяется уже на протяжении двух лет. Он помог существенно улучшить качество разрабатываемого инструментария. От “наколеночного” софта удалось перейти к разработке программ, имеющих профессиональный вид.
За указанное время отдел разработал 2 серьезных приложения: одно — для дизайнеров визуальных эффектов, а другое — для 3D-аниматоров. Первое приложение уже активно используется в разработке игры и снискало положительные отзывы со стороны пользователей. Оно также позволило отказаться от используемого ранее приложения третьей стороны и, таким образом, сэкономить деньги на оплату лицензии. Второе приложение было выпущено недавно и в настоящий момент активно внедряется в разработку игры.
За два года отдел вырос в 2 раза: от двух программистов и 1-го инженера по качеству, работавшего на проекте лишь время от времени, до 4-х программистов и 1-го инженера по качеству на полную ставку. При текущем процессе у отдела имеется потенциал роста до 6 — 7 программистов. При дальнейшем росте сверх этого количества разработчиков, вероятно, потребуются изменения в процессе, связанные с большей формализацией.
Автор благодарит своих друзей и коллег за помощь при подготовке статьи.
«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».
Странность ситуации заключается в том, что вроде бы умные и опытные руководители компаний задумываются об организации процесса разработки не в начале работы над проектом, а лишь только тогда, когда набранная команда терпит неудачу. Между тем, над процессом следует задумываться в самом начале.
В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.
О компании
Larian Studios — это небольшая компания с количеством сотрудников чуть более 100 человек разрабатывает серию ролевых игр Divinity. Компания состоит из нескольких студий, расположенных в разных странах. Одна из студий находится в Санкт-Петербурге. Игры выпускаются под разные платформы, среди которых Windows, Linux, Mac OS X, Xbox ONE и PlayStation 4.
О технологиях
Для разработки игр компания использует свой 3D движок и свою интегрированную среду разработки. Несмотря на то, что движок портирован под разные платформы, разработка ведется на платформе Windows. Это связано с тем, что среда разработки написана с использованием технологий WinForms и WPF и работает под управлением среды .NET Framework.
Интегрированная среда разработки представляет собой приложение, внутри которого можно запустить игру, как целиком, так и отдельный игровой режим или уровень. Можно сказать, что это своего рода контейнер для запуска игры, который снабжен различными инструментами для создания уровней, редактирования поверхности, расстановки объектов, создания и редактирования скриптов, диалогов между персонажами и т.д. и т.п.
Редактор Larian Editor используется для создания игры Divinity: Original Sin 2
Несмотря на то, что среда разработки выглядит внушительно, а множество UI-элементов обеспечивает доступ к обширной функциональности, однако, удобство ее использования оставляет желать лучшего как из-за перегруженности самого интерфейса, так и из-за того, что отдельные его части не согласованы друг с другом. В этом и состоит основная проблема.
О требованиях
Основные требования к инструментарию можно выразить 3-мя условиями:
- Он должен выглядеть профессионально, а не как “наколеночный” софт.
- Должен обладать заданной функциональностью и быть удобным в использовании.
- Сроки и стоимость разработки не должны превышать разумных пределов.
Редактор All Spark, разработанный отделом инструментария, используется для создания визуальных эффектов
О заказчиках
Инструменты разрабатываются для внутренних заказчиков. К ним относятся все те люди, которые непосредственно делают игру. Это и дизайнеры визуальных эффектов, и 3D-аниматоры, и игровые дизайнеры, и скриптеры и т.д. и т.п.
Об отделе
Отдел разработки инструментария является небольшим. Его состав:
- 1 ведущий программист (он же менеджер)
- 3 программиста
- 1 инженер по качеству
О процессе
Обзор
Чтобы организовать работу отдела, необходимо поставить процесс разработки. Поставленный процесс поможет сдавать проекты в срок и с заданным качеством. Поскольку команда небольшая, и все друг друга знают, то мы используем не тяжеловесный и зарегулированный всякими правилами, а легкий процесс разработки. Многие вещи в нем не формализованы, а другие — основываются на устных договоренностях. Однако есть и четко структурированные вещи, о которых мне и хочется рассказать.
Стадии и этапы разработки
Процесс разработки в отделе инструментария можно разделить на 4 этапа:
- Разработка концепции
На этом этапе наши внутренние Заказчики готовят концепцию разрабатываемой программы и формулируют основные требования.
- Планирование
На данном этапе мы делаем оценку проекта и создаем его план.
- Разработка
На данном этапе производится разработка программы.
- Сопровождение
В программу вносятся улучшения, исправляются баги.
Этап 1. Разработка концепции
Работа над новым инструментом начинается с разработки концепции. Этим занимаются наши внутренние Заказчики такие, как дизайнеры визуальных эффектов, 3D-аниматоры, игровые скриптеры и т.д.
Процесс создания концепции состоит из нескольких стадий:
- Осознание потребностей
На этой стадии заинтересованные лица осознают свои потребности в инструменте и причины, которые их толкают к тому, чтобы подобный инструмент был разработан внутри студии. В качестве таких причин могут выступать:
- Финансовые
До недавнего времени использовали инструмент, который лицензировали у третьей стороны. Но цена за лицензию выросла так, что разработать свой инструмент выходит дешевле.
- Технологические
Имеющийся инструмент не поддерживает новую платформу, для которой разрабатывается игра, или же с его помощью нельзя реализовать требование, которое должно стать одним из ключевых в новой игре.
- Эргономические
Имеющимся инструментом неудобно пользоваться, что существенным образом сказывается на производительности труда и, как следствие, скорости разработки игры.
- Финансовые
- Формулирование требований
На этой стадии заинтересованные лица формулируют требования к новому инструменту. Эти требования включают как функциональную часть (что инструмент должен делать), так и эргономическую составляющую (насколько инструментом должно быть удобно пользоваться).
- Поиск решений-аналогов
Поиск решений проблем, сформулированных на предыдущем шаге, следует начать с изучения программ-аналогов. В нашем случае, такими аналогами являются Unreal Editor, Unity 3D, FxStudio Designer и другие программы. Глубокое знание подобных инструментов позволяет подсмотреть удачные решения и использовать их в собственном приложении.
- Рисование макетов
Макеты позволяют разработчикам создать визуальное представление о том, как разрабатываемый инструмент будет выглядеть. Вначале достаточно нарисовать несколько ключевых экранов таких, как главное окно приложения, окно редактирования основных данных, панели инструментов. По мере разработки можно добавлять макеты и для остальных окон.
- Подготовка документа
Финальный документ формируется путем объединения мокапов с требованиями. Документ разбивается на главы на поэкранной основе: каждый экран — отдельная глава. В начале главы приводится макет соответствующего экрана, а под ним — соответствующие требования в текстовом виде.
Этап 2. Планирование
Во время планирования команде важно выполнить три вещи:
- Договориться о результате с заинтересованными лицами.
- Составить план проекта.
- Составить план коммуникаций.
Шаг 2.1. Договориться о результате
На этом шаге важно понять, что будет собой представлять альфа-версия продукта. В нашем случае, альфа-версия — это версия программы, которая получается по окончанию третьего этапа — разработка, о котором подробнее мы будем говорить ниже. Альфа-версия может включать в себя далеко не все требования, которые Заказчики сформулировали в концепции, а только лишь некоторое подмножество. Почему?
Дело в том, что концепция включает в себя многие “хотелки” Заказчиков. Некоторые из них не проверены практикой, и могут в реальности не пригодиться. И, наоборот, может потребоваться реализовать что-то другое, о чем Заказчики не подумали, когда писали концепцию.
Поэтому мы стараемся сделать так, чтобы Заказчики начали пользоваться нашей программой как можно быстрее. Пусть не в рабочем, но хотя бы тестовом режиме. Только реальный опыт использования может показать, какие требования важны, а какие — несущественны.
Чтобы достичь этой цели, мы пытаемся понять, что должна включать минимальная рабочая версия. И из всех требований — по согласованию с Заказчиками — выбираем только те, без реализации которых действительно невозможно обойтись.
Минимальная рабочая версия и является альфа-версией. На ее выпуске заканчивается этап разработки.
Наш собственный редактор Genome позволяет 3D-аниматорам визуально программировать персонажа
После того, как наши Заказчики начинают использовать нашу программу, выявляются баги и различные шероховатости. Кроме того, появляется и опыт использования сначала в тестовых, а затем — и в “боевых” условиях. Этот опыт позволяет оценить остальные требования: какие из них важны, а какие — несущественны.
Мы устраняем шероховатости, реализуем переоцененные требования и исправляем баги на этапе сопровождения.
Шаг 2.2. Составить план проекта
Чтобы составить план проекта, нужно:
- Сделать оценку проекта
- Оценить имеющиеся ресурсы
- Запланировать майлстоуны
Шаг 2.2.1. Сделать оценку проекта
По моему мнению, существуют два вида оценки проекта:
- Предварительная оценка
- Детальная оценка
Предварительная оценка является достаточно грубой. Она использует упрощенную декомпозицию, но по этой причине не требует слишком много времени.
Детальная оценка является более точной. Но для того, чтобы ее получить, необходимо выполнить проектирование и сделать декомпозицию работ.
Чтобы сэкономить время, мы делаем грубую оценку проекта. Однако и при использовании “грубых моделей” можно получить точный результат. Как мы этого добиваемся? Для оценки проекта вместо одной модели мы используем три:
- Функциональную модель
- Компонентную модель
- Процессную модель
Функциональная модель представляет разрабатываемую программу в виде набора полезных функций. Она отражает точку зрения пользователя.
Компонентная модель представляет приложение в виде набора модулей. Она отражает взгляд инженера.
Процессная модель представляет собой взгляд на программу, как на проект, который имеет некоторую протяженность во времени и состоит из последовательности этапов. Каждый этап имеет свои задачи (часто организационные или управленческие) и, как результат, его длительность может быть оценена, как суперпозиция времени, необходимого для выполнения каждой из задач. Процессная модель отражает точку зрения менеджера.
Будучи объединенными, эти три точки зрения представляют собой комплексный взгляд на один и тот же продукт. Какие-то вещи лучше оценить через функции, какие-то — через модули, какие-то — через процесс. В результате, получается сбалансированная оценка.
Возможно, более детально данная тема будет раскрыта в отдельной статье.
Шаг 2.2.2. Оценить имеющиеся ресурсы
Чтобы правильно учесть имеющиеся ресурсы, нужно понять, что ни один работник не тратит 100% своего времени на выполнение задач. Обязательно, какую-то часть своего времени программист будет тратить на общение с коллегами и небольшой отдых.
Конечно, если в команде только 2 человека, и они работают с примерно одинаковой производительностью, то непроизводительными тратами времени можно пренебречь и считать, что один рабочий человеко-день составляет 8 часов. В самом деле, при таком размере команды время на согласование каких-то вопросов не будет слишком значительным.
Однако если в команде уже 4 человека, то следует учитывать как время на коммуникацию, так и разную производительность труда разных людей.
При оценке имеющихся ресурсов мы используем такую таблицу производительности труда:
| Работник | Производительность |
| Ведущий инженер | 50% |
| Инженер | 85% |
| Новичок | 50% |
| Неопытный новичок | 25% |
Ведущий инженер, помимо программирования, тратит часть своего времени на планирование, распределение задач, общение с Заказчиками, введение в курс дела новеньких, если такие есть, и на обучение неопытных. Поэтому мы считаем, что он может тратить на программирование лишь половину своего времени.
Обычный инженер должен работать с 85-ю процентной производительностью. Остальные 15% своего времени он тратит на коммуникацию с остальными членами команды, общение с Заказчиками и написание отчетов.
Как известно, подключение к проекту новых людей поначалу не ускоряет, а замедляет разработку. Это связано с тем, что члены команды вынуждены отвлекаться от работы на обучение нового сотрудника. Да и у самого новичка производительность труда в первое время невелика: мы считаем, что он тратит на обучение до половины своего рабочего времени. Со временем производительность должна расти. Если она не растет, то это повод задуматься о целесообразности его пребывания в команде.
Неопытный новичок поначалу вынужден тратить на обучение больше времени, чем просто новичок. Поэтому производительность в 25% в самом начале не должна выглядеть чем-то страшным. Однако со временем она тоже должна расти.
Используя эти цифры, можно оценить реальную производительность труда всей команды.
Предположим, команда состоит из 4-х человек:
- ведущий инженер;
- инженер;
- новичок;
- неопытный новичок
Тогда производительность всей команды будет равна:
1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2,1 человеко-дня
Это в два раза меньше, чем при простом подходе, когда считается, что каждый человек работает со 100-процентной производительностью.
Шаг 2.2.3. Запланировать майлстоуны
При планировании нужно распределить всю работу по нескольким этапам. Каждый этап заканчивается майлстоуном. Майлстоун — это некоторая точка во времени, когда оцениваются результаты проделанной работы.
При планировании майлстоунов необходимо решить две задачи. Во-первых, нужно распределить пользовательские требования по майлстоунам. Во-вторых, необходимо оценить длительность каждого майлстоуна. При этом, важно добиться, чтобы длительность майлстоунов была примерно одинаковая.
Для распределения работ по майлстоунам мы используем несколько критериев:
- Тема
Каждый майлстоун должен быть посвящен определенной теме. Это позволяет команде сконцентрироваться на чем-то определенном и избежать разбросов и метаний.
Примеры тем: модель данных, панели инструментов, окно редактирования графа и т.п.
- Зависимость
Необходимо учитывать зависимости между работами. Необходимо распределить работы таким образом, чтобы зависимые работы располагались бы позже тех работ, от результатов выполнения которых они зависят.
- Длительность
Необходимо выдержать примерно одинаковую длительность всех майлстоунов. Мы стараемся добиться того, чтобы длительность каждого майлстоуна составляла 5-6 недель.
Шаг 2.3. Составить план коммуникаций
Чтобы работа над проектом продвигалась успешно, необходимо подумать о том, как будет строиться общение внутри команды между отдельными разработчиками, а также между командой и Заказчиками.
Мы у себя в компании используем несколько практик, которые оказались — в нашем случае! — весьма успешными.
Пространство проекта в “облаке”
При старте нового проекта мы создаем пространство проекта в “облаке”. В качестве облачного хранилища мы используем Google Drive. Но можно использовать и другие сервисы: Яндекс Диск, Mail.Ru, One Drive от компании Microsoft и другие.
Если требования конфиденциальности или просто личные предпочтения не позволяют использовать облачный сервис, то можно установить Sharepoint на локальном сервере, или использовать систему контроля версий типа svn, git или perforce, или завести папку проекта на обычном файловом сервере. Вариантов — от простых до экзотических — масса.
Единое пространство проекта позволяет сконцентрировать все документы, относящиеся к проекту, в одном месте. А использование “облака” позволяет открыть доступ к ним всем членам команды: каждому — со своего рабочего места.
Что представляет собой пространство проекта? Это обычная папка в облачном хранилище, к которой настроены права доступа. Внутри себя она содержит другие папки, каждая из которых концентрирует в себе документы, относящиеся к определенной дисциплине.
Например, в нашем случае папка проекта обычно содержит в себе 4 такие подпапки:
- Концепция
Содержит документы, описывающие требования Заказчиков и дизайн разрабатываемого приложения.
- Технический проект
В эту папку помещаются документы, описывающие технический дизайн программы, диаграммы классов, имеющиеся технические ограничения и т.п.
- Управление проектом
Данная папка содержит все то, что относится к вопросам управления проектом: оценку проекта, состав команды, график проекта, график отпусков и т.д.
- Оценка качества
Сюда помещаются описания тест-кейсов, отчеты по результатам майлстоуна, правила по оформлению багов, перечень проблемных мест в программе, методики поиска багов.
Список контактов
Список контактов представляет собой документ, в котором содержатся имена всех людей, так или иначе связанных с проектом, а также — способы связаться с ними: телефоны, адреса электронной почты, аккаунты в скайпе и т.п.
Список контактов позволяет довольно быстро найти нужного человека. Менеджеры, пренебрегающие составлением подобного списка, потом напрасно тратят свое время и свои нервы, чтобы найти своего ведущего программиста, дизайнера или инженера по качеству в каком-нибудь экстренном случае.
Список контактов лучше всего оформлять в виде примерно такой таблицы:
| Ф.И.О. | Должность | Моб. Тел. | Skype | |
| Иванов П.И. | Ведущий программист | +7 (XXX) XXX-XX-XX | pivanov@company.com | pivanov |
| Петров И.С. | Программист | +7 (XXX) YYY-YY-YY | ipetrov@company.com | ipetrov |
Ежедневные совещания (стендапы)
Каждый день наша небольшая команда (4 программиста и 1 QA-инженер) собирается на короткое совещание, чтобы обсудить текущий ход работы над проектом. Обычно такое совещание занимает 10 — 15 минут и позволяет всем членам команды быть в курсе дел.
Формат совещания на протяжении длительного времени остается неизменным и состоит из трех частей:
- Общие объявления
- Отчет каждого члена команды
- Обсуждение проблем и предложений
В первой части менеджер проекта (или ведущий программист, выполняющий менеджерские функции) информирует команду о каких-то новостях, связанных с проектом. Это могут быть какие-то управленческие решения кураторов проекта, просьбы со стороны внутренних Заказчиков, положительные или отрицательные отзывы по разрабатываемому приложению или по работе команды.
Затем наступает черед отчетов. На этом этапе каждый член команды отчитывается о своей работе, отвечая на три следующих вопроса:
- Что я делал вчера?
- Что я собираюсь делать сегодня?
- Имеются ли у меня какие-либо препятствия, которые мешают мне выполнять текущие задачи?
Такой формат отчета позволяет менеджеру проекта (или ведущему инженеру, выполняющему часть менеджерских функций) быть в курсе того, как двигается проект и какого прогресса достигла команда. А поскольку каждый член команды должен рассказать о задаче, над которой работает в данный момент и назвать имеющиеся проблемы, то это помогает другим членам команды вовремя узнавать о зависимостях между своей задачей и задачей своего коллеги и, при необходимости, эти зависимости разрулить, скорректировав свои действия.
Еще один плюс публичных отчетов заключается в том, что работа каждого члена команды оказывается на виду. Невозможно скрыть отсутствие результатов. Это является дополнительным стимулирующим фактором как для самого человека, который не сумел продвинуться по своей задаче, так и для команды: кто-то может дать подсказку или предложить взять часть работы по задаче на себя.
После отчетов наступает очередь обсуждений. Если имеются какие-либо проблемы, то они кратко обсуждаются и вырабатываются подходы к их решению.
Практика работы нашей команды подтвердила высокую полезность таких совещаний. А чтобы польза сохранялась и в дальнейшем, важно, чтобы совещания не перерастали в длительные и безрезультатные обсуждения всех имеющихся проблем.
“Обсуждение” в программе-коммуникаторе
Перед началом работы по проекту мы также создаем “обсуждение” в программе-коммуникаторе. Наша компания использует для этой цели slack. Но можно использовать и другие программы такие, как HipChat, skype и т.п.
Такое “обсуждение” (“разговор”, “группа” или “конференция”) позволяет состыковать команду с людьми, которые работают над проектом удаленно, например, с внутренними Заказчиками, которые могут находиться в другом офисе или даже в другой стране, или с некоторыми удаленными сотрудниками.
В нашей компании “обсуждение” в коммуникаторе активно используется как разработчиками, так и Заказчиками. Разработчики используют его для задания коротких вопросов к Заказчикам и для информирования их о новых возможностях выпущенной версии приложения. Заказчики оставляют в “обсуждении” свои отзывы и просьбы исправить какой-либо критичный баг, если это надо сделать срочно.
Этап 3. Разработка
Обзор
Процесс разработки состоит из последовательности майлстоунов. Каждый майлстоун заканчивается выпуском версии приложения, которая поддерживает запланированную функциональность. Последний майлстоун этапа разработки заканчивается выпуском альфа-версии.
Под альфа-версией понимается приложение, которым можно пользоваться, хотя оно и содержит баги.
Майлстоун
В течение каждого майлстоуна выполняются такие работы:
- Планирование работы
- занимает от 2-х человеко-дней до 1-ой человеко-недели
- выполняется ведущим программистом
- иногда требует интенсивного обсуждения с Заказчиком отдельных требований
- Разработка (занимает 4 — 5 недель)
- Исправление багов (занимает 1 неделю)
Задачи
Во время планирования майлстоуна работа, которую нужно сделать к окончанию майлстоуна, разбивается на задачи. Выполняется оценка задач, а сами задачи вносятся в систему контроля задач. В качестве такой системы мы используем JIRA, но это не имеет существенного значения. Вместо нее можно использовать любую другую систему контроля задач: от бесплатного Redmine до дорогущего DevTrack.
Все задачи условно можно подразделить на две категории, каждая из которых отражает определенный взгляд на планируемую работу. В нашем случае это:
- Пользовательские задачи
- Технические задачи
Пользовательские задачи
Пользовательские задачи определяются по конечному результату, который необходимо достичь. Этот результат хорошо виден конечному пользователю, и поэтому пользовательские задачи легко верифицируются QA-инженером: результат либо есть, либо его нет.
Примеры таких задач:
- Создать выпадающую панель для выбора текстуры
- Добавить форму для выбора цвета
Однако, наряду с преимуществами пользовательские задачи обладают и недостатками: их сложно оценить, они могут обладать циклическими зависимостями (например, для выполнения задачи Б необходимо сначала выполнить задачу А, а для выполнения задачи А, в свою очередь, необходимо выполнить задачу Б).
Пользовательские задачи можно разделить на две категории:
- Задачи, которые характеризуют некоторую наблюдаемую часть программы, например, отдельное окно, сложный элемент управления или какую-то сервисную функцию (например, экспорт документа в определенный формат).
- Задачи, которые задают критерии выполнения задач из первой категории.
Задачи-критерии — это своего рода пункты чек-листа. QA-инженер может пройтись по нему, условно поставить галочки (если пункты выполняются) и закрыть родительскую задачу, если все “галочки” проставлены.
Примечание: Следует отметить, что задачи-критерии оформляются в виде подзадач для задач первой категории.
Существуют 3 вида критериев:
- Критерии, которые описывают состав компонента (отдельной формы, отдельного контрола)
При формулировании таких критериев следует задавать себе вопросы:
- Из чего состоит компонент?
- Какие элементы включает?
- Критерии, которые характеризуют ключевые визуальные характеристики компонента
При формулировании таких критериев следует задавать вопросы:
- Какого цвета фон компонента?
- Какого цвета текст?
- Какой шрифт используется?
Примечание: Не следует перечислять все визуальные характеристики до мельчайших подробностей. Это слишком трудоемко да и не нужно. Внимание нужно уделять только ключевым характеристикам или только тем характеристикам, которые отличаются от стандартных.
Цель формулирования критериев — не создать детальное описание компонента в мельчайших подробностях, а обратить внимание QA-инженера на то, чтобы он не забыл проверить те или иные характеристики перед тем, как “закроет” задачу.
ПРИМЕР. Если цвет фона, цвет текста и шрифт окна не отличается от стандартных, то все эти проверки можно сформулировать в виде одной задачи:
Проверить, что цвет фона, цвет текста, гарнитура и размер шрифта совпадают с руководством.
- Критерии, которые описывают поведение
При формулировании таких критериев следует задаваться вопросами:
- Что элемент делает?
- Как он отреагирует на определенное воздействие пользователя?
- Что должен сделать пользователь, чтобы элемент повел себя определенным образом?
- Зависит ли поведение элемента от времени?
- Может ли пользователь то или иное действие отменить?
ПРИМЕРЫ:
- Как пользователь, я могу управлять отображением решетки при помощи нажатия на кнопку Grid
- Убедитесь в том, что список можно развернуть или свернуть, нажимая стрелку с левой стороны заголовка
Технические задачи
Технические задачи отражают взгляд программиста на работу, связанную с реализацией того или иного требования или той или иной группы требований. Они представляют собой элементы плана действий и выражаются в технических терминах или, по крайней мере, лексиконом программиста.
ПРИМЕРЫ технических задач:
- Разработать класс, который делает… или отвечает за…
- Написать функцию, которая…
- Улучшить алгоритм поиска...
Технические задачи легче оценить, а полученная оценка — более точна. Также из них можно сформировать поток работ, и легче учесть и разрулить зависимости между ними.
Тем не менее, они сложнее поддаются верификации. Часто результат выполнения технической задачи не виден конечному пользователю. Чтобы он был заметен, бывает необходимо выполнить серию технических задач.
Одновременное использование технических и пользовательских задач оправдано, когда команда состоит из более 6-ти человек. В этом случае, сроки и потраченное время оцениваются по техническим задачам, а результат — по пользовательским задачам. Однако такой подход требует выделенного на полную ставку менеджера, в обязанности которого входит распределение и технических, и пользовательских задач между членами команды и на установления соответствия между пользовательскими и техническими задачами.
В нашем случае команда не такая большая. Поэтому мы используем только пользовательские задачи, т.к. они легко могут быть проверены QA-инженером. Все технические тонкости и подходы к реализации мы обсуждаем на словах. Точно также мы разруливаем зависимости между различными пользовательскими задачами, если они есть.
Метки
При занесении задачи в JIRA мы маркируем ее метками. Метки позволяют настраивать различные фильтры, а также — собирать и анализировать статистику.
В качестве меток мы используем:
- Идентификатор майлстоуна
Он позволяет легко найти все задачи, относящиеся к тому или иному майлстоуну.
- Тип задачи
Это либо задача-особенность (по-английски — feature), либо критерий.
- Идентификатор компонента или части программы, к которой относится задача
Фильтрация по этому критерию впоследствии позволяет легко оценить трудоемкость той или иной части программы.
Ревью кода
Перед отправки написанного кода в общий репозиторий необходимо пройти процедуру ревью. Поначалу ревью кода делают более опытные разработчики. Но и новичков следует привлекать к ревью чужих изменений как можно раньше. Это позволит им ознакомиться с кодом приложения и лучше понять стиль, принятый в команде.
Наиболее распространенными ошибками, которые находятся во время процедуры ревью кода, являются такие:
- Ошибки из-за неаккуратности
Наиболее яркий пример — это инициализация составной переменной. В неаккуратно написанном коде инициализация такой переменной (или частей такой переменной) может быть разбросана по всему файлу. Правильно код инициализации все же сгруппировать. Ошибки из-за неаккуратности допустимы у новичков. Но они должны быстро искореняться. Желательно, чтобы новичок после пары-тройки ревью более таких ошибок не допускал.
- Ошибки по невнимательности
Наиболее распространенная ошибка — это забывание добавить только что созданный файл в change list. Такие ошибки допустимы, но должны встречаться крайне редко.
- Ошибки в названиях
Тут возможна целая гамма ошибок: название класса или функции не отражает его (или ее) сути, слишком длинное название, непонятное название и другие. Поначалу такие ошибки будут встречаться часто. Но с опытом их должно быть все меньше и меньше.
- Ошибки в распределении функций по модулям и классам
Наиболее характерное проявление такой ошибки — это когда небольшое изменение затрагивает сразу множество файлов. Новички учатся долго не совершать подобных ошибок. Тут нужна кропотливая и терпеливая работа со стороны опытных разработчиков и ведущего программиста.
Исправление багов
Тестирование приложения происходит параллельно с разработкой. Для этого в отделе имеется QA-инженер, который занимается только тестированием разрабатываемых инструментов.
Каждое утро QA-инженер забирает обновленный исходный код из системы контроля версий и самостоятельно собирает его. Это входит в его обязанности. Таким образом, QA-инженер всегда работает с обновленной версией и не просит программиста собрать очередной билд для него. Программист привлекается только в том случае, если во время сборки или во время запуска произошла какая-то ошибка.
По мере выполнения задач QA-инженер смотрит, как они выполнены. Если он находит какой-то баг, то сразу же заводит его в системе контроля багов. Наше правило — проводить все найденные баги через баг-трекер. Даже если баг обнаруживает программист, то не бросается его исправлять сразу, а просит QA-инженера его повторить и, если он воспроизведется, то завести его в системе контроля багов. Почему это важно?
Во-первых, потому что в лице QA-инженера появляется независимая сторона, которая сможет проконтролировать, что баг исправлен.
Во-вторых, потому что зарегистрированный в баг-трекере баг попадает в статистику, которую впоследствии можно анализировать на предмет наиболее распространенных ошибок или наиболее “бажных” подсистем.
При регистрации бага в системе контроля багов рекомендуется использовать метки. Наиболее важные из них:
- Идентификатор майлстоуна
- Идентификатор подсистемы программы, в которой проявляется баг
Такие метки позволяют проанализировать статистику по багам должным образом.
Сопровождение
Обзор
Процесс сопровождения, как и процесс разработки, состоит из последовательности майлстоунов. Каждый майлстоун заканчивается выпуском очередной версии программы. Только, в отличие от версий, выпускаемых на этапе разработки, версии приложения, поставляемые на этапе сопровождения, можно полноценно использовать в работе.
Условно процесс сопровождения можно представить последовательностью альфа-версий, которая заканчивается выпуском бета-версии, а затем — финальной версии.
Только в реальной жизни до выпуска окончательной версии дело никогда не доходит. Практика использования приложения вносит свои коррективы, и заказчики предъявляют к приложению все новые и новые требования, которые реализуются в ходе очередного майлстоуна. Возможно, в будущем мы подумаем над системой нумерации версий продукта, но пока этого не требуется.
Майлстоун
Длительность майлстоуна на этапе сопровождения обычно составляет 3-4 недели. Это меньше, чем средняя продолжительность майлстоуна во время этапа разработки. Объясняется это уменьшением количества задач, которые необходимо реализовать. Это понятно, т.к. основная функциональность была реализована во время разработки.
Задачи, которые выполняются в ходе этапа сопровождения, условно можно отнести к одному из двух видов:
- Устранение барьеров
- Расширение функциональности
Устранение барьеров
Одна из важных целей, которую мы преследуем на этапе сопровождения — это сделать инструмент чрезвычайно удобным в использовании. Чтобы достичь этой цели, мы стараемся устранить все препятствия, которые мешают нормальному использованию.
Как мы выявляем такие препятствия? Просто даем версию приложения заказчикам и просим поработать с ней в полевых условиях. По результатам работы спрашиваем:
- Что мешает?
- Что раздражает?
- Чего не хватает?
Полученные ответы анализируем и разрабатываем варианты решений, которые и устраняют проблемы.
Расширение функциональности
Опыт использования приложения в реальной деятельности позволяет приоритезировать еще не реализованные требования. Если, рассуждая абстрактно, в отрыве от реальной практики, заказчики склонны фантазировать или запрашивать features, которые они где-то подсмотрели, то при регулярной работе с приложением сразу становится понятно, чего не хватает прямо сейчас, а что — может и подождать.
Опыт реального использования приложения позволяет сформулировать новые требования и переоценить уже существующие.
Заключение
В статье рассматривается процесс разработки в отделе инструментария игровой студии. Предложенный процесс применяется уже на протяжении двух лет. Он помог существенно улучшить качество разрабатываемого инструментария. От “наколеночного” софта удалось перейти к разработке программ, имеющих профессиональный вид.
За указанное время отдел разработал 2 серьезных приложения: одно — для дизайнеров визуальных эффектов, а другое — для 3D-аниматоров. Первое приложение уже активно используется в разработке игры и снискало положительные отзывы со стороны пользователей. Оно также позволило отказаться от используемого ранее приложения третьей стороны и, таким образом, сэкономить деньги на оплату лицензии. Второе приложение было выпущено недавно и в настоящий момент активно внедряется в разработку игры.
За два года отдел вырос в 2 раза: от двух программистов и 1-го инженера по качеству, работавшего на проекте лишь время от времени, до 4-х программистов и 1-го инженера по качеству на полную ставку. При текущем процессе у отдела имеется потенциал роста до 6 — 7 программистов. При дальнейшем росте сверх этого количества разработчиков, вероятно, потребуются изменения в процессе, связанные с большей формализацией.
Автор благодарит своих друзей и коллег за помощь при подготовке статьи.
Поделиться с друзьями
Комментарии (4)
GooRoo
22.11.2016 13:38-2Слава богу, автор пилит тулзы, а не игру.
Небось для пробной реализации какой-то игровой идеи пришлось бы сначала составлять дополнение к диз.доку, писать спецификацию на фичу по ГОСТам, аппрувить в трёх разных отделах с обходным листом и треугольной печатью из седьмого кабинета и т.д.
Мы бы даже в первую часть ещё не поиграли.
rinatr
Когда ориджинал син 2 выйдет?
А, вообще интересно. Я вот каждую неделю отчет не могу научится писать, а тут — каждый день.
Destros
Вроде уже в декабре обещали
Askofen
В 2017 году.