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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

воскресенье, 7 июля 2013 г.

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

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

1.      Статья носит декларативный, а не процедурный характер.
2.      Сведения, изложенные в статье, известны и преподаются в любом вузе, обучающем специальности «программное обеспечение вычислительной техники и автоматизированных систем».
3.      Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.
4.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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

воскресенье, 20 января 2013 г.

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

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

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

воскресенье, 13 января 2013 г.

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


Прежде чем приступать к разработке продукта, необходимо сначала создать его концепцию. Концепцию продукта вырабатывает продюсер, а в случае сложного продукта — целый продюсерский отдел, который состоит из:
  1. линейного продюсера;
  2. креативного директора;
  3. арт-директора;
  4. дизайнера интерфейса;
  5. звукового дизайнера;
  6. и т.д.

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

Грубая оценка
Источники

пятница, 11 января 2013 г.

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

Задание
Концепция
Грубая оценка
Источники

Ожидания

После выявления целевых групп необходимо составить список их ожиданий. “NASA System Engineering Handbook” такой процесс называет stakeholder expectations definition. Ожидания можно выявить путём опросов представителей целевых групп, например, по следующей методике. Опросы должен проводить не руководитель отдела разработки, а маркетолог.
Для наших целевых групп были выявлены такие ожидания:

вторник, 8 января 2013 г.

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

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

Ожидания
Концепция
Грубая Оценка
Источники