Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - Кирилл Лебедев

Страницы: 1
1
История первая

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



Игровая компания немца разрабатывала 3 вида игр:

Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

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

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

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

На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.

На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.

Далее - https://habrahabr.ru/company/larian/blog/329032/

2
Проходя собеседование на должность руководителя разработки в некоторых компаниях, автору в ходе разговора приходилось выслушивать одну и ту же историю:

«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».

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

В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.

https://habrahabr.ru/post/315514/

3


Классический процесс разработки программного обеспечения делится на 3 этапа: pre-production, production и post-production.

На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.

Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.

На этапе post-production — исправляются остальные баги.

К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.


Миф 1. Если исправление багов отложить на этап post-production, в скором времени количество багов вырастет, как снежный ком, и проект станет плохо прогнозируемым и плохо управляемым.

Управляемость проектом не будет потеряна, потому что:

1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д. Этот прогноз используется в работе отделом QA и менеджментом проекта. Более того, он регулярно корректируется с использованием актуальных данных. Так что ни о какой "плохой прогнозируемости" и "плохой управляемости" не может быть и речи.

2. Во время production отдел QA находит далеко не все баги, а только их часть. В проектах, в которых я принимал участие, их количество составляет от 30 до 40 процентов от общего числа багов. Причина этого проста — основные силы QA подключаются незадолго до того, как все фичи будут реализованы. Подключать их ранее не имеет смысла, потому что фичи ещё не сделаны, и нечего тестировать. Кроме того, ещё не готовы тест-кейсы, т.к. фичи находятся в работе, и представление продюсеров о них может меняться. Во время production отсутствуют необходимые условия для подключения большой команды тестеров.

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

Дальше: http://askofen.blogspot.ru/2013/08/blog-post_19.html

4
Реклама тренинга

"Рынок электронных устройств насыщен до предела. Как производители создают новые устройства? Типовой приём - взять за основу известное устройство и увеличивать количество полезных функций (см.: функциональный подход). Сейчас уже трудно встретить в продаже "чистый" mp3-плеер. Современный плеер позволяет не только слушать музыку, но и просматривать фотографии, видео-клипы и Интернет-сайты. Но увеличение количества полезных функций не всегда приводит к хорошему результату. Почему?"

http://www.treko.ru/techno

Страницы: 1