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

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

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

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

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

Дальше

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

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

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

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

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

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

Контекст

1.      Команда разработчиков работает над популярной видеоигрой.

2.       Предполагаемый тираж игры – свыше 10 миллионов копий.

3.       Размер команды – 100 человек.

4.       В разработке принимают участие команды из трёх стран.

5.       Разница во времени между командами достигает 12 часов.

6.       Сроки выпуска игры не сдвигаются ни на день.

7.       На проекте заняты специалисты разных – в том числе, творческих – специальностей: маркетологи, менеджеры, программисты, 3D моделлеры, аниматоры, художники, дизайнеры интерфейса и др.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочитал статью Титова А.А. «Двадцать основных принципов, без которых нельзя обойтись при создании надёжного программного обеспечения». Появились такие выводы:

1.      Статья носит декларативный, а не процедурный характер.

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

3.      Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.

4.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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

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

У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:

1.      Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.

Вместо методик часто можно услышать и прочитать банальные советы в стиле: "сокращайте потери", "принимайте решения, как можно позже" и т.п. Некоторые из этих советов очевидны, некоторые – спорны. Но те и другие сформулированы настолько общё и настолько банальны, что под них можно подвести всё, что угодно (любую ситуацию, любой пример). И самое главное – они не дают инструмента для решения реальных проблем, которые встречаются на проекте.

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

В эти выходные в Питере прошла конференция для разработчиков CodeCamp 2011. Выступил на ней с докладом, в котором рассказал об основных этапах работы над продуктом (бизнес-приложением, видеоигрой). Фактически был изложен пошаговый алгоритм создания продукта, который включает в себя: маркетинг, дизайн и инженерное проектирование.

Выступление было составлено на базе моего 15-летнего опыта работы в ИТ-индустрии. Для тех, кому оно будет интересно, выложил презентацию:

Code Camp 2011 - Продуктовая копания: Постановка процесса разработки

View more presentations from Kirill Lebedev

УПРАВЛЕНИЕ.РУ и MANAGEMENT.COM

В чём различие западного и отечественного подходов к управлению программными проектами?

Критерий	Управление.ру	Management.com
Задачи	Глобальные, иногда -  грандиозные задачи, выполнение которых подчас требует слаженной работы нескольких специалистов в разных областях знаний. Время выполнения задачи измеряется неделями или даже месяцами. ПРИМЕР. В одной из компаний, занимающийся разработкой GPS-навигационных систем,  менеджер любил давать своим подчинённым глобальные задачи: 1)     разработать модуль роутинга; 2)     разработать модуль поиска координат по адресу; 3)     разработать красивый UI; 4)     и т.д.	Конкретные задачи, измеряемые часами или, в крайнем случае, днями. Любая глобальная и комплексная задача разбивается на серию конкретных подзадач с чёткой формулировкой. Устанавливается порядок их выполнения. ПРИМЕР. Комплексная задача "разработать модуль роутинга" разбивается на серию небольших подзадач: 1)     составить перечень алгоритмов поиска маршрутов и выбрать наиболее подходящий из них; 2)     ознакомиться с документацией по картам и составить список атрибутов, необходимых для корректной работы алгоритма; 3)     расписать интерфейс доступа к картографическим данным; 4)     спроектировать и реализовать структуру для хранения информации о дорожном элементе; 5)     спроектировать и реализовать структуру для хранения всех рассмотренных дорожных элементов; 6)     и т.д.

Проклятие аутсорсинга

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

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

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

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

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

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

Успешная технология разработки продукта организует работу всех этих людей, как единой системы.

Каждый специалист занимается своим делом. Технология предоставляет чёткие критерии качества работы для каждого специалиста.

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