Проблема эллипса и окружности

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

Одной из проблем, которая порождает подобные дискуссии, является проблема эллипса и окружности. Её можно сформулировать так:

Как с точки зрения объектно-ориентированного подхода правильно объединить в единую иерархию два класса - класс Эллипс и класс Окружность:

Унаследовав Эллипс от Окружности?
Или унаследовав Окружность от Эллипса?

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

В эти выходные в Питере прошла конференция для разработчиков 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)     и т.д.

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

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

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

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

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

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

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

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

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

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

Пластический интерфейс

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

В одной из предыдущих заметок я поделился идеей пластического метода редактирования фигур. Его суть заключается в том, что пользователь изменяет форму фигуры не при помощи специальных манипуляторов, как это сделано сейчас в профессиональных графических редакторах, например, в CorelDraw, а при помощи пальцев, как будто лепит фигуру из пластилина. Более подробно об этой идее смотрите здесь.

А недавно мне попалась на глаза игра для iPad'а, в которой данный подход фактически реализован. Игра называется "Let's create! Pottery", она рассчитана на казуальную (преимущественно, женскую) аудиторию, и её смысл заключается в лепке горшков.

Более полробно смотрите здесь.

Как делать эстимейты? Часть 2

В этой заметке мне хотелось бы снова поднять тему эстимейтов.

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

Данный подход можно использовать двояко:

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

Во втором случае разработчик оценивает каждую пользовательскую функцию с учётом текущего дизайна системы, т.е. прикидывает, какие изменения потребует реализация отдельной пользовательской функции в различных частях программы, и оценивает трудозатраты по объёму этих изменений.

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

В прошлой заметке я приводил примеры эстимейтов, данных в "системе координат" пользователя. В этой же заметке мне бы хотелось привести пример оценки, сделанной в "системе координат" разработчика.

Как делать эстимейты?

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

В этой заметке я расскажу о нескольких подходах к созданию эстимейтов. Надеюсь, изложенная информация будет полезной.

Первый подход можно назвать "функциональной декомпозицией". Его суть заключается в том, что инженер "дробит" изначально большую задачу на ряд подзадач по функциональному основанию. Каждая из подзадач должна отвечать за выполнение некоторой полезной функции. Дробление следует осуществлять до тех пор, пока инженеру не станет понятно, сколько времени займёт реализация той или иной подзадачи.

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

В общем случае, хочется дать такие рекомендации: