Комментарии 62
Тема конечно старая и избитая, впрочем, вы хорошо заметили, что «опытным разработчикам и менеджерам в этих историях не удастся найти чего-то нового» и «Эти истории могут быть полезны начинающим программистам»
ЗЫ: поправьте пожалуйста
«может воскликнуть читать и будет не прав»
«полезны начинающим программистам, которые может быть даже и читатель книги» — как то режет слух
ЗЫ: поправьте пожалуйста
«может воскликнуть читать и будет не прав»
«полезны начинающим программистам, которые может быть даже и читатель книги» — как то режет слух
НЛО прилетело и опубликовало эту надпись здесь
На хабре вот было: программист и антивирус. Скорее, разработчики антивируса забьют.
А ещё непонимание заказчика (начальства), что они хочут очень сильно сроки срывает. Вот пример: программа элементарная — внутри себя содержит просто ярлычки на запуск отдельных приложений пакета и вроде обо всём было оговорено, но после быстрого создания программы, то это не нравится, то то подвинь, то это, то верни назад, то давай ещё вот тут, ой, плохо, давай назад, а вот можно… Короче элементарный проект максимум на 3 дня с параллельным просмотром порно через корпоративный канал и сидением на Хабре занял бы 3 дня, а в результате 2 недели нервов и 2 мегабайта (! — по моему для такой элементарщины и 500 Kb много) в релизе из-за оставления всего того мусора, на случай, если ещё в голову взбрендит…
С одной стороны согласен, а с другой откуда заказчику/начальнику знать, что они хотят? Я серьезно! Почему программист «имеет наглость» надеятся на то, что заказчик точно это знает? Заказчик же не марсианин с устройством анализа будущего. Это же очень сложно четко сформулировать ТЗ.
Проблема иногда заключается и в том, что заказчик порою не знает даже того, что ему нужно сейчас.
Нет, я с этим согласен, как программист. Но не согласен как заказчик. Почему кто-то надеется, что я робот и точно знаю, что мне сейчас нужно? Очень и очень сложно это точно знать.
В таком случае заказчик должен полностью оплатить составление грамотного ТЗ, чего он конечно же не хочет делать по вполне объективным (для него) причинам.
Так платите за поправки, а то «поди и сделай то, не знаю что, пять раз переделай, но вложись в сроки и бюджет». А так по-моему никто не против переделать какие-то моменты, тем более что это шанс что-то улучшить.
в этом случае хороший начальник организует так работу, чтобы было сделано наименьшее количество итераций. В моём примере можно было бы сначала сделать несколько «снимков» в каком-нибудь графическом редакторе, нарисовать отдельно несколько видов иконок со всякими затенениями и засветлениями для случаев наведения и кликов, глянуть как это будет выглядеть и выбрать нужные варианты, потом попробовать запуск по одинарному или двойному клику по иконкам без оформления, затем всё это собрать, попробовать, кое-что подделать… В моём же случае было непосредственное вмешательство в техпроцесс создания: типа сделай рабочую версию, а потом посмотрим, т.е. приходилось непосредственно резать по живому и переделывать в рамках одного проекта, в то время как можно было разбить задачу на маленькие подпроекты. Если ты нихрена не разбираешься в техпроцессе, то или дай другим действовать наиболее эффективно или разберись, хотя бы набрав статистику мнений среди разработчиков, раз одному разработчику не доверяешь и контролируй со знанием дела, а не просто по принципу я — начальник (чит. бог), а ты — подчинённый (чит. раб)
НЛО прилетело и опубликовало эту надпись здесь
Не сошланусь. В голове у меня (как заказчика) есть идеал программки, которая мне нужна. Я как мог составил по этому идеалу ТЗ, дал его разработчик, вместе с ним внимательно и аккуратно мы реализовали его. Но результат получился далек от того мысленного идеала. Виноват автор ТЗ (заказчик)? Виноват. Можно ли его в этом винить? Ну даже если и можно, то толку то. Он же не робот, чтобы без ошибочно ТЗ составлять.
Грамотный специалист должен уметь сам решить, что нужно заказчику на основании данных его пытокинтервью и аргументированно доказать что решение правильное
смешно :) Самое весёлое, что свободы действий, хоть какой-нибудь мулипусинькой свободы действий в этом случает как правило нет, ведь «он же всё знает и понимает, просто сказать не может» (с)
НЛО прилетело и опубликовало эту надпись здесь
На самом деле тут уже важнее как себя поведешь с заказчиком. Иногда достаточно просто сказать, что добавление вот этой простой (на первый взгляд) фичи потребует еще неделю коддинга и будет стоить столько денег. Заказчик сразу задумается а нужна ли ему эта фича вообще.
При чём здесь блог компании Интел? В тексте не нашёл ни одного упоминания об отношении проблем к корпорации Intel.
(Автор вроде работает в Туле в собственной компании, как видно из личных данных, но администрирует блок компании Интел. Ну и что? Где отношение статьи к Intel?)
(Автор вроде работает в Туле в собственной компании, как видно из личных данных, но администрирует блок компании Интел. Ну и что? Где отношение статьи к Intel?)
как говорится «а если бы вы писали под линукс...»
а вообще — shit happens, металург тоже не может ожидать что внезапно его металл окажется посреди цеха
а вообще — shit happens, металург тоже не может ожидать что внезапно его металл окажется посреди цеха
Мда… Как я вас понимаю… На локализацию казалось бы простого JFileChoosed диалога ушло более недели… (при начальной оценке 8 часов).
Ошибки в оценке сроков возникают от массового оптимизма программистов. Программист верит в то, что:
1. Он хороший программист.
2. Задача не сложная.
3. Не возникнет непредвиденных задач и багов
Всё это часто не так. Но дело в том, что быть пессимистом или реалистом программисту тоже нельзя — у него будут опускаться руки от страха перед новым проектом. Таким образом имеем выбор — бояться багов и неудач и не сделать вообще ничего, или верить в себя и удачу и занижать сроки. Лучше уж второе.
2. Задача не сложная.
3. Не возникнет непредвиденных задач и багов
Всё это часто не так. Но дело в том, что быть пессимистом или реалистом программисту тоже нельзя — у него будут опускаться руки от страха перед новым проектом. Таким образом имеем выбор — бояться багов и неудач и не сделать вообще ничего, или верить в себя и удачу и занижать сроки. Лучше уж второе.
Я обычно, у сложных задач, предполагаемый срок умножаю на 2..3, тем более что внезапно могут появиться новые, критические задачи которые нужно выполнить вперед старых.
но это ещё не так плохо по сравнению с тем, когда начальство выставляют тебе срок. особенно если срок звучит так «ещё вчера...»
но это ещё не так плохо по сравнению с тем, когда начальство выставляют тебе срок. особенно если срок звучит так «ещё вчера...»
Ну так на то между программистом и заказчиком есть прослойка в виде менеджмента, которая оптимистичные сроки должна умножать и уже их предоставлять заказчику.
Я не совсем понимаю, что этот пост делает в блоге компании Intel? Мне почему-то казалось, что в блогах компаний пишут сотрудники этих компаний, разве не так?
На первый вопрос — я тоже не понимаю. На второй — нет. Вы путаете официальный блог компании Интел и блог с названием «Интел», а это на Хабре не одно и то же.
Проблема в том, что этот блог называется не Intel, а «Блог компании Intel Corporation». Логично было бы предположить, что здесь будут постить сотрудники компании или уж на крайний случай какие-то переводные материалы, которые Intel принадлежат. Но, похоже, этот блог просто как пиар используют уже. Второй раз замечаю пост не по делу в нем.
tl;dr: при оценке сроков разработки чего-либо сложнее hello world обязательно учитывайте фактор неизбежного появления НЁХ, которая заставит потратить кучу сил и времени на пустом казалось бы месте.
Оценка сроков сложная задача, Ашманов рекомендует (да и я согласен с ним) считать примерно так: «Спросить программистов сколько им надо и как минимум удвоить»
Программисты такие люди что не редко излишне оптимистичны, всегда упускается из виду тот факт что «не всегда всё идёт по плану» (непредвиденные обстоятельства случаются) да и программисты такие люди чаще всего имеют не малый запас оптимизма…
Программисты такие люди что не редко излишне оптимистичны, всегда упускается из виду тот факт что «не всегда всё идёт по плану» (непредвиденные обстоятельства случаются) да и программисты такие люди чаще всего имеют не малый запас оптимизма…
Тоже оптимизм. В одной, довольно старой книжке, посвящённой программированию (забыл что за книжка, буржуйская вроде какая-то) формула была вообще суровая — возьмите следующую временнУю размерность и умножте на 4. То есть при оценке 1 час получается 4 дня, при оценке 2 дня, получается восемь недель :) и тд.
«Спросить программистов сколько им надо и как минимум удвоить»
Важно! Это работает, только если программисты об этом не знают.
Важно! Это работает, только если программисты об этом не знают.
Одна из моих прямых обязанностей — оценка проектов заходящих в отдел, так вот точность оценки зависит от времени потраченном на изучение и анализ документации.
Если спросите о моих промахах в оценке, то список будет не так уж и велик:
— не хватило времени на анализ документации — когда оценку нужно сделать на вчера, а документации пару сотен страниц, это просто мозг ломает (львиная доля ошибок)
— про… л сноску на какую-то НЁХ, т.е. моя невнимательность (отмазок конечно можно придумать с пачку)
— недооценил риски — фигли, как оценить время на изучение и изменение чужого «индуского» кода (это же относится к 3-rd party библиотекам)?
— переоценил ресурсы которые будут делать проект, меряешь ± по себе, а проект отдают зашедшему с испытательного
Если спросите о моих промахах в оценке, то список будет не так уж и велик:
— не хватило времени на анализ документации — когда оценку нужно сделать на вчера, а документации пару сотен страниц, это просто мозг ломает (львиная доля ошибок)
— про… л сноску на какую-то НЁХ, т.е. моя невнимательность (отмазок конечно можно придумать с пачку)
— недооценил риски — фигли, как оценить время на изучение и изменение чужого «индуского» кода (это же относится к 3-rd party библиотекам)?
— переоценил ресурсы которые будут делать проект, меряешь ± по себе, а проект отдают зашедшему с испытательного
> В которой нет десятилетиями проверенных стандартов и практик.
Стандарты и практики уже не одно десятилетие как существуют и применяются на практике. Умножать что-то на два — вот настоящее дилетантство.
Когда я слышу о проекте, что оценку программистов умножают, у меня возникает вопрос, а почему только оценку программистов умножают? Неужели про типовые фазы проекта по разработке ПО можно только слышать и читать?
А план проекта? Неужели его так сложно хотя бы набросать и оценить каждую задачу (группу задач) отдельно и свести их, например, в MS Project?
Я уверен, что в этом случае не только программистов придется спрашивать. Есть масса методов, как спросить «программистов», если есть неопределенность: можно использовать <a href=«ru.wikipedia.org/wiki/PERT>PERT (MS Project поддерживает это). И пожалуйста — получите приемлемую оценку плюс/минус.
Стандарты и практики уже не одно десятилетие как существуют и применяются на практике. Умножать что-то на два — вот настоящее дилетантство.
Когда я слышу о проекте, что оценку программистов умножают, у меня возникает вопрос, а почему только оценку программистов умножают? Неужели про типовые фазы проекта по разработке ПО можно только слышать и читать?
А план проекта? Неужели его так сложно хотя бы набросать и оценить каждую задачу (группу задач) отдельно и свести их, например, в MS Project?
Я уверен, что в этом случае не только программистов придется спрашивать. Есть масса методов, как спросить «программистов», если есть неопределенность: можно использовать <a href=«ru.wikipedia.org/wiki/PERT>PERT (MS Project поддерживает это). И пожалуйста — получите приемлемую оценку плюс/минус.
>Неужели его так сложно хотя бы набросать и оценить каждую задачу
некоторые задачи бывает сложно оценивать, особенно когда они из другой сферы.
Тут и первая задача становиться сложно оцениваемой («изучить новую сферу, достичь необходимого уровня для разработки»), не говоря уж о последующих.
некоторые задачи бывает сложно оценивать, особенно когда они из другой сферы.
Тут и первая задача становиться сложно оцениваемой («изучить новую сферу, достичь необходимого уровня для разработки»), не говоря уж о последующих.
Что значит из другой сферы? В разработке ПО задача из сферы металлургии?
Согласен, что часто есть задачи связанные с новыми технологиями, с которыми вы до этого не работали (скорее всего это будет новая библиотека или фреймворк, также это может быть просто код, который написан в проекте до этого и с которым нужно работать). В таком случае изучение нового нужно также включать в план как отдельную задачу (я думаю это вы имели ввиду) и попробовать ее оценить, либо найти на проект человека, который с этой технологией знаком и может либо выполнить работу, либо передать знания. Поверьте, это можно оценить достаточно просто и точно. В крайнем случае, если оценка получится слишком расплывчатой и нечеткой можно сделать небольшой пилотный проект (скажем, сроком в неделю, чтобы просто «пощупать»), чтобы картина прояснилась, возможно, поискать альтернативный вариант решения задачи… погуглить наконец. Если же таких «сложных» задач, которые нельзя оценить, становится очень много — значит у вас просто не достаточно опыта и компетенций, и скорее всего этот проект просто вам не по зубам.
Согласен, что часто есть задачи связанные с новыми технологиями, с которыми вы до этого не работали (скорее всего это будет новая библиотека или фреймворк, также это может быть просто код, который написан в проекте до этого и с которым нужно работать). В таком случае изучение нового нужно также включать в план как отдельную задачу (я думаю это вы имели ввиду) и попробовать ее оценить, либо найти на проект человека, который с этой технологией знаком и может либо выполнить работу, либо передать знания. Поверьте, это можно оценить достаточно просто и точно. В крайнем случае, если оценка получится слишком расплывчатой и нечеткой можно сделать небольшой пилотный проект (скажем, сроком в неделю, чтобы просто «пощупать»), чтобы картина прояснилась, возможно, поискать альтернативный вариант решения задачи… погуглить наконец. Если же таких «сложных» задач, которые нельзя оценить, становится очень много — значит у вас просто не достаточно опыта и компетенций, и скорее всего этот проект просто вам не по зубам.
> Поэтому когда опытный коллега или начальник увеличит вашу оценку в два-три раза, не думайте, что он недальновидный.
Хорошо, когда начальник такой «недальновидный». Плохо, когда наоборот уменьшают… Или вообще когда надо «прямо сейчас» — вот это бесит.
Хорошо, когда начальник такой «недальновидный». Плохо, когда наоборот уменьшают… Или вообще когда надо «прямо сейчас» — вот это бесит.
>>Понятно, что дисциплина эта новая (по сравнению, к примеру, с металлургией).
Проблема не в том, что она новая. Самолетостроению в 60-х было примерно столько же, сколько и программированию сейчас, а все уже работало как часы. Можно вспомнить космонавтику, ровесницу программирования, тоже все предсказуемо. Еще круче с атомной энергетикой — за какие-то 20 лет от экспериментом пришли к рутине.
Проблема в самом предмете — программировании. Например, у Гласса это подробно расписано. И никаких реальных прорывов в этом пока не видно.
Лично я работал на пяти новых проектах в разных фирмах (одна их них ИБМ). Все четыре проекта не были сделаны в срок, задержка была как минимум в два раза, причем количество участников проекта за его время увеличивалось раза в полтора. Т.е. ошибка оценки примерно в 2-4 раза. По-моему это норма.
Вот сейчас работаю на проекте год. В данный момент примерно 100 000 000 американских рублей лежат в мусорной корзине. Менеджмент с прошлой среды решает, оставлять их там или все-таки попробовать вытащить. Мы уже неделю официально ничего не делаем. Проект прошел стадию паники, сейчас стадия апатии.
Проблема не в том, что она новая. Самолетостроению в 60-х было примерно столько же, сколько и программированию сейчас, а все уже работало как часы. Можно вспомнить космонавтику, ровесницу программирования, тоже все предсказуемо. Еще круче с атомной энергетикой — за какие-то 20 лет от экспериментом пришли к рутине.
Проблема в самом предмете — программировании. Например, у Гласса это подробно расписано. И никаких реальных прорывов в этом пока не видно.
Лично я работал на пяти новых проектах в разных фирмах (одна их них ИБМ). Все четыре проекта не были сделаны в срок, задержка была как минимум в два раза, причем количество участников проекта за его время увеличивалось раза в полтора. Т.е. ошибка оценки примерно в 2-4 раза. По-моему это норма.
Вот сейчас работаю на проекте год. В данный момент примерно 100 000 000 американских рублей лежат в мусорной корзине. Менеджмент с прошлой среды решает, оставлять их там или все-таки попробовать вытащить. Мы уже неделю официально ничего не делаем. Проект прошел стадию паники, сейчас стадия апатии.
О да, самые большие ошибки в оценке проектов — это когда через пару лет понимают, что проект был не нужен. Тоже доводилось. Конечно на фоне таких промахов, промахи программистов даже стыдно упоминать.
Но вот про то что в самолетах и бомбах сейчас все ok я не уверен честно говоря. Булава-то не летает…
P.S Research In Motion или Mentor Graphics?
Но вот про то что в самолетах и бомбах сейчас все ok я не уверен честно говоря. Булава-то не летает…
P.S Research In Motion или Mentor Graphics?
— Но вот про то что в самолетах и бомбах сейчас все ok я не уверен честно говоря. Булава-то не летает…
Давайте сравним, сколько ИТ проектов накрылось и сколько булав не летает, сразу все сранет понятно.
Вот для примера:
РД0146
В 1997 г. по ТЗ ГКНПЦ им. М.В.Хруничева КБХА приступило к разработке кислородно-водородного двигателя РД0146… Проведены автономные испытания агрегатов, испытания блоков агрегатов каждого компонента на режимах выше номинальных и камеры с запальным устройством, изготовлено 4 экземпляра двигателей, на которых проведено 30 огневых испытаний с выходом на режим до 109,5% и суммарной наработкой 1680 сек. Наработка на одном двигателе составила 1604 сек. при 27 испытаниях. Отказом и аварий при испытаниях не было.
Кто мне покажет программу, которая с первого запуска прошла все тесты, включая стрессовые (109.5%)?
— P.S Research In Motion или Mentor Graphics?
Ээээ… Не понял?
Давайте сравним, сколько ИТ проектов накрылось и сколько булав не летает, сразу все сранет понятно.
Вот для примера:
РД0146
В 1997 г. по ТЗ ГКНПЦ им. М.В.Хруничева КБХА приступило к разработке кислородно-водородного двигателя РД0146… Проведены автономные испытания агрегатов, испытания блоков агрегатов каждого компонента на режимах выше номинальных и камеры с запальным устройством, изготовлено 4 экземпляра двигателей, на которых проведено 30 огневых испытаний с выходом на режим до 109,5% и суммарной наработкой 1680 сек. Наработка на одном двигателе составила 1604 сек. при 27 испытаниях. Отказом и аварий при испытаниях не было.
Кто мне покажет программу, которая с первого запуска прошла все тесты, включая стрессовые (109.5%)?
— P.S Research In Motion или Mentor Graphics?
Ээээ… Не понял?
>> Кто мне покажет программу, которая с первого запуска прошла все тесты, включая стрессовые (109.5%)?
По правде говоря многие программы и не с первого раза 100% тестов не пройдут :-).
>> Ээээ… Не понял?
Хотел компанию угадать. Видимо не угадал :-).
По правде говоря многие программы и не с первого раза 100% тестов не пройдут :-).
>> Ээээ… Не понял?
Хотел компанию угадать. Видимо не угадал :-).
«Кто мне покажет программу, которая с первого запуска прошла все тесты, включая стрессовые (109.5%)»
Насчёт 109,5% не уверен, но если результат закешировать в nginx, то может и 109.5% будет; о)
Насчёт 109,5% не уверен, но если результат закешировать в nginx, то может и 109.5% будет; о)
Увеличение количества участников редко когда способно приблизить релиз. Скорее, наоборот.
Да, об этом Гласс тоже пишет, но он же пишет, что есть ньюансы — если новые сотрудники хорошо знакомы как с софтом, так и с предметной областью, а заняты на проекте они должны быть долго, то это неверно. 4 из пяти проекто были пристрелкой стандартного софта по месту, этим новые участники проекта занимались много раз, так что расходы на их обучение были минимальны, поэтому это было оправдано.
Один проект, кстати, хотели закончить за 9 месяцев. Он идет уже 3.5 года и ему конца-края не видно. Это софт для оч.большой страховой компании, и все четко знали, что проект будет идти до того момента, когда фирма примет решение заменить этот софт на другой. Все, кроме топ-менеджеров.
Один проект, кстати, хотели закончить за 9 месяцев. Он идет уже 3.5 года и ему конца-края не видно. Это софт для оч.большой страховой компании, и все четко знали, что проект будет идти до того момента, когда фирма примет решение заменить этот софт на другой. Все, кроме топ-менеджеров.
> Так вот иногда программа «не успевала» закрыть файлы
Вы никогда не слышали о Disposable и using в .NET?
Вы никогда не слышали о Disposable и using в .NET?
Вы никогда не слышали о других средствах разработки, кроме .NET? :-)
Да я то слышал, но в статье речь шла именно о .net:
Программа была написана на .Net, поэтому время запуска сборщика мусора и прочих штук было не совсем очевидным
«Прочие штуки» — это как раз вызов Dispose() после окончания работы с файлом, using делает это автоматически как только код выходит из его scope.
Программа была написана на .Net, поэтому время запуска сборщика мусора и прочих штук было не совсем очевидным
«Прочие штуки» — это как раз вызов Dispose() после окончания работы с файлом, using делает это автоматически как только код выходит из его scope.
Пара примеров из моего опыта.
Во-первых, когда в команду приходит новый человек, он по незнанию может что-то недовнести, не туда закоммитить код и так далее. И такие вещи очень часто сбивают работу всего приложения. Яркий пример из своего опыта — коммит до апдейта, все изменения сделанные другим человеком летят на юг.
Во-вторых, фантазия управляющего звена. Я думаю, многие относятся к фразе «я тут придумал классную штуку» с содроганием, особенно если билд завтра, особенно если рабочий день кончился вчера. Некоторые менеджеры, чтобы угодить заказчику, начинают соглашаться на новые фичи в последний момент, что приводит к гонке в проекте и, следоваться, новым ошибкам и панике.
Во-первых, когда в команду приходит новый человек, он по незнанию может что-то недовнести, не туда закоммитить код и так далее. И такие вещи очень часто сбивают работу всего приложения. Яркий пример из своего опыта — коммит до апдейта, все изменения сделанные другим человеком летят на юг.
Во-вторых, фантазия управляющего звена. Я думаю, многие относятся к фразе «я тут придумал классную штуку» с содроганием, особенно если билд завтра, особенно если рабочий день кончился вчера. Некоторые менеджеры, чтобы угодить заказчику, начинают соглашаться на новые фичи в последний момент, что приводит к гонке в проекте и, следоваться, новым ошибкам и панике.
К «во-вторых» добавлю — на мой взгляд помогают такие правила:
— никаких новых правок (на сайте к примеру) в пятницу;
— никаких новых «штучек» не добавляется в проект за сколько-то времени до релиза.
Но даже следуя этим правилам иногда появляется соблазн немножко подкрутить что-то, что потом к сожалению сломает версию.
— никаких новых правок (на сайте к примеру) в пятницу;
— никаких новых «штучек» не добавляется в проект за сколько-то времени до релиза.
Но даже следуя этим правилам иногда появляется соблазн немножко подкрутить что-то, что потом к сожалению сломает версию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Откуда возникают ошибки в оценке сроков программных проектов (по мотивам собственного опыта)?