О сроках разработки программ

В ванной капает кран. Кап-кап, выносит мозг. Сколько времени тебе потребуется, чтобы его починить? «Часик», прикинул ты? «А почему столько?» — спросит тебя владелец бизнеса (жена). Все, тупик, тебе ответить нечего. Хоть раньше ты и чинил краны, но ты только что дал необдуманную, исключительно интуитивную оценку, и теперь вынужден нести за нее ответственность.


© 2009 orkomedix | http://www.flickr.com/photos/orkomedix/4197641094/

«Как это так я дал необдуманную оценку? А сколько времени, по-твоему, нужно чинить кран?»

Читать дальше »

С удовольствием! Вылазь в скайп или gtalk - договоримся:)
Всё верно, но с небольшой оговоркой: адекватный estimate можно посчитать тогда, когда нет сомнений в том, каким путём следует решать задачу.
То-есть когда программист настолько не программист, что вынужден регулярно руками производить действия, которые нормальный программист после второго-третьего раза максимум переложил бы либо на машину, либо на непрограммиста. ;)
Основная проблема в том, что по-уму бОльшая часть программирования - это R&D, которые
а) производятся практически однократно (в последующем воспроизведение результатов занимает радикально меньше времени)
б) в силу очевидных причин непредсказуемы по срокам

Из этого есть парадоксальное следствие: предсказуемость процесса - признак плохого программирования. :)
Да верно подмечено, это с одной стороны делает работу интересной, что-то новенькое поковырять, но с другой стороны лежит неопределёный объём который может от этого ковыряния вывалится. Самый лучший вариант это когда проект содержит элементы предыдущего проекта, который был сделан в ковыряниях и на новом можно прооптимизировать наработки прошлого и получить удовольствие.
Я думал, ты расскажешь про cone of uncertainty
спасибо за пост. у меня эта проблема стоит остро в связи с написанием статей: сроки у нас размытые, но они есть, и часть руководителей имеют привычку жестко давить, чтобы статья кровь из носу была готова в сжатые сроки, при том что это не только техническая работа, а творческий процесс от формулирования идеи до написания внятного текста
Хорошая статья. Жаль менеджеры-не-бывшие-программисты все равно не поймут
(Anonymous)
я бы не был так категоричен, менеджеры-не-бывшие-программисты тоже люди, а если еще и адекватные, то понимают творческую натуру программистов и склоняются больше к прянику, чем к кнуту. Но опятьже, все зависит от человека.
++

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

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

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

И не забываем о статистике - как ни странно умножение общей оценки на коэффициент быстрее и точнее чем детальная декомпозиция и сумма.

P.S. Так что менеджер может помочь не только доставкой пиццы :)
Сколько времени не дай "от-до" - программист использует ВСЕ время, дашь больше использует еще больше.
Поэтому покер гейм :)

"А вот если его хорошо кормить…" мотивации нет, сколько не плати - эффект кратковременный
человек вообще объект нестабильный и автоматизировать его управление или выписать супер-пупер рецепт нельзя
"Радостный" человек может быть в любой момент времени по разным причинам, так же как и грустный или работать лень
"работать лень" - это нормальное явление для девелопера; мозг не может творить по заказу все рабочие дни напролет. Иногда не запускается. Надо погулять или забить.
(Anonymous)
а как оценить, сколько времени займет решение такой задачи?
(у опытного разработчика, и у человека, впервые узнавшего о существовании objective c?)
http://www.iphones.ru/forum/index.php?showtopic=86918
(взываю о помощи!)
Для проф. разработчика оптимистическая оценка: полчаса за чашкой пива. Пессимистическая оценка: придется помучаться несколько часов и разбить пару айфонов в ходе отладки. Возможный сценарий: вообще нереально сделать без фирменного кабеля, в котором, собственно, серийный порт и реализован.
(Anonymous)
ну отладка там хитрая: порт tty.iap открывается только если приложение запущено из папки /stash (кажется, так называется папка, где хранятся все приложения jailbreak). ну и потребуется нормальный разъем с нужными контактами, паяльник, и устройство для согласования уровней (если необходимо).
а почему возможен сценарий, что нереально сделать?
Ну, я просто не помню что там с серийным портом у айфона, вынесен ли он вообще на разъем. Может его там и нет. Не помню:)
(Anonymous)
вынесен, вынесен. не был бы вынесен - вопросов бы не возникало :-)
а сможете помочь? (на безвозмездной основе или за вознаграждение)
Увы, к сожалению, не возьмусь. Спросите @mishakarpenko в твиттере - возможно, он сможет помочь.
(Anonymous)
жаль. спасибо в любом случае!