Пользователь
0,0
рейтинг
23 ноября 2009 в 15:59

Управление → Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения

Введение


В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.


Десять Почти Смертных грехов в оценке трудоёмкости разработки ПО


Для «разогрева» Стив сначала перечисляет «почти смертные грехи», т.е. ещё не самые страшные, но всё равно очень серьёзные. Он их практически не комментирует.
Итак, по мнению Стива, Почти Смертными грехами в оценке трудоёмкости являются следующие вещи:
  • 20. Оценивать сколько времени займёт сделать «ЭТО» до того, как кто-нибудь разберётся, что же «ЭТО» всё-таки такое
  • 19. Предполагать, что наиболее достоверные оценки поступают от людей с самыми сильными голосовыми связками
  • 18. Рассказывать кому-либо, что Вы пишете книгу по оценке трудоёмкости ПО, потому что они спросят «И когда вы планируете закончить свою книгу (прим., оцениваете срок окончания)?»
  • 17. Делать оценки нового проекта, сравнивая его с предыдущим проектом…
    … оценки которого превышены… и в итоге понимая, что Вы основываете планы нового проекта на результатах предыдущего проекта вместо того, чтобы использовать информацию, адекватную текущей ситуации
  • 17а. Делать оценки нового проекта, сравнивая его с предыдущим проектом…
    … в котором было очень много внеурочной работы… и в итоге понимая, что Вы так же закладываете много внеурочной работы в новый проект
  • 16. Предполагать, что отдел продаж делает оценки лучше, чем сами разработчики
  • 15. Делать оценки, предполагая, что никто не пойдёт на тренинг…
    … не пойдёт на митинг… никого не «сдёрнут» на другой проект… никто не потребуется для поддержки «ключевого заказчика»… не пойдёт в отпуск… не заболеет...
  • 14. Давать оценки с высокой степенью точности (напр., «64,7 дня») в то время, когда они основаны на оценке с низкой точностью (+- «2 месяца»)
  • 13. Верить, что результаты оценки, выполненные в коммерческом ПО, не идут ни в какое сравнение с результатами, выполненными карандашом на салфетке
  • 12. Рассуждать, что чем раньше мы начнём отставать от плана, тем больше времени нам потребуется, чтобы сократить отставание
  • 11. Доказывать, что разработчики (прим., специально) занижают свои оценки так, чтобы они выглядели привлекательно
    … последний проект, который удалось закончить раньше времени, был ещё при Рейгане!

Десять Смертных грехов в оценке трудоёмкости разработки ПО


1. Путать проектные цели и оценки


Типичная ситуация выглядит следующим образом. Руководство ставит задачу оценить трудоёмкость работы, добавляя при этом, что проект планируется показать на какой-нибудь ежегодной выставке где-нибудь за рубежом. Т.е., вроде как, и оцените, сколько надо… но надо тогда-то. Здесь оценка трудоёмкости перемешивается с целями проекта ( «показать на выставке в фиксированное время» ). Решение проблемы состоит в итеративном выравнивании целей и оценок. Например, для достижения цели можно уменьшить объём представляемого функционала, чтобы успеть всё сделать в срок.

2. Говорить «Да» тогда, когда вы, на самом деле, подразумеваете «Нет»


Часто складывается так, что за столом переговоров, за которым обсуждаются оценки/сроки, люди делятся на две группы. По одну сторону располагаются разработчики, которые часто интровертивны, молоды и редко обладают даром убеждения… а по другую сторону сидят экстравертивные и «умудрённые опытом» сейлз-менеджеры, которые не только обладают навыками убеждения, но и, иногда, специально обучены убеждать. В такой ситуации очевидно, что независимо от качества оценок, «побеждает» тот, кто умеет лучше «убеждать», а не тот, чьи оценки более адекватные.

3. Давать обещания на ранней стадии Конуса неопределённости


Перед вами так называемый «конус неопределённости» (или неуверенности… кому как нравится).
image
Это график, на горизонтальной оси которого указано время, а на вертикальной оси — значение ошибки, которая закладывается при оценке трудоёмкости. Как видно из графика, с течением времени, по мере того, как становится известно всё больше данных об оцениваемом проекте, о том, что же конкретно и в каких условиях придётся делать, «разброс» ошибки становится всё меньше.
Суть же проблемы состоит в том, что нельзя давать обещания в тот момент времени (крайняя левая часть конуса), когда величина ошибки ещё слишком велика. Стив оценивает предел «уверенности» где-то в районе 1,5x, т.е. тот момент времени, когда вероятная ошибка будет составлять 1,5 раза как в большую, так и в меньшую сторону. Давать обещания раньше этого момента — заведомо подвергать себя слишком большому риску.

4. Предполагать, что недооценка оказывает нейтральное влияние на результаты проекта


На эту мысль автор неоднократно делает акцент и в своей книге (см. Введение). Взгляните на график ниже.
image
Левая часть графика показывает зону недооценки (underestimation), правая часть графика зону переоценки (overestimation). По вертикали откладывается стоимость ошибки. Из графика видно, что стоимость переоценки растёт линейно (по закону Паркинсона). В то же время стоимость недооценки увеличивается лавинообразно по мере того, как возрастает ошибка недооценки необходимых усилий. В случае недооценки прогнозировать дополнительные усилия куда сложнее, чем в случае переоценки.

5. Фокусироваться на методах оценки в то время, когда вы реально нуждаетесь в ИСКУССТВЕ оценки трудоёмкости разработки ПО


Оценка трудоёмкости в основе своей — это не только конкретные методики, но и практика их применения. Это набор удачных подходов, которые хорошо зарекомендовали себя. Искусством же является применение нужной методики в нужное время и в нужном месте.

6. Делать оценки в «Зоне невероятности»


Здесь нужно пояснить, что же подразумевается под зоной невероятности. Для произвольного проекта представим вот такой диалог (прим. сильно сокращён):
— Смогут ли 12 разработчиков закончить Проект за 10 месяцев?
— Да, может быть — отвечаем мы.
— А 15 разработчиков за 8 месяцев?
— Ну да, — отвечаем мы — скорее да, чем нет.
— А 30 за 4?
— Вряд ли — становится очевидно, что 30 человек, скорее всего, не смогут сработаться за такой короткий срок.
— 60 за 2 месяца?
— Ну это уже смешно!, — ответите вы…
— А 120 разработчиков за 1 месяц?
— Ну а это вообще не смешно. Издевательство просто…
Из этого диалога видно, что «сжатие» сроков при заданной трудоёмкости не может происходить бесконечно — есть предел. Так вот идея данного пункта состоит в том, чтобы не производить оценок за этим пределом. Такие оценки не могут быть состоятельными. Предел «на сжатие», по мнению Стива, находится где-то около 25% от номинальных оценок.

7. Переоценивать выгоду от новых методов и технологий


Использование новых технологий сопряжено с:
  • затратами на обучение
  • рисками, связанными с использованием непроверенной технологии
  • тем, что выгода от использования более совершенной технологии оказывается меньше, чем обычно заявлено
Личная рекомендация Стива: «Считать, что использование новой технологии в первый раз снизит продуктивность разработки». И снова тезис: «Нет серебряной пули».

8. Использовать только один метод оценки трудоёмкости


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

9. Пренебрегать специализированным ПО для оценки трудоёмкости


Моделирование при помощи компьютерных программ может повысить адекватность оценок. Естественно, использование специальных средств не гарантирует вам надёжность и адекватность оценок. Но при умелом использовании может заметно повысить их точность. Кроме того, автор даёт ссылку на сайт своей компании, где доступны бесплатные инструменты для проведения компьютерной оценки трудоёмкости разработки ПО. Одно из главных достоинств специального ПО в том, что результаты выглядят более убедительно для «потребителей» оценок.

10. Давать поспешные оценки


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

Заключение


Я не буду пытаться убедить вас в истинности всех тех утверждений, которые делает Стив. Вы вольны полагаться на свои знания и опыт. Стив — человек с огромными знаниями и опытом, но он человек, а людям свойственно ошибаться. Если вы считаете, что где-то он не прав, то отпишитесь, пожалуйста, об этом в комментариях — будет очень интересно обсудить.
Юрий Дайбов @Jay_Di_Human
карма
47,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (27)

  • +10
    Макконел крутой дядька, всегда любит все четко по полочкам разложить. Большинство (или даже все) из приведенных «смертных грехов» так или инчае понимает любой адекватный разработчик, но иметь такой вот список очень полезно — можно лишний раз просмотреть его перед началом нового проекта и уберечь себя от ненужных ошибок=) В избранное!
    • +2
      Да-да, опытный специалист (будь то разработчик или управляющий проектами) большую часть этих пунктов знает. Более того, скорее всего, уже проверил «на собственной шкуре». Здесь МакКоннелл сделал акцент, что это не просто ошибки, как таковые, а действительно очень-очень серьёзные проблемы в оценке трудоёмкости.
      Данный вебинар скорее предназначен, чтобы уберечь начинающих специалистов от типовых и очень опасных ошибок. Опытным он позволить просто поставить дополнительный «плюсик» к своим знаниям — эдакий «пруфлинк».
    • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    Читать и перечитывать, пока в голове не отложится каждое слово, которое здесь написано.
  • +2
    Какие знакомые грабли…
  • 0
    Я что-то не понимаю или заголовок:
    9. Не использовать специализированное ПО для оценки трудоёмкости
    противоречит пояснению
    • 0
      Да нет, ничуть… НЕ использовать спец. ПО — ошибка… всё логично, читается как «используйте и будете правы».
    • +1
      Это «грех», т.е. ошибка.
      «Не использовать» — плохо.
      «Использовать» — хорошо.
      • +1
        Для улучшения читабельности надо бы подобрать уничижительный греховный синоним к «Не использовать», и вписать его.

        Предлагаю, например, «Пренебрегать»…
        • 0
          Спасибо! Поправил. Так действительно лучше читается.
  • 0
    даёт ссылку на сайт своей компании, где доступны бесплатные инструменты для проведения компьютерной оценки

    У кого-нибудь получилось там зарегистрироваться? Кнопки сабмита не видно, а по Enter выдаётся

    search results for ""

    No Results.
    • 0
      У меня из оперы тоже не получилось — попробуйте из FF. И потом при логине не жмите Enter — только мышкой )
      • 0
        Забавно, даже у таких значимых людей на сайте можно найти такие вот «детские» баги, как например этот — нерабочий DefaultButton в WebForms в Firefox :)
    • +2
  • 0
    «Личная рекомендация Стива: «Считать, что использование новой технологии в первый раз снизит продуктивность разработки». И снова тезис: «Нет серебряной пули».»

    В моей недавней практике использование новой для нас технологии — SOAP+Hibernate+Java продуктивность не снизило, а наоборот, сильно повысило. И чем дальше, тем правильней выглядит это решение.
    • 0
      График полезный, буду его клиентам показывать, отдельно за оценку никто платить не хочет — так чтоб понимали, что либо надо пройти первый этап разработки, либо смириться с ошибкой 400%.
    • 0
      Наверно, не стоит считать это 100%-ым правилом, т.к. это не везде применимо. Но так бывает (я встречал), когда на новую технологию предварительных затртат больше, чем при работе «по старинке». При этом получить ожидаемый эффект не всегда хватает времени.
      Здесь немного упрощённый призыв «не вестись» на маркетинговые приёмы и принимать очень взвешанные решения по внедрению новых технологий.
      При этом, естественно, нужен и определённый риск, и кураж… без этого не удастся сделать что-то новое, необычное, амбициозное.
  • +1
    все отлично только вопрос,
    т.е. сначала нужно тратить время на въезжание в тему пока не достигнешь 1.5x?
    кто будет платить за это время?

    и, если после достижения этой отметки проект не запустят — выйдет, что его начинали зря.

    можно конечно запланировать в самом проекте отрезок времени с 2-3-4/кратным запасом на оценку самого проекта разработчиками.
    • +1
      Очень хороший вопрос.
      Время тратить нужно. Если не потратить его на аналитическое обследование до старта проекта, то потом придётся платить за это втридорого. Иногда выгоднее за проект вообще не браться.
      Если удастся договориться (за это отвечает менеджмент), то платить за это будет заказчик. Если нет, то платить нам (исполнителям), но проводить предварительную работу всё равно надо.
      Повторюсь… в некоторых случаях осмысленно «потерянный» проект — это выгода (за счёт экономии средств).
  • +1
    отличная статья, спасибо Вам!
    • 0
      Скорее всё-таки Стиву МакКоннеллу. :)
      Мне только посчастливилось его услышать и передать это вам.
      • 0
        за это и спасибо :)
  • 0
    Грехи 3,6 и 10 суть одно и то же.
    Грех 9 — плохо скрытая реклама сайта и продуктов автора.
    Грех 2 — тема не раскрыта. Там автор что имел ввиду? Что программисты не умеют делать оценки? Что нет менеджера проекта, который должен сидеть на переговорах вместо них?
    Грех 5 — просто пустой звук. Если вам не хватает «искусства» в вашей работе — не беритесь.

    Автор так же ни слова не сказал о рисках. Вот уж что точно несет смерть оценкам.
    Другой грех — делать оценки только раз на проект.

    Коллеги, эти тезисы вас не спасут от ошибок в оценках, не очень полагайтесь на советы МакКоннела.
    • 0
      Ну наконец… Именно такого комментария я долго ждал. Спасибо.
      Согласен с тем, что 3,6 и 10 могут казаться похожими… если не читать пояснения.
      Я поясню.
      3 — ранние оценки из-за отсутствия необходимой информации о предмете
      6 — сжатие сроков при сохранении значения трудоёмкости (увеличение команды)
      10 — ранние оценки из-за невозможности/нежелания «отойти в сторону» и немного подумать, сравнить и соизмерить.
      Да, похожи, но всё-таки разные.
      9 — согласился бы с Вами, если бы не тот факт, что продукты бесплатны. Кроме того, никто не заставляет пользовать продуктами автора, даже обычный Excel — уже достаточно мощный инструмент для проведения моделирования.
      2 — автор имел в виду проблему «продавливания» оценок теми, кто более уверенно говорит и убеждает. Только это.
      5 — здесь автор говорит о том, что инструмент в неумелых руках ещё не гарантирует результата (стамеска в руках мастера — произведение искуства, в «кривых» руках — что угодно, только не то, что нужно)

      Риски — это немного другой угол зрения. Риски, как правило (но не всегда), влияют на сроки, а не на оценки трудоёмкости. В общем, это тема другой статьи.

      И да, согласен, эти тезисы не спасут от всех ошибок, но, возможно, помогут избежать самых грубых.
  • 0
    Цитирую статью и ваш последний комментарий

    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» Это никак не «поспешная оценка», ай-яй.

    Чтож вы как неаккуратны в переводе?
    Резюме: презентация МакКонела не фонтан, но перевод просто мрак. Читайте оригинал!

    • 0
      Дословно «Off-the-Cuff» переводится как «импровизированный, неподготовленный», но в таком виде, на мой взгляд, это звучит криво, не по-русски как-то. Поэтому я избрал синоним «поспешный».
      Какой синоним подобрали бы Вы?
      • 0
        Конечно «неподготовленный», потому что это точно. Далее там идет:

        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)

        и т.д… Тоесть, конкретные советы по подготовке.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.