понедельник, ноября 15, 2010

Временные оценки в программировании

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

Но мы не такие! Мы решаем проблемы, а не ищем виноватых. Мы ищем способ, а не причину. Мы не жалуемся на Злую Судьбу, Законы Вселенной и не вздыхаем обреченно "оно всегда так".

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

Итак, как обычно происходит оценка сроков? Вот очень распространенный сценарий. Программиста спрашивают "сколько времени этой займет?" Ответ ожидается прямо сейчас, у программиста есть несколько секунд на раздумья. У него в голове возникает некий срок. Пускай будет "три недели". При этом программист отбрасывает время, нужное для отладки, учитывается только время кодирования. Потом внутренний голос говорит ему "Ты же крут! Какие три недели! За две справишься!". "Две недели" - отвечает программист. После этого начинается торг. Менеджер пытается уменьшить уже сильно заниженный срок. В итоге они сторгуются на неделе. Это просто какой-то срок, взятый с потолка, который выполнен не будет.

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

Увы, я не знаю волшебных заклинаний и HOWTO как всегда со стопроцентным попаданием рассчитывать сроки. Но есть несколько известных мне приемов, которые ситуацию с оценкой сроков улучшают значительно. Я их все использовала, опробовала на себе. Все они требуют активного сотрудничества между менеджером и программистами. Если такого сотрудничества нет, попробуйте делать временные оценки для себя. Это полезный навык, может потом пригодиться.

Оценка времени программирования задач в часах
Этот способ рекламировал Джоэл Спольски у себя в блоге. Там вы найдете его подробную статью об этом: Evidence Based Scheduling. Разбиваем задачу на подзадачи, оцениваем время каждого этапа в часах.
Если вы привыкли брать сроки с потолка, то оценки по этому методу будут получаться пугающе большими. Это нормально.

Временные отсечения
У нас есть задача, требующая определенных исследований. Наши программисты ни разу такое не делали. И вообще не представляют как это делать. Мы начинаем исследование и бросаем его в определенный срок. Например, 20 мая. Если до этого времени не успели - все. Даже если "почти все готово", даже если "вот сейчас заработает". Откатываемся к предыдущей версии. Беремся за следующую задачу.

Разработка по спирали
Наверное, у этого способа есть какое-то умное название. Задача как можно быстрее получить работающую версию продукта. В случае игры - играбельная версия, один уровень, почти без графики, без спецэффектов, без меню или с убогим меню. А потом уже на нее навешиваем фичи. Добавляем спецэффекты. Делаем оптимизацию. Разработка получается гибкой. Мы на ранних этапах можем отказаться от каких-то фичей, от спецэффектов.

Предоставить другую информацию

Если программист не знает когда задача будет выполнена, то зачастую он может назвать срок, в который она точно выполнена не будет. Этого может оказаться достаточно менеджеру, чтобы принять какое-то решение. Например, перенести собрание или вовсе отказаться от выполнения этой задачи. Можно побеседовать и выяснить, что программист может предложить некое решение, которое можно сделать очень быстро, но оно будет обладать существенными недостатками. Например, не будет работать в некоторых случаях или будет работать очень медленно. Его можно будет использовать в качестве заглушки. Зачастую бывает лучше продемонстрировать медленно работающую программу, чем вообще ничего не продемонстрировать.

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




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




Для того, чтобы лучше понимать нужды менеджера полезно бывает что-нибудь отменеджить. Если вам предоставится такая возможность, то вы увидите, что важен не столько срок, сколько общий контроль над процессом. Пускай что-то пойдет медленнее, чем ожидалось, главное, что мы можем этим управлять, знаем причины, знаем как на это влиять. Главная цель - удержать контроль над ситуацией.

суббота, ноября 13, 2010

Интервью на OpenQuality.Ru

На OpenQuality.Ru сейчас публикуются интервью с программистами о разработке софта. Много спрашивают про обеспечение качества.

Пока там всего два интервью. Моё и Александра Дёмина, автора блога Программирование - это просто. У него там есть интересное про организацию работы в Блумберге.

OpenQuality.ru

пятница, ноября 12, 2010

Статьи про рендеринг в Старкрафт 2

"...вашему вниманию предлагается реверс инжиниринг рендера всем известной игры Старкрафт 2, от не менее известной компании Близзард."
Старкрафт 2: Секреты технологий
Старкрафт 2. Рендер роликов



via lightypp

вторник, ноября 09, 2010

Впечатления от работы с игровыми консолями

Меня тут в комментариях как-то просили рассказать о моих впечатлениях от работы с консолями, вот оно.

Пара слов о том, какие бывают игровые консоли. Есть те, которые надо подключать к телевизору, по-русски они обычно называются "приставки". Сейчас наиболее популярны три из них: Microsoft XBOX 360, Sony PS3, Nintendo Wii. Причем Wii всех рвет по продажам.

Есть консоли со своим собственным экраном, самые известные - Nintendo DS и Sony PSP.

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

Архитектура
Пришлось работать с довольно странной архитектурой, это непривычно. На консолях любят big endian. Что создает, хм, некоторые проблемы, если вам хочется двоичные данные с PC перенести на консоль. А вам этого захочется, потому что у вас все дизайнеры уровней сидят на PC.

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

В целом приходится сидеть сильно ближе к железу и вот здесь хорошо себя проявляет С++. Здесь вы можете и данные разложить как вам надо, и с полиморфным наследованием поработать.

Огромный плюс - консоли везде одинаковые. Например, у вас нет зоопарка видеокарт, как на PC, которые это поддерживают, это не поддерживают, а вот тут у нас драйвер устаревший... И это прекрасно.

Контроль качества
В играх под PC сложилась такая нехорошая практика - сразу после выхода игры выходит пачка патчей. Здесь с патчами все сложно. Либо их нет совсем, либо их довольно сложно и неудобно выпускать. При этом, если вы играли в игры на консолях, то, возможно, обращали внимание, крэш игры - это что из ряда вон выходящее. Да и вообще багов не видно.
Потому что тут существует Контроль Качества. Вам не удастся себя уговорить, что "и так сойдет" и "никто не заметит". По ту сторону вас ждет не пользователь, которому, в принципе, можно навешать лапши на уши, а платформодержатель. И стоит он насмерть.

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

Закрытость

Вы не можете задать вопрос в коммьюнити размером с целый мир. У вас есть закрытый форум или список рассылки, это вам не stackoverflow. Особого выбора библиотек тоже нет. Радуйтесь тому, что есть.


Ссылки по теме:
Про консоли
Updated 01.12.2010
Kill the Gatekeepers