Pull to refresh

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

Project management *

Введение


В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 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. Давать поспешные оценки


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

Заключение


Я не буду пытаться убедить вас в истинности всех тех утверждений, которые делает Стив. Вы вольны полагаться на свои знания и опыт. Стив — человек с огромными знаниями и опытом, но он человек, а людям свойственно ошибаться. Если вы считаете, что где-то он не прав, то отпишитесь, пожалуйста, об этом в комментариях — будет очень интересно обсудить.
Tags:
Hubs:
Total votes 116: ↑106 and ↓10 +96
Views 29K
Comments Comments 27