Неофициальные Дневники Разработчика

Адреналин

2005-10-30T19:02:17Z

На прошлой неделе смотрели на одной отдельно взятой машине в оффисе в обед из-за спины.
Wow-эффект - в полной мере. Eye candy - в полной мере.
За комментаторов - респект огромный.
Короче эффект "взгляда из-за спины" присутствует. Поиграть хочется.
Смотрел на выходных дома - комментаторы надоедают быстро,
хоть и километры текста. Играть на нормале интересно, хотя и сложновато, а понижать сложность не хочется.
Стал ездить с компьютером включенным, с нитрой и "Z". Зато адреналин не кончается...
Все очень, очень круто.
Гайдзины постарались на совесть. Должны стать богатыми и сами ездить на крутых машинах скоро.
Еще огромный респект 1С за продакт-плэйсмент. Тут он очень в тему.

P.S. Еще очень понравилась заставка Гайдзиновская, про улитку!

Планирование и реальность

2005-10-30T18:46:19Z

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

А теперь о коррективах, которые вносила реальность.

Сборка версии.

Сборка версии в нашей компании - мероприятие ежемесячное. Тут речь не идет о тех версиях,
которые по нескольку штук собираются ежедневно (build).
Я говорю о "стабильной версии" (stable build), которая отправляется продюсерам и другим умным людям для ознакомления с ходом работ по проекту и выработки Ценных Руководящих Указаний.
Чем она отличается от обычного билда?
Обычно в этой версии как можно меньше ошибок, и она не "падает" при попытках немного поиграть. Кроме того, в этой версии показывается не только работа программистов, но и работа арт-отдела, и гейм-дизайнеров.
Можно сказать, что это такое мини-демо, которое должно быть не стыдно показывать.
Чтобы собрать этакую демку, нам приходится за неделю до даты сборки прекращать вносить в общий код новые фичи (на локальной машине программист может далать фичу, но заливать в общий репозитарий он её не должен), и сосредатачивать усилия на дебаге и контенте. Почему прекращаем вносить новые фичи? Чтобы плодить меньше новых багов. Они и так появятся в процессе исправления старых, но хоть не в таком количестве.
А раз мы сосредотачиваем усилия на дебаге, то мы не можем нормально планировать никакие работы, т.к. не знаем чья бага выплывет в процессе тестирования и сколько займет времени её пофиксить. Соответственно на неделю о планировании забываем и ведем лишь учет багов.
Т.е. теперь мы знаем, что при планировании работ на месяц, надо сразу учесть эту фазу стабилизации версии и запланировать недельный дебаг. Если сборка стабильной версии у Вас реже чем раз в месяц, то и фаза стабилизации версии будет дольше.
НО! Настоящая засада поджидает нас, когда уже сделали стабильную версию. Нужно ВЕРНУТЬСЯ К ПЛАНИРОВАНИЮ РАБОТ.Этот процесс требует определенных усилий, т.к. работа в фазу дебага очень привлекательна для сотрудников скоростью реакции на запросы, и тем, что многое решается "на местах". Соответственно, она очень инерционна, и слабо контроллируема.

Оптимизация.
Одна из самых больших моих недавних ошибок была сделана тогда, когда я, посмотрев на очередной stable build, подумал:
"Игра стала очень сильно тормозить, сейчас мы недельку потратим на оптимизацию и выправим ситуацию. Добавлять фич пока не будем и через неделю у нас будет новый stable build который уже не будет тормозить."
За первую неделю мы оптимизировали ряд "узких мест", но достаточного прироста в скорости не получили. В эту же неделю были запущены несколько задач по оптимизации, которые должны были дать серьезный прирост в производительности. К сожалению, они были связаны со ЗНАЧИТЕЛЬНЫМ рефакторингом, и не были сделаны за неделю. Они растянулись на месяц. Месяц не добавлять фич в общий репозитарий нельзя, соответственно параллельно велась работа над запланированными на этот месяц фичами. Но все равно, планы сильно "поехали". И период стабилизации версии дался нам особенно тяжело.
Вывод, который я для себя сделал: "Нельзя недооценивать временнЫе затраты на оптимизацию. Оптимизация - это серьезно."

Стало полегче

2005-10-24T17:31:28Z

Сынуля подрастает, начинает спать больше. Режим приходит в норму.

Работа над проектом идет полным ходом.
Вот уже несколько месяцев мы пытаемся работать по схеме, описанной в предыдущих постах.

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

Ура!

2005-08-11T00:15:19Z

Сын! Родился!

Вылазка в город за Бригадой Е5

2005-08-07T15:02:18Z

Предпринял еще одну вылазку в город за Бригадой Е5 (третью, две первых оказались неудачными, игры в продаже еще не было).
Температура снаружи +40, солнце и легкий ветерок - гриль, с конвекцией.
Кондиционер в машине не роскошь, а средство выживания.
Благо на этот раз купить игру удалось. Буду ознакамливаться.

Предаюсь отдыху и размышлениям.

2005-08-07T11:09:01Z

Размышляю над цитатой:
"Кризис - это шанс".

Про ТМ.

2005-08-02T12:18:18Z

Знакомьтесь с третьей главой моих записок о планировании. В ней я попробую рассказать о программе TaskManager ( далее TM), используемой нами сейчас для тактического менеджмента работ на уровне исполнителей.

Немного истории.
Моё знакомство с TM началось с первого визита в Gaijin чуть более года назад. Я был в Москве в командировке и получил приглашение от Антона Юдинцева заглянуть к ним в гости. И вот там, в ходе обмена опытом и демонстрации друг-другу некоторых наработок, Антон показал мне прототип TM'а. Это была веб-надстройка над workbench, которая умела делать некоторые вкусные вещи. Так, например, уже тогда TM умел считать время проведенное каждым членом команды на работе и выдавать отчеты за неделю и месяц. Не отходя от компьютера, менеджер мог посмотреть, кто из сотрудников работает в данный момент, а кто уже ушел. Это было связано со свободным графиком посещения, принятым в Gaijin. Возможно, уже тогда TM умел делать еще что-то важное и полезное. Возможно, мне просто не все показали. Но тогда я счел эту программку полезной и крайне многообещающей. Тогда же мне пояснили, что в Gaijin собираются дорабатывать программу до уровня продукта и продавать её с поддержкой. Я же, в свою очередь, сказал что не прочь потестить этот продукт в своей фирме, готов даже платить за него деньги и взял с Антона обещание, держать меня в курсе. Периодически я интересовался у Aliot'а, как продвигается развитие ТМ, и зимой 2005го мне таки удалось заполучить эту программу. Причем купить её не получилось - отдали "так", со словами: "За деньги её поддерживать надо, а у нас сейчас ресурсов нет для этого...". Я, впрочем, пообещал заплатить при появлении такого интереса со стороны Gaijin.

Внедрение.
Из Москвы я привез TM на флэшке. Хочу напомнить, что TM - это сильно доработанный workbench с клиентской частью. Соответственно, пришлось настраивать сервер и устанавливать его туда практически "на ощупь", это ведь была внутренняя рабочая версия Gaijin. Только благодаря помощи Антона, нам все-таки удалось запустить TM. Мы установили каждому пользователю по клиенту, зарегистрировали их в базе данных и попробовали работать. Может быть нам все же удалось накосячить при установке TM, возможно мы просто взяли билд с багами, но с первого раза что-то у нас не заладилось. Клиент TM после подключения к серверу с периодом в пол-часа выдавал глубоко философский вопрос из систем-трея: "Are you working?". Уже на второй день эта надпись была распечатана и надолго поселилась на аквариуме. На третий день все убрали TM из автостарта.
Поняв, что самим ТМ нам не настроить, мы открыли Антону Юдинцеву доступ в соответствующие папки сервера. Через короткое время мы стали обладателями уже рабочей версии программы. На этот раз, я решил ставить эксперимент на отдельно взятом отделе. Отделе программистов. Оказалось, что с ТМ вполне можно работать, но оставался ряд неудобств и пожеланий. Мы собрали все пожелания и баги в один список (совсем небольшой, к слову сказать) и отправили в Gaijin. Буквально в тот же день пришел ответ что Aliot УЖЕ сделал 90% того, что было в этом списке. Оставшиеся 10% уже должны были работать, но почему-то не работали.
Через неделю у нас была доработанная версия, которую мы установили во всех отделах, и с которой работаем до сих пор и нарадоваться не можем. (Лиды точно радуются, а уж как я рад!)

Как работает ТМ.
На сервере располагается база данных ТМ с веб-оболочкой. В базе хранятся все задачи, там же их можно посмотреть и отфильтровать по исполнителям и статусам. Вначале в ТМ зарегистрирован только Администратор. Админ может регистрировать новых пользователей, создавать группы и проекты. Создав необходимые группы и проекты приступаем к регистрации пользователей. При регистрации пользователя, указывается к какой группе он относится (например "Программист"), обладает ли он менеджерскими правами и в каких проектах он участвует.

Главное удобство ТМ - его клиентская часть. При первом запуске клент вводит свой логи, пароль и путь к серверу (это делается всего один раз). Если пользователь не обладает менеджерскими правами, его клиентская часть позволяет ему видеть только его задачи. Ставить задачи через клиента он может тоже только себе. При приходе на работу и включении компьютера, ТМ подключается к серверу и появляется в систем-трее, после чего пользователю нужно сказать, что он действительно начал работать, открыв меню ТМ (меню вызывается при клике на иконку ТМ в трее) и нажав кнопку "Work!". Если этого не происходит, то ТМ периодически напоминает о себе словами "Are you working?". Окно ТМ организовано в виде таблицы с вложенными списками. Очень просто и удобно. Вызывается двойным щелчком по иконке ТМ.
Начав работать пользователь должен стартовать задачу (выбрав задачу и нажав "start"), если ни одна назначенная ему задача не активна (ТМ напоминает ему об этом). Просмотреть список задач можно в окошке ТМ, при этом новые задачи помечаются префиксом New! и выделяются цветом. При поступлении новых задач, на иконке ТМ начинает мигать жёлтенький конвертик. Чтобы прекратить этот эффект достаточно просто прочитать текст задачи. Краткий текст задачи можно прочитать во всплывающей подсказке прямо в окне ТМ. Для нормального просмотра нужно зайти на электронную страничку задачи, с помощью двойного щелчка по задаче в окне ТМ. Для активной задачи считается время её выполнения и сравнивается с прогнозируемым. Всегда можно посмотреть, сколько времени осталось на данную задачу, её прогнозируемое время и процент выполнения. Когда время на задачу заканчивается, появляется окно с вопросом, закончена ли задача, и если нет, то сколько времени планируется её доделывать. У каждой задачи есть крайний срок (Due Date). Он также отображается в окне ТМ. Когда крайний срок прошел, а задача еще не готова - задача помечается как просроченная (Expired). Можно передать задачу другому сотруднику. Для этого нужно открыть окно задачи. Выбрать из выпадающего списка нужного сотрудника. Написать в комментариях, почему и зачем передается задача и нажать "Submit". Вся информация о том, кто и когда создал задачу, сколько с ней работал, кому отдал и все комментарии сохраняются. Их можно посмотреть в веб-экране задачи.
Заканчивая рабочий день, пользователь нажимает кнопку "Leave." чтобы обозначить, что он уже не работает и время выполнения активной задачи перестает увеличиваться.

Менеджерам доступна бОльшая функциональность. Каждый менеджер может определить своих подчиненных, поставив галочку напротив каждого в графе "Watch User" в специальном веб-окне TM (доступном только для менеджеров). С этих пор менеджер в своем окне ТМ видит свех своих подчиненных, видит какая задача у них активна, какие просрочены, сколько времени осталось на выполнение. Руководствуясь недельным планом, менеджер ставит задачи. Для этого он вызывает веб-окно новой задачи для данного пользователя, заполняет наимениование и текст задачи, определяет её крайний срок и, по возможности согласовав с исполнителем, выставляет время на выполнение данной задачи. Задача возникает у исполнителя с префиксом "New!". Если пользователь сам ставит себе задачу, менеджер должен её одобрить (Approve), пока одобрение не получено, эта задача в ТМ окне менеджера будет выделяться ярко-красным цветом, привлекая внимание. Одновременно, ТМ сообщает менеджеру, если его подчиненный работает, но у него не активирована задача, если задачи у подчиненных отсутствуют, если есть не одобренные задачи. Выполненные задачи переходят в папочку "Done" в списке пользователя. После чего их нужно еще закрыть. Сделать это может менеджер, но не может исполнитель. В случае, если задача на самом деле не закончена, менеджер может открыть её снова (Reopen).
Если пользователь работает, то в окне ТМ его менеджера к имени этого пользователя приписывается постфикс @Work.
Менеджеру доступна возможность создавать отчеты о пользователях. В отчеты записывается вся статистика пользователя за отчетный период, количество задач с опережением, с опозданием, время проведенное на работе, считаются коэффициенты запаздывания/опережения для данного сотрудника.

Что еще ТМ умеет.
ТМ умеет работать со вложенными задачами. Т.е. есть возможность прямо там задавать подзадачи и выполнять уже их (почти как в MsProject).
Можно посмотреть свои данные по времени проведенному на работе (во сколько пришел тогда-то, во сколько ушел, сколько часов отработал в итоге за день) за определенный период. Менеджеры могут посмотреть эти данные одновременно по всем своим подчиненным.
Если пользователь на протяжении долгого времени не проявляет активности (не двигает мышкой, не нажимает кнопки), пользователю ставится статус "away" как в аське, и сообщается, как долго "away 20 min". При продолжительном периоде отсутствия активности away автоматически переходит в статус "не работает" (Leave), и время в статусе away тоже определяется как не рабочее. Таким образом, даже если пользователь забыл уходя нажать "Leave", и при этом не выключил компьютер. Большой погрешности в отчетности не случится.
Одного пользователя может "наблюдать" несколько менеджеров.
У менеджеров могут быть тоже менеджеры.
Есть поддержка внутренней электронной почты.

P.S.
Возможно я рассказал не обо всем, что умеет ТМ, но основные вещи, которыми мы пользуемся постоянно я упомянул.
Этот текст написан не как реклама ТМ, но мне хочется поблагодарить Gaijin за создание очень полезного для нашей индустрии продукта. Я не знаю, когда ТМ поступит в продажу и поступит ли. Но я советую всем менеджерам присмотреться к этому удобному и полезному инструменту распределения и отслеживания хода выполнения задач. Нам он очень облегчил жизнь.

P.P.S.
Только что пришло обновление ТМ. Говорят, он теперь умеет импортить таски из MsProject и интерфейс у него стал более удобным.

Написал.

2005-08-01T20:19:02Z

Текст готов.
Днем отредактирую, вставлю картинки и выложу.
А сейчас пойду спать.

Пишу про ТМ.

2005-08-01T18:28:09Z

Начало тяжело шло. Решил выйти в интернет, отвлечься, почитать что-нибудь. Только компьютер к интернету подключился, как писать стало значительно легче. Даже страничку никакую загрузить не успел. Может это как-то связано? Мистическим образом?

Da green - Da best! Waaaaarh!

2005-07-31T06:19:10Z

Вчера впервые нормально поиграл своими орчатами. Трёхсторонняя драка, мои орки, некроны и имперские гвардейцы (armoured fist - василиск, два танка, химера и пехтура). Всего на 750 поинтов.
Сыграли вничью. В конце игры в нужной зоне у каждого было по скоринг юниту. Особо отличились Warboss и Lobba.
Ворбосс взорвал некроновский монолит и имперский Леман-Расс, сжег из скорчи один имперский отрядик. А лобба настреляла некронов больше любого другого юнита.
Начало последнего хода. В зоне у меня вместо скоринг юнитов - сломанный Looted Leman Russ и два полудохлых отряда орчат, по 30% в отряде. Гретчин чинит танк. +1 скоринг юнит. Орки делают mob up и объединяются - второй скорин юнит. Da green - Da best! Waaaaarh!
(после этого некроны постреляли орчат, но танк ни они, ни имперцы окончательно сломать не смогли - ничья!)

Эх, молодость...

2005-07-28T10:25:18Z

Вчера наткнулся в интернете на веб-архив, который хранит "копии" старых страниц интернета с 1996го года, по-моему.
Удалось восстановить текстик, который я считал безвозвратно потеряным. Вот такой привет из прошлого получился:
http://www.ino-co.com/skelos/old_text.htm

Вот блин!

2005-07-26T05:16:23Z

Вчера скачал несколько докладов с сайта КРИ, чтобы послушать их на сон грядущий,
записал их на КПК. Уже лёг, наушники надел, когда обнаружил что они OGG.
Пришлось так засыпать, без сказок на ночь.
Сегодня буду искать чем OGG на КПК проигрывается.

Красивое и редкое погодное явление

2005-07-25T18:42:18Z

Недавно взглянул в окно и ошалел слегка.
Радуга через все небо, от края - до края. В объектив не умещается.
А если присмотреться, то рядом с яркой радугой по краям вторая радуга проглядывает, менее яркая.
Считаю - это к удаче.

Как я пришел к текущей системе планирования и что перепробовал.

2005-07-25T18:19:05Z

Продолжаю тему планирования и поддержки планов. Хочу поделиться своим опытом.

Первый опыт.
Все началось во время работы над проектом "Звездные Волки".
Т.е. меня конечно учили построению сетевых графиков в институте, но серьезно планировать работу нескольких человек на длительный срок я начал только в середине работ над нашим первым большим тайтлом.
Предшествующий период характеризовался как препродакшен, создание команды и организация рабочего процесса.
Нас было немного (около 10 человек) и действовала система "звезда", когда я лично каждому работнику ставил задания.
Тогда мною создавался план до конца проекта (причем для всех работников), который я потом пытался поддерживать.
Задачи бились так чтобы быть менее недели. Этот план ежедневно обновлялся. Это даже работало некоторое время, но вскоре я заметил,
что часа в день на обновление плана уже недостаточно. В плане появились своеобразные "бесконечные задачи" - например "облет препятствий" который делался
очень долго и так и не был совсем избавлен от ошибок в вышедшем проекте. В план постоянно добавлялись новые задачи, менялась последовательность задач, менялись исполнители, и конечно увеличивались сроки. Огромной гирей висели уже выполненные задачи, их уже было больше чем невыполненных но запланированных. Кинутые на конец проекта, болтались нераспределенные задачи. Часто человек работал над какой-то большой задачей, потом прерывал её, чтобы сделать нечто на один-два дня, а затем возвращался к прерванной задаче. В итоге, после трех месяцев поддержки такого плана, разобраться в нем мог уже только я,а вот поддерживать его мне жутко не хотелось, т.к. я тогда был сильно перегружен работой по самому проекту, а каждое обновление плана занимало очень много времени... К тому же, количественно команда выросла до 15 человек. Заниматься планами, общением с издателем, работой над проектом (я писал диалоги для миссий из первых двух эпизодов) и одновременно управлять работой в стиле "звезды" я уже был не в состоянии, и я выделил отделы. Появились отдел программирования, художественный отдел и отдел гейм-дизайна. Были назначены менеджеры отделов и жизнь моя стала проще, я уже не ставил задач напрямую каждому человеку, но планирование все еще висело на мне.

Попытки что-то улучшить.
Тогда план был создан заново, опираясь на опыт и стараясь исправить недостатки присущие предыдущему плану я ввел цветовую идентификацию задач. Так красным цветом обозначались задачи, для которых временные риски были высокими (т.е. сроки выполнения весьма расплывчаты), а зеленым цветом я подкрашивал задачки необязательные к выполнению (фичи "на отрезание"). Бесконечные задачи я выделил в специальную папочку, сделал и папку для багов. Для более точного планирования, вместе с Лидом программистов мы пытались дробить задачи так, чтобы они занимали меньше дня. Исполнители, понятное дело, этому однако крайне сопротивлялись когда речь шла о задачах, над которыми они еще не думали (а таких было большинство). Тем не менее, информативность плана стала значительно выше. С ним первое время было даже удобнее работать (кроме того я избавился от груза уже выполненных задач)
Через месяц оказалось что, несмотря на все наши старания разработка идет совсем не так как мы предполагали, т.е. достоверность плана оказалась очень низка. Но хуже этого было то, что из-за высокой детализированности и насыщенности связями план стало очень дорого поддерживать. Мне казалось я все свое время провожу за планированием. Экран MsProject только иногда и ненадолго сменялся страничками dev.dtf.
На финальной стадии проекта стало совершенно очевидно, что нам нужна внутренняя программа для работы с ошибками и их документирования. Тогда мы нашли Workbench и приспособили его для своих нужд. Первое время московские тестеры присылали нам баги прямо туда, но вскоре перешли на TestTrakPro - с тех пор действовала следующая схема: я отслеживал базу данных ошибок TTP и удалял повторяющиеся, переносил оттуда ошибки в workbench и спускал на уровень Лида. Тот назначал исправлять ошибку конкретному исполнителю, затем цепочка разматывалась. Задача возвращалась Лиду, он удостоверялся в выполнении и возвращал задачу мне. Я закрывал её одновременно и в workbench и в TTP. Так получилось, что и для назначения простых задач из плана я стал использовать тот же технологический процесс. Но план я апдейтил все реже, и все дальше он был от действительности. В определенный момент мы перестали добавлять в игру новые фичи и занялись только чисткой багов....
Затем проект вышел.

Другой проект
Еще до выхода Волков мы начали разработку следующего проекта. К тому времени уже были вполне оформившиеся отделы, и соответственно план составлялся для каждого отдела несколько обособлено. Точнее, был один общий план разделенный на несколько частей - по отделам. Первоначальное планирование велось вместе, в дальнейшем поддержка планов ложилась на плечи Лидов. Опять мы сделали достаточно детальный план до конца проекта.Т.к. в команде уже была некоторая специализация у программистов, то задачи были достаточно легко разделены,но в следствии этой же спциализации, некоторые сотрудники получились крайне перегружены. На этот раз выделили риски вообще в отдельные задачи следующие за самими работами. Сохранили цветовую идентификацию. К тому же, учитывая просьбы продюсера, и для повышения информативности плана, были созданы вехи, на которые были завязаны определенные игровые этапы.
Вехи были вынесены в верхнюю часть плана. Продюсер просил также отталкиваться при постоении плана от того что нужно сделать для игры и не писать в план всяких задач со сложными техническими названиями. Но тогда мы еще не видели, как это можно сделать хорошо.
Очень скоро мы встретились со старыми проблемами "ниоткуда" возникающих задач, низкой достоверностью плана и трудоемкой поддержкой. Мы распечатывали месячный план и вешали его на стену, только чтобы убедиться что уже после второй недели все идет совсем не так. Лид просто не мог выделять на поддержку плана столько времени, сколько нужно.

Научный подход
Окончательно убедившись в ущербности того подхода к планированию, который реализовывался нами прежде, мы серьезно задумались о том, как сделать максимально ПРАВИЛЬНЫЙ план, чтобы его достоверность была высока, чтобы он был информативен и чтобы поддерживать его было несложно. И нам показалось, что мы придумали. Еще на текущем КРИ-2005 я был весь во власти идеи такого плана и горел желанием его реализовать.
Итак, в первую очередь мы решили, что большинство бед с недостоверностью планов из-за внезапно возникающих срочных задач. А возникают они от того, что нет четкого представления Всего что нужно для игрового проекта.
Поэтому, нужно отталкиваться от продукта и от фиче-листа. Сказано - сделано, мы обновили фиче - лист, т.е. практически переписали его с нуля, внеся туда все сущности которые видит или с которыми взаимодействует игрок в ходе игры.
Список получился внушительный. Список был классифицирован, туда были добавлены редакторы и на основе того, что получилось решили строить план (уже с уверенностью, что ничего не забыли). Этот список мы назвали "Игрой с точки зрения игрока". Его перенесли в MsProject. Там на его основе были построены еще два представления игры. Первое представление "Игра с точки зрения разработчика" состояла из модулей игры и их версий. Например модуль "Ладшафт -в.1 - сетка", "Ландшафт - в.2. базовая функциональность". Каждая версия состояла из ряда фич, входящих в этот модуль на основе фиче-листа. Все задачи были вехами с нулевой продолжительностью. Далее на основе этого представления, мы построили второй вид "Игра с точки зрения издателя". Мы решили, что раз мы сдаем версии игры, то мы можем просто составить версию игры из ряда модулей. Например "Игра в. 0,01" состояла из модулей "Интерфейс - в.1 - базовая реализация", "Ландшафт - в.2 - базовая реализация", "Вывод юнитов - в.2 - почти игровой вид" и т.д. Соответствующие вехи были связаны. Так, если я перемещал по времени какую-нибудь фичу в "Игре с точки зрения разработчика",
смещалась дата завершения соответствующего модуля, и соответственно смещалась дата завершения соответствующей версии игры. Кроме того, версии были достаточно нечеткими, т.к. при завершении очередной версии любого модуля, можно было собирать новую версию игры.
В нижней части плана был непосредственно... план, разделенный на отделы и распределенный по сотрудникам. Он получался следующим образом: в каждом модуле в "представлении разработчика" бралась каждая фича и разбивалась на коротенькие подзадачки, эти подзадачки распределялись по отделам и по людям, заносились в план и снабжались связями.
Смысл плана был в том, чтобы поддерживая план на уровне отделов мы в любой момен удобным образом могли посмотреть - когда будет какая-то фича, какой-то модуль, какая-то версия игры.

У нас получился огромный динозавр, обреченный на вымирание. Эта неповоротливая скотина настолько сильно сопротивлялась изменениям, что у меня уже через месяц опустились руки и я люто возненавидел планы с большим количеством взаимосвязанных задач.
Хотя до сих пор, тот план используется мною как отличное справочное пособие по содержанию игры.
Надежды на удобство поддержки - не оправдались по причине величины плана и огромномго количества связей.
Надежды на информативность - не оправдались, по причине глубокой вложенности и огромного размера.
Надежды на достоверность - не оправдались, задачи все еще возникают в ходе разработки "ниоткуда".
Сил было потрачено - уйма.

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

P.S.
В ближайшее время напишу про TaskManager, если санкцию от Гайдзинов получу.

Странные числовые совпадения.

2005-07-24T22:38:01Z

Только что зашел на форум dev.dtf и заметил вот такое совпадение:
группа dtf.dev.general - 9999 сообщений,
и одновременно dtf.dev.management - 6666 сообщений.
сделал скриншот.

Планирование в больших игровых проектах

2005-07-24T18:50:39Z

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

Для планирования использую MsProject.
Для отслеживания работ на местах и для постановки задач непосредственным исполнителям с удовольствием использую Workbench усовершенствованный Gaijin Ent. с их надстройкой TaskManager
(У команды за ним закрепилось название "Гайдзиновксий Троян" - но все сейчас им крайне довольны, чуть позже расскажу про него подробнее)

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

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

Сейчас я пытаюсь использовать схему планирования состоящую из нескольких планов, а именно:
стратегического плана - совсем маленький план, он состоит из списка месяцев, и из того, что мы в каждой конкретный месяц хотим такого глобального сделать, например "сентябрь - межмиссионный интерфейс, 1 эпизод, летающие юниты". Этот план позволяет руководствуясь здравым смыслом прикинуть сроки и расставить серьезные большие задачи в разумную последовательность. В нем учитываются и крайние сроки и обозначаются презентационные версии, например "апрель - сборка и шлифовка E3 демо". Этот план составляется PM'ом и согласовывается с продюсером.

тактического (месячного) плана - этот план состоит из задач для отдела программирования на текущий месяц - задачи могут быть большими как к примеру "игровая камера" и сроком на неделю-полторы. Этим задачам назначаются исполнители и выставляется простая последовательность. Строится этот план исходя из задач стратегического плана на этот месяц. Экспериментально пришел к тому что в таком плане оптимальное кол-во задач < 40 штук (Хорошо, когда их, к примеру,~ 30). Задачи объединяются в папки по смыслу "Игровая механика", "Графика", "Оптимизация" и т.д., что облегчает восприятие такого плана. Этот план составляется PM'ом вместе с Лидом программистов. Т.е. PM делает список задач, а Лид вместе с PM расставляет исполнителей и взаимосвязи, уточняет сроки на выполнение задач, порождает связанные с выполнением плана задачи для других отделов (например, очень часто для отдела гейм-дизайна появляется задача "задокументировать такую-то фичу для реализации").

локальньного (недельного) плана - очень подробный план, но всего на неделю. Из тактического плана берутся большие задачи/цели которые докомпозируются на мелкие задачки, (желательно с длинной не более одного рабочего дня) распределяются по исполнителям, назначаются сроки, расставляются взаимосвязи. Эту работу делает Лид уточняя сроки у непосредственных исполнителей. После окончания этой работы Лид уточняет тактический(месячный) план (вносит в него поправки).

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

Почему именно так? Какие плюсы и какие минусы?
Сейчас такая система кажется достаточно эффективной и необременительной,
т.е. имеет высокий КПД. К идее иметь три уровня планирвания я пришел постепенно сам (в след. главе поясню, как именно),
а вот идею разделения на несколько совсем отдельных планов, как мне кажется, позаимствовал у фирмы 1С,
хотя, возможно, я просто чего-то не понял. Т.е. я не берусь утверждать, что у них так все и планируют.
Теперь о плюсах и минусах.

Минусы

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

не производится подробное планирование до конца проекта - соответственно сложно оценивать реалистичность стратегического плана (опыт говорит, что реалистичность детального плана на большие периоды зачастую ниже, хотя может это только мы такие?)

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

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

для создания и поддержания плана требуется целых два человека

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

Плюсы

относительная легкость в создании - мало задач, мало связей

информативность - сами планы короткие, их можно охватить одним взглядом

!!!ПОДДЕРЖКА!!! - такие планы ГОРАЗДО проще поддерживать, тратится НАМНОГО меньше времени на таскание задач и переводы стрелок. (Это, в общем, главный плюс)

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

соблюдается иерархия и разделение задач при планировании и ведении плана.Мне кажется, что неправильно когда за план отвечает только ЛИД программистов. А когда за него отвечает только PM - так и подавно неправильно, ведь ему нужно минуя Лида апдейтить план и уточнять сроки у непосредственных исполнителей. Или делать это посредством Лида, что тоже неудобно.

текущий план может обновляться ежедневно! - это делает Лид, и на это он тратит мало времени. Одновременно PM всегда может оценить ход работ.

Пока все, если будет интересно, то в ближайшее время выложу следующие главы:

Как я к этому пришел и что перепробовал.
Подробнее о программе Task Manager. (Жду разрешения от Gaijin)

Первая запись - почти дисклэймер

2005-07-24T04:40:00Z

Привет.
Тут буду писать на разные интересующие меня темы.
Кое что будет и про разработку текущих двух тайтлов (пока неанонсированных), но не в основном.

Лазил по ЖЖ людей геймдева, нашел своего сотрудника, почитал... узнал много нового.