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

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

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

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

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

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

Контекст

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.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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

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

Это - последняя статья из серии про "Интерактивную Примерочную". В ней рассказывается о том, как сделать грубую оценку проекта на основе запланированных features. С предыдущими статьями вы можете ознакомиться по ссылкам:

Задание

Рынки

Целевые Группы

Ожидания

Концепция

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

Источники

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

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

В качестве зависимостей могут выступать: