среда, 3 августа 2016 г.

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

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


четверг, 30 июня 2016 г.

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

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

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

среда, 25 июня 2014 г.

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

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

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

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

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

воскресенье, 25 мая 2014 г.

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

Контекст

1.      Команда разработчиков работает над популярной видеоигрой.
2.       Предполагаемый тираж игры – свыше 10 миллионов копий.
3.       Размер команды – 100 человек.
4.       В разработке принимают участие команды из трёх стран.
5.       Разница во времени между командами достигает 12 часов.
6.       Сроки выпуска игры не сдвигаются ни на день.
7.       На проекте заняты специалисты разных – в том числе, творческих – специальностей: маркетологи, менеджеры, программисты, 3D моделлеры, аниматоры, художники, дизайнеры интерфейса и др.

Как координировать работу всех этих людей?

понедельник, 19 августа 2013 г.

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


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

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

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

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

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

пятница, 9 августа 2013 г.

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

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

Такой подход считаю в корне неверным. Планы и оценки делаются совсем для другой цели

четверг, 8 августа 2013 г.

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

В очередной раз на форуме RSDN.RU возник спор про гибкие методологии и, в частности, канбан. Некоторое время назад я опубликовал статью "Халтура.Ру: Как халтурят отечественные ИТ-консультанты?".

Сегодня мне бы хотелось привести дополнительные аргументы.