Проходя собеседование на должность руководителя разработки в некоторых компаниях, автору в ходе разговора приходилось выслушивать одну и ту же историю:
«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».
Странность ситуации заключается в том, что вроде бы умные и опытные руководители компаний задумываются об организации процесса разработки не в начале работы над проектом, а лишь только тогда, когда набранная команда терпит неудачу. Между тем, над процессом следует задумываться в самом начале.
В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.
За два года отдел вырос в 2 раза: от двух программистов и 1-го инженера по качеству, работавшего на проекте лишь время от времени, до 4-х программистов и 1-го инженера по качеству на полную ставку. При текущем процессе у отдела имеется потенциал роста до 6 — 7 программистов. При дальнейшем росте сверх этого количества разработчиков, вероятно, потребуются изменения в процессе, связанные с большей формализацией.
Дальнейшие перспективы — расширение отдела до отдельного бизнеса, производящего инструменты для разработчиков игр.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios. КЛ>https://habrahabr.ru/post/315514/
хрена там бюрократии на 5 человек.
а как вытаскиваются требования из заказчиков?
а есть ли промежуточные демо/билды, по которым меняются планы? а то 4-5 недель — это дофига. зачем так много вообще?
а что, "табличка производительности" работает? где я это видел, там были промахи по оценкам.
а как происходит поддержка с учётом идущего этапа? ведь выделенного человека на это нет, значит, нужно как-то искать время. а в планировании об этом не сказано.
что за система контроля версий? есть ли отдельные ветки для разных релизов?
Предложенный процесс применяется уже на протяжении двух лет. Он помог существенно улучшить качество разрабатываемого инструментария.
имхо просто набрались опыта на задачах. тем более, если первые два-три человека работали все эти 2 года.
...coding for chaos...
Re[2]: Процесс разработки в отделе инструментария в игровой студии
Здравствуйте, neFormal, Вы писали:
F>а как вытаскиваются требования из заказчиков?
Используем несколько методов:
1. Заказчики сами составляют концепт-документ. (В нашем случае это прекрасно работает.)
2. Предлагаем варианты решения и спрашиваем, какой лучше.
3. Изучаем аналоги.
F>а есть ли промежуточные демо/билды, по которым меняются планы? а то 4-5 недель — это дофига. зачем так много вообще?
Не понимаю, зачем делать билды чаще. На этапе "разработка" приложение только разрабатывается. И после первого майлстоуна, и после второго майлстоуна — им всё равно невозможно нормально пользоваться. Что-то осмысленное возможно сделать только с использованием альфы-версии. А до этого, просим Заказчиков посмотреть интерфейс отдельных элементов, посылаем скриншоты и видео. Нет смысла дергать Заказчиков чаще, чем раз в майлстоун.
F>а что, "табличка производительности" работает? где я это видел, там были промахи по оценкам.
У нас были промахи по оценкам, но за 2 года — 2 раза. В остальном, всё хорошо работает.
F>а как происходит поддержка с учётом идущего этапа? ведь выделенного человека на это нет, значит, нужно как-то искать время. а в планировании об этом не сказано. F>что за система контроля версий? есть ли отдельные ветки для разных релизов?
Сопровождение — это третий этап. На этапе сопровождения длительность майлстоуна может уменьшаться до 3-4 недель. Фичи отбираем заранее. Если есть что-то срочное (и не особо длительное) — включаем по ходу майлстоуна. Баги фиксятся в общем порядке. У нас всегда зарезервировано время на багфиксинг. Просто можем фиксить одни баги, а можем — другие (более срочные).
В качестве системы контроля версий используем perforce. Отдельные ветки есть. Но ими не злоупотребляем.
F>имхо просто набрались опыта на задачах. тем более, если первые два-три человека работали все эти 2 года.
У меня на этот счет другое мнение. Тем более, что люди в команде меняются. Кто-то уходит разрабатывать игру. Приходят и новички.
Здравствуйте, Кирилл Лебедев, Вы писали:
F>>а есть ли промежуточные демо/билды, по которым меняются планы? а то 4-5 недель — это дофига. зачем так много вообще? КЛ>Не понимаю, зачем делать билды чаще.
это не обязательно, но это можно делать.
профиты в ритмичности прогресса и возможности отчётности, а значит и возможности поменять ошибочные решения.
скриншоты и видео тут тоже вполне нормально выглядят.
КЛ>В качестве системы контроля версий используем perforce. Отдельные ветки есть. Но ими не злоупотребляем.
в одну ветку всё скидываете? или ветки для каждого разработчика?
...coding for chaos...
Re[4]: Процесс разработки в отделе инструментария в игровой студии
Здравствуйте, SkyDance, Вы писали:
SD>Другой вариант — заказчик сворачивает финансирование этой шарашки, разумно посчитав, что целый Лас-Вегас с блек-джеком им ни к чему.
Пока таких планов нет. Наоборот, внутренние заказчики довольны результатом.
