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

Введение

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

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

Для «разогрева» Стив сначала перечисляет «почти смертные грехи», т.е. ещё не самые страшные, но всё равно очень серьёзные. Он их практически не комментирует. Итак, по мнению Стива, Почти Смертными грехами в оценке трудоёмкости являются следующие вещи:

• 20. Оценивать сколько времени займёт сделать «ЭТО» до того, как кто-нибудь разберётся, что же «ЭТО» всё-таки такое

• 19. Предполагать, что наиболее достоверные оценки поступают от людей с самыми сильными голосовыми связками

• 18. Рассказывать кому-либо, что Вы пишете книгу по оценке трудоёмкости ПО, потому что они спросят «И когда вы планируете закончить свою книгу (прим., оцениваете срок окончания)?»

• 17. Делать оценки нового проекта, сравнивая его с предыдущим проектом… … оценки которого превышены… и в итоге понимая, что Вы основываете планы нового проекта на результатах предыдущего проекта вместо того, чтобы использовать информацию, адекватную текущей ситуации

• 17а. Делать оценки нового проекта, сравнивая его с предыдущим проектом… … в котором было очень много внеурочной работы… и в итоге понимая, что Вы так же закладываете много внеурочной работы в новый проект

• 16. Предполагать, что отдел продаж делает оценки лучше, чем сами разработчики

• 15. Делать оценки, предполагая, что никто не пойдёт на тренинг… … не пойдёт на митинг… никого не «сдёрнут» на другой проект… никто не потребуется для поддержки «ключевого заказчика»… не пойдёт в отпуск… не заболеет...

• 14. Давать оценки с высокой степенью точности (напр., «64,7 дня») в то время, когда они основаны на оценке с низкой точностью (+- «2 месяца»)

• 13. Верить, что результаты оценки, выполненные в коммерческом ПО, не идут ни в какое сравнение с результатами, выполненными карандашом на салфетке

• 12. Рассуждать, что чем раньше мы начнём отставать от плана, тем больше времени нам потребуется, чтобы сократить отставание

• 11. Доказывать, что разработчики (прим., специально) занижают свои оценки так, чтобы они выглядели привлекательно … последний проект, который удалось закончить раньше времени, был ещё при Рейгане!

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

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

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

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

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

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

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

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

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

5. Фокусироваться на методах оценки в то время, когда вы реально нуждаетесь в искусстве оценки трудоёмкости разработки по

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