tag:blogger.com,1999:blog-10303035.post5211642767206967775..comments2024-02-04T23:20:04.066+03:00Comments on Алёна C++: Временные оценки в программированииAlenahttp://www.blogger.com/profile/09389124127364799922noreply@blogger.comBlogger33125tag:blogger.com,1999:blog-10303035.post-54999883488393808572010-12-06T14:17:10.593+03:002010-12-06T14:17:10.593+03:00Мне очень нравится подход известный под названием ...Мне очень нравится подход известный под названием Earned Value Analysis http://en.wikipedia.org/wiki/Earned_value_management . Он предназначен не сколько для начального планирования, сколько для поддержания плана проекта в актальном состоянии. Пользовался этим подходом и в качестве разработчика и в качестве руководителя команды. Смысл подхода довольно прост - регулярные корректировки оценки времени оставшейся до выполнения задачи. MS Project неплохо поддерживает эту тухнологию через Basilines и Actual Work values. <br />Полностью согласен с мнением что для хорошего менеджера важны не сколько точные комитменты, сколько понимание состояния проекта и опасных и потенциально опасных мест (ну да risks management). <br />А оценку сроков по задачам всегда делаю по Сколнски - разбиваю на мелкие задачи максимум на день и оцениваю их. Плюс буфер на задачи не попавшие в оценку. А потом откладываю оценку и смотрю на задачу с точки зрения практического смысла - сколько по макисмуму имеет смысл на нее потратить времени. Если потом сравнить оценки - получается интересный результат :-).Dragganhttps://www.blogger.com/profile/17723967297981786619noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-65284349295996615922010-11-29T07:50:47.156+03:002010-11-29T07:50:47.156+03:00Алёна, насколько это уместно здесь, вам решать. :-...Алёна, насколько это уместно здесь, вам решать. :-)<br /><br />Взгляд с другой стороны баррикад: http://dtf.ru/articles/read.php?id=4085Денисnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-62473870576496764002010-11-21T19:17:44.826+03:002010-11-21T19:17:44.826+03:00Сегодня делали по учебе расчеты, на основе объема ...Сегодня делали по учебе расчеты, на основе объема кода, для оценки времени разработки системы, которая состоит из кода на JAVA, немного C++ и HTML. Потом перевели это все через коэффициенты (JAVA = 6, C++ = 3.5, HTML = 30) в строки ассемблерного кода, поделили на производительность и получили и получили примерный срок 6-10 лет на 4-ых. Все перепроверили несколько раз. Как придумывают такие методологии?Anonymoushttps://www.blogger.com/profile/10789886794562081769noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-10971671094481842932010-11-19T12:18:41.414+03:002010-11-19T12:18:41.414+03:00greesha-ru пишет...
Пробовали на неподготовленной...<b>greesha-ru пишет...</b><br /><br /><i>Пробовали на неподготовленной команде из пяти человек...</i><br /><br />Спасибо за ответ. Планирования на несколько отрезков вперед неплохое решение, попробуем подумать как реализовать у нас.<br /><br />По поводу точности согласен, данный способ эстимации позволяет получить достаточно точную оценку. <br /><br />У нас основная проблема была с затратами на планирования. Команда в 10 человек работала 2-х недельными спринтами. Соответственно покерная игра была каждые две недели и занимала практически весь день, иногда полтора дня. Достаточно большой оверхед для команды :(. <br /><br />Вторая проблема была в неровности команды. Только 2-3 человека обладали достаточными знаниями в данной области, поэтому остальным приходилось долго обьяснять как, что и где будет работать.<br /><br />В результате мы отказались от покерной игры в чистом виды и выработали свой подход. Начиналось с того, что каждый получал примерный фронт работ и шел на свое рабочее место, дабы подумать как это реализовать. Потом огранизовывались небольшие митинги с каждым программером. Участники: лид, программер и еще 1-3 человека, которые реально могли помочь с решением задачи. Такой группой управлять проще, соответственно игра происходила быстрее и эффективнее. В конце, когда все проэстимировали свои задачи был общий митинг, на котором просто проходились по спринту, чтобы каждый мог знать чем занимаются коллеги и, если что, внести поправки.<br /><br />При таком подходе мы составляли спринт за 4-6 часов и при этом не вся команда отрывалась от работы.<br /><br />Все, больше сказать нечего :). Прошу извинить, если сильно ушел от основной темы.ForestManhttps://www.blogger.com/profile/01139998914608666149noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-59622709936158266312010-11-18T21:54:42.175+03:002010-11-18T21:54:42.175+03:00@ForestMan
Использовали в работе, но подходит тол...@ForestMan <br /><i>Использовали в работе, но подходит только если команда достаточно ровная, т.е. все равно круты. Также есть негативный опыт при работе с командой в 9 человек - составление спринта занимает очень много времени.<br />Интересно было бы узнать о вашем опыте использовании Planning Poker.</i><br /><br />Пробовали на неподготовленной команде из пяти человек. Один, правда, самоустранился (отказывался давать комментарии), но он и правда по делу ничего не мог сказать.<br /><br />Среди оставшихся выявились, как на подбор: пессимист, оптимист и реалист. В их спорах и рождалась истина в виде оценок, которые потом с высокой точностью подтвердились.<br /><br />Времени это занимало на первый взгляд немало, это правда. Но мы планировали проект вперёд сразу на несколько этапов (каждый по одному-два месяца). И потом оказалось, что день, потраченный на покер, на фоне выполненной работы - это совсем ничего.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-28723047410470461952010-11-18T09:30:21.945+03:002010-11-18T09:30:21.945+03:00Не совсем в тему, но в принципе - о том же:
http:/...Не совсем в тему, но в принципе - о том же:<br />http://www.computerra.ru/compunity/russ/32031/Alexhttps://www.blogger.com/profile/11631725129351855737noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-25878831396510378462010-11-17T21:20:44.328+03:002010-11-17T21:20:44.328+03:00Alena пишет...
Сколько у вас часов в дне, если не...<b>Alena пишет...</b><br /><br /><i>Сколько у вас часов в дне, если не секрет?<br />Тут выше было предположение о восьмичасовом дне. Я считала 4-6, в зависимости от задачи.</i><br /><br />Мы считаем что один день это 8 часов. Так проще оперировать данными. При этом в эстимацию закладывается время на раскрутку для программера, время на то, чтобы включится в работу. Лично я считаю, что активно программист работает только 5 часов.ForestManhttps://www.blogger.com/profile/01139998914608666149noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-11786809120081267972010-11-17T20:49:51.729+03:002010-11-17T20:49:51.729+03:00ForestMan
Спасибо за статью.
Пожалуйста :-)
В р...<b>ForestMan</b><br /><br /><i>Спасибо за статью.</i><br /><br />Пожалуйста :-)<br /><br /><i>В работе используем оценку только в часах, если нужно, то потом полученный результат переводиться в недели, месяцы, года.</i><br /><br />Сколько у вас часов в дне, если не секрет? <br />Тут выше было предположение о восьмичасовом дне. Я считала 4-6, в зависимости от задачи.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-60667668986378729112010-11-17T20:42:35.792+03:002010-11-17T20:42:35.792+03:00Спасибо за статью.
Небольшой комментарий из собст...Спасибо за статью. <br />Небольшой комментарий из собственной практики. <br /><br />В работе используем оценку только в часах, если нужно, то потом полученный результат переводиться в недели, месяцы, года. Для оценки задачи разбиваются на более мелкие и спускаются вниз по иерархии. <br /><br />Менеджер идет к лиду и рассказывает требования. Потом лид разбивает на более мелкие задачи и раздает людям, которые предположительно будут выполнять данную работу. Каждый оценивает свой фронт работ и лид сводит это в одну таблицу. Чтобы случайно чего-то не забыть, лид работает с каждым программером отдельно, а не просто копирует цифры.<br />Помимо вопроса, сколько времени займет фича от программиста требуется рассказать, что конкретно он сделает за этот срок. Т.е. будет ли это финальная версия фичи или нужна будет дополнительная отладка, будет ли фича работать на всех платформах или только на одной и т.д. Это позволяет определить насколько программист правильно понял задачу и не забыл ли он что-то при оценке.<br /><br />При таком подходе очень много ответственности ложится на лида. Но постепенно команда учится правильно оценивать свои возможности и не теряется боевой дух, поскольку люди видят, что их мнение не игнорируется. <br /><br /><b>greesha-ru пишет...</b><br /><i>Каждый раз удивляюсь, когда не обнаруживаю Planning Poker в списке методов оценки сроков.</i><br /><br />Использовали в работе, но подходит только если команда достаточно ровная, т.е. все равно круты. Также есть негативный опыт при работе с командой в 9 человек - составление спринта занимает очень много времени.<br />Интересно было бы узнать о вашем опыте использовании Planning Poker.<br /><br /><b>Alex Ott пишет...</b><br /><i>Опытные менеджеры/тим-лидеры знают, что программист излишне оптимистичен, поэтому его срок сначала умножается на 2, а потом еще добавляется константа :-)</i><br /><br />В таком случае решение принимаеся по каждому конкретному человеку отдельно, и при этом с ним ведется работа по улучшению его абилок в оценке.<br /><br /><b>Wot пишет...</b><br /><i>- там где могут быть проблемы - надо закладываться на troubleshooting. На птичьем это risk assessment </i><br /><br />При составлении плана мы обычно закладываем риск буфер, размер которого зависит от нашего понимания задачи. Также при этом составляет список наших предположений, т.е. мы сразу говорим, что в данный срок будет поставлена версия только с базовым функционалом, или же фича будет работать только на такой-то платформе. Константы и коэфициенты стараемся не использовать. Если это не устраивает менеджера или заказчика, то начинается торг. К сожалению на данном этапе от программеров не все зависит, но очень помогает если налажен хорошший контакт со своим проджект менеджером и вы выступаете одним фронтом.ForestManhttps://www.blogger.com/profile/01139998914608666149noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-4724069949901526062010-11-17T20:03:35.871+03:002010-11-17T20:03:35.871+03:00Тут уже писали про правило ПИ, я про него не слыша...Тут уже писали про правило ПИ, я про него не слышал. Со временем у меня этот коэффициент получился равным 2,3. При условии что было дано время оценить задачу и прикинуть что к чему.<br />Я кстати склоняюсь к версии того что проблема возникает из-за того что неделя считается, например, 40 часовой, хотя реально никто не работает(трудится над конкретной задачей) по 8 часов в день (в среднем). Все же и блоги читают и тематику и башорг в конце-концов.Alexander Yastrebovhttps://www.blogger.com/profile/07659751891233705468noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-33956516327338110952010-11-17T11:11:07.078+03:002010-11-17T11:11:07.078+03:00@Alena:
>Я написала пост о том, как одному про...@Alena:<br /><br /><i>>Я написала пост о том, как одному программисту оценить срок выполнения выданной ему задачи.</i><br /><br />Прошу прощения, это уже "Остапа понесло". Флеймить прекращаю.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-5125423483181822332010-11-17T11:07:57.169+03:002010-11-17T11:07:57.169+03:00Евгений Охотников
В заказном ПО распространены сл...<b>Евгений Охотников</b><br /><br /><i>В заказном ПО распространены случаи, когда от разработчика требуют указать срок выполнения многомесячного проекта сразу. </i><br /><br />Я написала пост о том, как одному программисту оценить срок выполнения выданной ему задачи.<br />Как оценивать срок проекта целиком, куда входит далеко не только программирование - это отдельная большая история.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-90373735588036170002010-11-17T11:01:25.796+03:002010-11-17T11:01:25.796+03:00@Alena:
>Многомесячные работы надо разбивать н...@Alena:<br /><br /><i>>Многомесячные работы надо разбивать на этапы. Хотя бы для того, чтобы тестирование провести.</i><br /><br />В заказном ПО распространены случаи, когда от разработчика требуют указать срок выполнения многомесячного проекта сразу. Мол, что мы можем обещать вот этому заказчику, а хочет он вот это, это и это? А потом бах, и фиксируют оценку разработчика как срок выполнения и запуска проекта.<br /><br />Не говоря уже про случаи, когда сроки выполнения (где счет идет в диапазонах 6-12 месяцев) определяется не техническими, а политическими соображениями.<br /><br />Ну и совсем уж тяжелые случаи -- когда ПО должно быть готово к определенной совсем далекими от разработки людьми дате (смене законодательства, запуска нового аэропорта и т.д.) Взять хотя бы печально известную систему <a href="http://ru.wikipedia.org/wiki/%D0%95%D0%93%D0%90%D0%98%D0%A1" rel="nofollow">ЕГАИС</a>.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-27990077179859374522010-11-17T10:47:09.185+03:002010-11-17T10:47:09.185+03:00Евгений Охотников
И хороший менеджер далеко не по...<b>Евгений Охотников</b><br /><br /><i>И хороший менеджер далеко не последнее обстоятельство :)</i><br /><br />Безусловно. Я об этом вначале написала. <br /><br /><i>Я хотел спросить: когда вы говорите о положительном опыте предсказания сроков, то о каких объемах задач и сроках идет речь? </i><br /><br />В описанном посте случае было то ли две, то ли три недели. <br /><br /><i>Скажем, это задачи на неделю работы, на месяц, три месяца, полгода или больше?</i><br /><br />В основном делала оценки на недели. Самое большое, что я сейчас вспомню - 3 месяца.<br /><br />Многомесячные работы надо разбивать на этапы. Хотя бы для того, чтобы тестирование провести.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-85217581667769698362010-11-17T10:21:07.184+03:002010-11-17T10:21:07.184+03:00@Alena:
>Это статья про то, почему "невоз...@Alena:<br /><br /><i>>Это статья про то, почему "невозможно".</i><br /><br />Да. Я просто хотел подчеркнуть, что причина "Ты же крут! Какие три недели! За две справишься!" далеко не самая определяющая и, с возрастом, она играет все меньшую и меньшую роль.<br /><br /><i>>Сложно, да. Достигается тренировками. Но не невозможно.</i><br /><br />Есть у меня подозрение, что это достигается лишь при определенных стечениях обстоятельств. И хороший менеджер далеко не последнее обстоятельство :)<br /><br />Я хотел спросить: когда вы говорите о положительном опыте предсказания сроков, то о каких объемах задач и сроках идет речь? Скажем, это задачи на неделю работы, на месяц, три месяца, полгода или больше?eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-82138282402409596272010-11-17T04:27:40.398+03:002010-11-17T04:27:40.398+03:00Возможно, я видела как люди с этим работают. Сложн...<i>Возможно, я видела как люди с этим работают. Сложно, да. Достигается тренировками. Но не невозможно.</i><br /><br />Соглашусь. Оценка времени - это отдельный навык, так же тренируется, как и любой другой. Чаще оценивать задачи и перестанет бросать в дрожь, когда подходит менеджер :)<br /><br />P.S. У меня есть ощущение, что к статье "парой" подойдет пост http://gaperton.livejournal.com/50685.htmlYury Yurevichhttp://pyobject.runoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-22739890498283697292010-11-17T00:53:58.040+03:002010-11-17T00:53:58.040+03:00Евгений Охотников
Алёна, мне кажется, что причины...<b>Евгений Охотников</b><br /><br /><i>Алёна, мне кажется, что причины, по которым программист ошибается в сроках вы сильно упростили и, я бы сказал, выставили программистов в плохом свете. Если интересно, то я когда-то пытался проанализировать, почему же это происходит даже при искренем желании программиста назвать нормальные сроки.</i><br /><br />О, интересно, как-то я пропустила эту статью.<br />Свою позицию я уже озвучила. Это статья про то, почему "невозможно". Возможно, я видела как люди с этим работают. Сложно, да. Достигается тренировками. Но не невозможно.<br />Мое дело тут - предложить. Я не настаиваю. :-)<br /><br /><i>И я думаю, что программерский оптимизм неистребим. </i><br /><br />Очень разные все. Есть пессимисты.<br /><br />Основная моя идея, что сроки можно научиться оценивать лучше, если оценивать их не эмоционально, а сесть и расписать сколько куда чего уйдет. <br />Это как прикидывать вероятность. Ну не умеет человек ее угадывать. Зато можно сесть и подсчитать.<br /><br /><i>Поскольку порочная практика спросить срок один раз в самом начале, а потом строго ему следовать, похоже, неискоренима.</i><br /><br />Зависит от менеджера. Работала с пересмотром сроков. Работала с ситуациями, когда сроки пересмотреть было нельзя, резали фичи. Ну с упертыми товарищами тоже работала... Все разные.<br /><br /><b>Веталь</b><br /><br /><i>если не нравится - идите лесом</i><br /><br />вот это грамотный профессиональный подход :-)Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-59943143107948290702010-11-17T00:32:13.165+03:002010-11-17T00:32:13.165+03:00Формула проста - время, которое первое всплывает в...Формула проста - время, которое первое всплывает в голове умножить на три, там и на отладку хватит и на все остальное, если не нравится - идите лесом или урезайте ТЗ до базовой версии...pavlovhttps://www.blogger.com/profile/06657280514987170000noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-10452081988488587402010-11-16T21:27:52.266+03:002010-11-16T21:27:52.266+03:00Алёна, мне кажется, что причины, по которым програ...Алёна, мне кажется, что причины, по которым программист ошибается в сроках вы сильно упростили и, я бы сказал, выставили программистов в плохом свете. Если интересно, то я когда-то <a href="http://eao197.blogspot.com/2010/08/progthoughts.html" rel="nofollow">пытался проанализировать</a>, почему же это происходит даже при искренем желании программиста назвать нормальные сроки.<br /><br />И я думаю, что программерский оптимизм неистребим. Посему менеджерам ничего не остаётся, как продолжать использовать коэффиценты. А еще лучше -- использовать практику пересмотра сроков. Поскольку порочная практика спросить срок один раз в самом начале, а потом строго ему следовать, похоже, неискоренима.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-40351380252410435192010-11-16T18:06:46.659+03:002010-11-16T18:06:46.659+03:00Вот это как раз очень неправильно и про это пишет ...<i>Вот это как раз очень неправильно и про это пишет Спольски. Программисту самому сложно оценить сроки выполнения задачи, хотя он в нее полностью погружен. Браться оценивать срок за него - странная затея.</i><br /><br />я не говорил что программисту не надо, обязательно надо, я говорил что с менеджером(руководителем) должен общаться например руководитель программистов у которого опыта побольше в оценке времени и со стороны виднее сколько каждому необходимо надбавить или убавить времени.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-62408680850816242942010-11-16T17:28:15.187+03:002010-11-16T17:28:15.187+03:00Анонимный
мне кажется, в статье несколько путают ...<b>Анонимный</b><br /><br /><i>мне кажется, в статье несколько путают оценку задач с методологией разработки и оценкой проекта.</i><br /><br />Эммм... Разве? Я говорила именно об оценке времени выполнения конкретной задачи программистом.<br />Про проект целиком речь не идет. Проект - это несколько больше чем программирование.<br /><br /><i>есть еще один нюанс: при оценке проекта, над которым работает 5-10-... человек, не всегда есть возможность привлечь всех для оценки. зачастую в таком случае в оценке участвуют один-два программиста, а менеджер "делает поправку" т.к. представляет, кто будет выполнять задачи и какова средняя "производительность" разработчиков.</i><br /><br />В таком проекте будет иерархия. Один-два ведущих могут собрать оценки с остальных и свести их вместе. Я уже говорила выше, что считаю, что придумывание оценок за других программистов - это плохая идея. Производительность сильно зависит от задачи.<br /><br />Но в любом случае. Если такая система используется и работает - то это прекрасно.<br />Если она используется, но ее результатом является вывод, что программисты плохие, мало стараются и виноваты, то имеет смысл попробовать что-то еще.<br /><br /><b>Анонимный</b><br /><br /><i>http://ru.wikipedia.org/wiki/Мифический_человеко-месяц</i><br /><br />AFAIR, Брукс тут опять же говорит про оценки в проекте целиком, то есть о том, что происходит на уровне выше.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-60807406459937510022010-11-16T17:11:26.394+03:002010-11-16T17:11:26.394+03:00книга Фредерика Брукса
http://ru.wikipedia.org/wi...книга Фредерика Брукса<br /><br />http://ru.wikipedia.org/wiki/Мифический_человеко-месяцAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-10327900275921032322010-11-16T16:59:34.049+03:002010-11-16T16:59:34.049+03:00мне кажется, в статье несколько путают оценку зада...мне кажется, в статье несколько путают оценку задач с методологией разработки и оценкой проекта.<br /><br />да, разработчик должен сам оценивать задачи, которые он будет выполнять.<br />однако, разработчик зачастую не включает в оценку кроме названных code review,debugging, defect fixing такие вещи, как коммуникация, выяснение требований, техническая сложность решения, внешние и внутренние зависимости. набрасывать процент на оценку программиста в таких случаях крайне необходимо. и сделать это проще менеджеру, у которого есть статистика по выполненным ранее задачам.<br /><br />есть еще один нюанс: при оценке проекта, над которым работает 5-10-... человек, не всегда есть возможность привлечь всех для оценки. зачастую в таком случае в оценке участвуют один-два программиста, а менеджер "делает поправку" т.к. представляет, кто будет выполнять задачи и какова средняя "производительность" разработчиков.<br /><br />я являюсь искренним приверженцем planning poker (который отлично работает при итерационной разработке), хотя тут есть и свои ограничения в виде несогласованности несработавшейся команды, например, или нежелания заказчика получать оценку на кусочки, а не на весь проект в целом.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-68356358926724035602010-11-16T15:38:42.265+03:002010-11-16T15:38:42.265+03:00Alex Ott
ну это также зависит от менеджера - он д...<b>Alex Ott</b><br /><br /><i>ну это также зависит от менеджера - он должен видеть, когда человек черезчур оптимистичен или нет</i><br /><br />В таком случае имеет смысл побеседовать с человеком и рассказать ему как делаются временные оценки. <br />Не, я понимаю, что бывают совсем уж безнадежные случаи, но хотя бы попытаться стоит.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-156893064406566502010-11-16T15:31:12.942+03:002010-11-16T15:31:12.942+03:00ну это также зависит от менеджера - он должен виде...ну это также зависит от менеджера - он должен видеть, когда человек черезчур оптимистичен или нетAlex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.com