Software Design

Архитектура клиентского приложения (механизмы структуризации)

noreply@blogger.com (Anonymous) — Fri, 19 May 2017 07:56:00 +0000

История первая

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

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

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

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

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

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

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

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

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

Далее

О “легком” процессе замолвите слово: процесс разработки в отделе инструментария Larian Studios

noreply@blogger.com (Anonymous) — Mon, 21 Nov 2016 08:04:00 +0000

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

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

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

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

Дальше

История семинаров и Мастер-классов

noreply@blogger.com (Anonymous) — Tue, 04 Oct 2016 19:48:00 +0000

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

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

Вторая проблема - умение решать творческие задачи - это лишь маленькая толика из того, что надо для того, чтобы разработать технически и технологически сложный продукт. Помимо творчества нужны еще и инженерные усилия. ТРИЗ никак не затрагивает этого аспекта. Более того, в своей книге "Найти идею" Генрих Саулович отвергает идею создать информационную систему для проектирования ювелирных изделий. С момента написания книги уже прошло ~35 лет. И мы можем сказать, что информационные системы, помогающие спроектировать техническую систему, получили широкое распространение (это разнообразные САПР), а вот экспертные системы, помогающие сделать изобретение, хоть и существуют, но, увы, не так широко. Реальная практика оказалась против прогноза. И помощь в конструировании (проектировании) оказалась важнее креатива.

Постановка процесса разработки в отделе инструментария игровой студии

noreply@blogger.com (Anonymous) — Tue, 02 Aug 2016 21:32:00 +0000

Выкладываю видеозапись моего выступления на IT Global Meetup, который проходил 23 июля 2016 года в Санкт-Петербурге. Тема выступления - процесс разработки, который мы используем.

Грубая оценка проекта

noreply@blogger.com (Anonymous) — Thu, 30 Jun 2016 08:11:00 +0000

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

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

Могу рекомендовать: online-лекции И.Л. Викентьева о творчестве

noreply@blogger.com (Anonymous) — Tue, 24 Jun 2014 20:33:00 +0000

По многочисленным просьбам иногородних Читателей интеллектуального портала VIKENT.RU, с осени-2014 начинаются бесплатные лекции И.Л. Викентьева о творческих личностях / коллективах.

Параметры online-лекций:

1) В основе лекций - крупнейшая в Европе база данных по технологиям творчества, содержащая уже около 50 000 материалов;

2) Данная база данных собиралась в течение 35 лет и легла в основу портала VIKENT.RU

Software Design

Архитектура клиентского приложения (механизмы структуризации)

История первая

О “легком” процессе замолвите слово: процесс разработки в отделе инструментария Larian Studios

История семинаров и Мастер-классов

Постановка процесса разработки в отделе инструментария игровой студии

Грубая оценка проекта

Могу рекомендовать: online-лекции И.Л. Викентьева о творчестве

Для чего нужны ежедневные отчёты?

Контекст

Распространённые мифы о классическом процессе разработки

Миф о точном планировании

Почему канбан НЕ поможет вам при ведении проекта?

Что нужно сделать при старте нового проекта?

Как сделать грубый estimate?

Грубая оценка

Как подготовить концепт-документ для продукта?

Проектирование интерактивной примерочной. Часть 2

Ожидания

Проектирование Интерактивной Примерочной. Часть 1

Халтура.Ру: Как "халтурят" отечественные ИТ-консультанты?

Как увеличить количество пользователей социальной сети? Продолжение.

Как увеличить количество пользователей социальной сети?

Архитектура ОС Singularity (отзыв на статью)

Пример проектирования: шифрующая папка на "рабочем столе"

Идеальный программист

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

Отзыв на книгу "Шаблоны интеграции корпоративных приложений"

Почему надо проектировать "от обязанностей", или сколько функций выполняет чашка?

О том, как путают функциональный подход к проектированию с процедурным программированием