Comments 27
Макконел крутой дядька, всегда любит все четко по полочкам разложить. Большинство (или даже все) из приведенных «смертных грехов» так или инчае понимает любой адекватный разработчик, но иметь такой вот список очень полезно — можно лишний раз просмотреть его перед началом нового проекта и уберечь себя от ненужных ошибок=) В избранное!
Да-да, опытный специалист (будь то разработчик или управляющий проектами) большую часть этих пунктов знает. Более того, скорее всего, уже проверил «на собственной шкуре». Здесь МакКоннелл сделал акцент, что это не просто ошибки, как таковые, а действительно очень-очень серьёзные проблемы в оценке трудоёмкости.
Данный вебинар скорее предназначен, чтобы уберечь начинающих специалистов от типовых и очень опасных ошибок. Опытным он позволить просто поставить дополнительный «плюсик» к своим знаниям — эдакий «пруфлинк».
Данный вебинар скорее предназначен, чтобы уберечь начинающих специалистов от типовых и очень опасных ошибок. Опытным он позволить просто поставить дополнительный «плюсик» к своим знаниям — эдакий «пруфлинк».
UFO just landed and posted this here
Читать и перечитывать, пока в голове не отложится каждое слово, которое здесь написано.
Какие знакомые грабли…
Я что-то не понимаю или заголовок:
9. Не использовать специализированное ПО для оценки трудоёмкости
противоречит пояснению
9. Не использовать специализированное ПО для оценки трудоёмкости
противоречит пояснению
даёт ссылку на сайт своей компании, где доступны бесплатные инструменты для проведения компьютерной оценки
У кого-нибудь получилось там зарегистрироваться? Кнопки сабмита не видно, а по Enter выдаётся
search results for ""
No Results.
«Личная рекомендация Стива: «Считать, что использование новой технологии в первый раз снизит продуктивность разработки». И снова тезис: «Нет серебряной пули».»
В моей недавней практике использование новой для нас технологии — SOAP+Hibernate+Java продуктивность не снизило, а наоборот, сильно повысило. И чем дальше, тем правильней выглядит это решение.
В моей недавней практике использование новой для нас технологии — SOAP+Hibernate+Java продуктивность не снизило, а наоборот, сильно повысило. И чем дальше, тем правильней выглядит это решение.
График полезный, буду его клиентам показывать, отдельно за оценку никто платить не хочет — так чтоб понимали, что либо надо пройти первый этап разработки, либо смириться с ошибкой 400%.
Наверно, не стоит считать это 100%-ым правилом, т.к. это не везде применимо. Но так бывает (я встречал), когда на новую технологию предварительных затртат больше, чем при работе «по старинке». При этом получить ожидаемый эффект не всегда хватает времени.
Здесь немного упрощённый призыв «не вестись» на маркетинговые приёмы и принимать очень взвешанные решения по внедрению новых технологий.
При этом, естественно, нужен и определённый риск, и кураж… без этого не удастся сделать что-то новое, необычное, амбициозное.
Здесь немного упрощённый призыв «не вестись» на маркетинговые приёмы и принимать очень взвешанные решения по внедрению новых технологий.
При этом, естественно, нужен и определённый риск, и кураж… без этого не удастся сделать что-то новое, необычное, амбициозное.
все отлично только вопрос,
т.е. сначала нужно тратить время на въезжание в тему пока не достигнешь 1.5x?
кто будет платить за это время?
и, если после достижения этой отметки проект не запустят — выйдет, что его начинали зря.
можно конечно запланировать в самом проекте отрезок времени с 2-3-4/кратным запасом на оценку самого проекта разработчиками.
т.е. сначала нужно тратить время на въезжание в тему пока не достигнешь 1.5x?
кто будет платить за это время?
и, если после достижения этой отметки проект не запустят — выйдет, что его начинали зря.
можно конечно запланировать в самом проекте отрезок времени с 2-3-4/кратным запасом на оценку самого проекта разработчиками.
Очень хороший вопрос.
Время тратить нужно. Если не потратить его на аналитическое обследование до старта проекта, то потом придётся платить за это втридорого. Иногда выгоднее за проект вообще не браться.
Если удастся договориться (за это отвечает менеджмент), то платить за это будет заказчик. Если нет, то платить нам (исполнителям), но проводить предварительную работу всё равно надо.
Повторюсь… в некоторых случаях осмысленно «потерянный» проект — это выгода (за счёт экономии средств).
Время тратить нужно. Если не потратить его на аналитическое обследование до старта проекта, то потом придётся платить за это втридорого. Иногда выгоднее за проект вообще не браться.
Если удастся договориться (за это отвечает менеджмент), то платить за это будет заказчик. Если нет, то платить нам (исполнителям), но проводить предварительную работу всё равно надо.
Повторюсь… в некоторых случаях осмысленно «потерянный» проект — это выгода (за счёт экономии средств).
отличная статья, спасибо Вам!
Грехи 3,6 и 10 суть одно и то же.
Грех 9 — плохо скрытая реклама сайта и продуктов автора.
Грех 2 — тема не раскрыта. Там автор что имел ввиду? Что программисты не умеют делать оценки? Что нет менеджера проекта, который должен сидеть на переговорах вместо них?
Грех 5 — просто пустой звук. Если вам не хватает «искусства» в вашей работе — не беритесь.
Автор так же ни слова не сказал о рисках. Вот уж что точно несет смерть оценкам.
Другой грех — делать оценки только раз на проект.
Коллеги, эти тезисы вас не спасут от ошибок в оценках, не очень полагайтесь на советы МакКоннела.
Грех 9 — плохо скрытая реклама сайта и продуктов автора.
Грех 2 — тема не раскрыта. Там автор что имел ввиду? Что программисты не умеют делать оценки? Что нет менеджера проекта, который должен сидеть на переговорах вместо них?
Грех 5 — просто пустой звук. Если вам не хватает «искусства» в вашей работе — не беритесь.
Автор так же ни слова не сказал о рисках. Вот уж что точно несет смерть оценкам.
Другой грех — делать оценки только раз на проект.
Коллеги, эти тезисы вас не спасут от ошибок в оценках, не очень полагайтесь на советы МакКоннела.
Ну наконец… Именно такого комментария я долго ждал. Спасибо.
Согласен с тем, что 3,6 и 10 могут казаться похожими… если не читать пояснения.
Я поясню.
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — сжатие сроков при сохранении значения трудоёмкости (увеличение команды)
10 — ранние оценки из-за невозможности/нежелания «отойти в сторону» и немного подумать, сравнить и соизмерить.
Да, похожи, но всё-таки разные.
9 — согласился бы с Вами, если бы не тот факт, что продукты бесплатны. Кроме того, никто не заставляет пользовать продуктами автора, даже обычный Excel — уже достаточно мощный инструмент для проведения моделирования.
2 — автор имел в виду проблему «продавливания» оценок теми, кто более уверенно говорит и убеждает. Только это.
5 — здесь автор говорит о том, что инструмент в неумелых руках ещё не гарантирует результата (стамеска в руках мастера — произведение искуства, в «кривых» руках — что угодно, только не то, что нужно)
Риски — это немного другой угол зрения. Риски, как правило (но не всегда), влияют на сроки, а не на оценки трудоёмкости. В общем, это тема другой статьи.
И да, согласен, эти тезисы не спасут от всех ошибок, но, возможно, помогут избежать самых грубых.
Согласен с тем, что 3,6 и 10 могут казаться похожими… если не читать пояснения.
Я поясню.
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — сжатие сроков при сохранении значения трудоёмкости (увеличение команды)
10 — ранние оценки из-за невозможности/нежелания «отойти в сторону» и немного подумать, сравнить и соизмерить.
Да, похожи, но всё-таки разные.
9 — согласился бы с Вами, если бы не тот факт, что продукты бесплатны. Кроме того, никто не заставляет пользовать продуктами автора, даже обычный Excel — уже достаточно мощный инструмент для проведения моделирования.
2 — автор имел в виду проблему «продавливания» оценок теми, кто более уверенно говорит и убеждает. Только это.
5 — здесь автор говорит о том, что инструмент в неумелых руках ещё не гарантирует результата (стамеска в руках мастера — произведение искуства, в «кривых» руках — что угодно, только не то, что нужно)
Риски — это немного другой угол зрения. Риски, как правило (но не всегда), влияют на сроки, а не на оценки трудоёмкости. В общем, это тема другой статьи.
И да, согласен, эти тезисы не спасут от всех ошибок, но, возможно, помогут избежать самых грубых.
Цитирую статью и ваш последний комментарий
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — чтобы не производить оценок в «зоне невероятности»
10 — предостережении от использования поспешных, необоснованных оценок
Ну уж настолько тонкая граннь между этими пунктами что можно, можно объединить их в один. Вебинар от этого только выйграл бы.
9 — дааа, спасибо что даром. реклама бесплатных продуктов все равно реклама. в данном случае — реклама самого МакКоннела. И не заставляет, да, а что, мог бы и заставить?
2 — все решения «продавливают» те, кто уверенно говорит и убеждает. лучше бы упомянули цитату Брукса из презентации «It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.» Интровертные неубедительные юные разработчики не вызывают во мне сочувствия. Они просто некомпетентны в проведении оценок.
5 — просто красивая фраза, которая не содержит в себе никакой специфики оценивания трудоемкости. Суть та же что в п.2 — некомпетентность.
Риски кстати в презентации макКонела упомянуты грехом № 9, посмотрел по вашей же ссылке.
А пункт 10 в оригинале «Providing Off-The-Cuff Estimates» Это никак не «поспешная оценка», ай-яй.
Чтож вы как неаккуратны в переводе?
Резюме: презентация МакКонела не фонтан, но перевод просто мрак. Читайте оригинал!
3 — ранние оценки из-за отсутствия необходимой информации о предмете
6 — чтобы не производить оценок в «зоне невероятности»
10 — предостережении от использования поспешных, необоснованных оценок
Ну уж настолько тонкая граннь между этими пунктами что можно, можно объединить их в один. Вебинар от этого только выйграл бы.
9 — дааа, спасибо что даром. реклама бесплатных продуктов все равно реклама. в данном случае — реклама самого МакКоннела. И не заставляет, да, а что, мог бы и заставить?
2 — все решения «продавливают» те, кто уверенно говорит и убеждает. лучше бы упомянули цитату Брукса из презентации «It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.» Интровертные неубедительные юные разработчики не вызывают во мне сочувствия. Они просто некомпетентны в проведении оценок.
5 — просто красивая фраза, которая не содержит в себе никакой специфики оценивания трудоемкости. Суть та же что в п.2 — некомпетентность.
Риски кстати в презентации макКонела упомянуты грехом № 9, посмотрел по вашей же ссылке.
А пункт 10 в оригинале «Providing Off-The-Cuff Estimates» Это никак не «поспешная оценка», ай-яй.
Чтож вы как неаккуратны в переводе?
Резюме: презентация МакКонела не фонтан, но перевод просто мрак. Читайте оригинал!
Дословно «Off-the-Cuff» переводится как «импровизированный, неподготовленный», но в таком виде, на мой взгляд, это звучит криво, не по-русски как-то. Поэтому я избрал синоним «поспешный».
Какой синоним подобрали бы Вы?
Какой синоним подобрали бы Вы?
Конечно «неподготовленный», потому что это точно. Далее там идет:
Use of guessing and intuition to create estimates is correlated with cost and schedule overruns (at the 0.05 level of
significance)
v Use of simple arithmetic formulas is negatively correlated with overruns (at the 0.01 level of significance)
и т.д… Тоесть, конкретные советы по подготовке.
Use of guessing and intuition to create estimates is correlated with cost and schedule overruns (at the 0.05 level of
significance)
v Use of simple arithmetic formulas is negatively correlated with overruns (at the 0.01 level of significance)
и т.д… Тоесть, конкретные советы по подготовке.
Sign up to leave a comment.
Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения