Насчет неумения оценивать в абсолютных величинах, есть множество научных источников. С результатами самого веселого, из повстречавшихся мне, исследования, проведенным норвежским научно-исследовательским институтом Simula Research Lab хочу поделиться с вами тут.
Исследователи попросили несколько групп разработчиков дать оценку некоторых программистких задач, описанных в спецификации. В среднем, группы оценили работу в 100 часов (я пропорционально привел все данные в исследовании к круглым цифрам, чтобы было проще запоминать).
После чего, начались следующие эксперементы:
В первоначальной спецификации был увеличен шрифт, увеличины страничные, межпараграфные и межстрочные отступы. В итоге та же самая спецификация получилась на большем количестве страниц, чем первоначальная (заметьте, содержание осталось прежним). “Новая” спецификация была выдана другим группам разработчиков с просьбой произвести оценку.
Результат: 150 часов, то есть в полтора раза больше, чем первоначальная.
Та же самая первоначальная спецификация была “разбавлена водой”. В нее была внесена информация, не имеющая отношения к оцениваемым задачам (различные комментарии, типа: что такое веб-дизайн, что такое логин, что такое пароли пользователей и тп). Новая спецификация снова была выдана другим группам разработчиков с просьбой произвести оценку.
Результат: 200 часов. Уже вдвое больше, чем первоначальная.
Снова за основу взяли первоначальную спецификацию, приложили к ней дополнительные пару листочков с описанием еще одной фичи и сказали группам разработчиков: “Оцените, пожалуйста, спецификацию, и, кстати, можете просто забыть о последних двух листах, нам эта функция не нужна, не оценивайте ее. (То есть, по сути, снова попросили оценить только первоначальную спецификацию).
Результат: 200 часов. Снова вдвое больше, чем первоначальная.
Напоследок исследователи решили протестировать эффект “заякоривания” разработчиков. За основу взяли спецификацию, которая была оценена несколькими группами разработчиков в среднем в 500 часов. После чего, эту спецификацию брал Product Owner, нес команде и просил оценить, вскользь упоминая, что, мол, другие люди (которые, конечно, могут ошибаться, именно поэтому я пришел к вам) оценили эту спецификацию в Х часов.
Сначала Product Owner говорил, что другие оценили это в 1000 часов (помним, на самом деле 500), после чего команда оценивала сама.
Результат: 600 часов. На 20% больше, чем на самом деле.
Потом, Product Owner говорил, что другие оценили это в 50 часов (помним, на самом деле по прежнему 500), после чего команда оценивала сама.
Результат: 100 часов. А это в 5 раз меньше, чем на самом деле.
После всего этого напрашивается простой вывод: “Люди не умеют оценивать”.
У кого еще есть подобные веселые случаи, доказывающие, что люди не умеют оценивать? Делимся в комментариях.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
Сергей, привет! Помню, в универе самым опасным словом от лектора было слово "очевидно". Прочитав комментарии, видится, что под вопрос ставится утверждение "оценивать должен тот, кто будет выполняться задачу". Для меня это именно "очевидно", однако есть ли какие-то другие объяснения этого?
[…] которые бы ими не пользовались. Главная причина – люди не умеют оценивать в абсолютных величинах, поэтому стори-поинты лучше, […]
Спасибо за комментарий, Алексей, хочу кое с чем поспорить.
Алексей, у меня всегда возникали проблемы с определением того момента когда ТЗ становится "более четким"? :)
Боюсь, что то к чему привыкли наши организации и разработчики на сегодняшний день настолько не соответствует современным методам сбора и обработки требований, что толку от этой спеки совсем не будет.
И тут тоже не соглашусь с вами, прорабатывать требования должен не менеджер с тим-лидом, а вся команда.
Согласен с вами, однако не весь прошлый опыт одинаково применим к оценкам. Если мы оцениваем инсталляцию Drupal в очередной (сотый) раз, то наш предыдущий опыт применим. А если мы делали проект по интеграции с одним банком, а теперь будем делать с другим, то не очень.
Тут неплохо учитывать неоднозначность мира (к примеру по Cynefin модели Дэйва Сноудена) или ей подобных.
1. Если мы получаем пояснительную записку от клиента в которой подробнейшим образом и жестко заданы требования, то оценка получится меньше чем в случае с "водой".
Если добавить воды - то это может послужить обходным путём для "пропихивания" дополнительных фич. Так мы делаем вывод, что заказчик не точно знает чего хочет и нам нужен будет запас на "слив" этой воды в последствие и доработку недетализированных или размытых требований.
Аргумент: более четкое ТЗ позволяет уменьшить запас часов на "зализывание ран".
Метод борьбы: Если предположить, что спецификация строится по общепринятым в организации правилам, к которым привыкли разработчики, то оценки будут получатся более регулярными.
Итого - менеджер и технический специалист (тим-лид) должны перерабатывать требования в типовой и привычный для всей организации документ.
Ситуация - А это можете не делать - например мобильная версия сайта - эта фича, которую можно просто забыть. А если заказчик в дальнейшем хочет использовать наши статические страницы как разные типы данных, каждой из которых будет принадлежать древовидная структура и тд. То естественно такой ход нужно предусмотреть в архитектуре.
Якоря - отличный пример рыночной экономики. Введение программиста в работу по оценке - это в том числе торговля - если есть возможность продать себя дороже (в данном случае запас безхозного времени) - он это сделает.
Т.е. всё станет на свои места если иметь ввиду что оценку вы получаете не сферического проекта в вакууме, а именно того где в скором времени прольются слезы и кровь беззащитных апологетов информационных технологий.
Спасибо за комментарий, Евгений.
Тут хочу с вами не согласится, наиболее точную оценку все-таки дают те, кто непосредственно будет эту работу выполнять.
А что касается опыта предыдущих проектов, если мы инсталлируем друпал 1000 раз подряд, то, да согласен, предыдущий опыт имеет смысл. Если же мы занимаемся инновациями, интегрируемся со сторонними системами, наш предыдущий опыт все равно не поможет нам произвести точные оценки.
Если речь идет о аутсорсе, то определять с точностью до часа и не требуется. Менеджер балансирует между возможной себестоимостью работ и риском что заказчику покажется ценник слишком дорогим. Наиболее точную оценку дают действительно менеджер и архитектор исходя из опыта на предыдущих проектах. А насколько она окажется верной - можно узнать только попробовав.
Ведь успех проекта, это не только грамотная оценка, но и работа с командой и минимизация рисков. Одна и та же команда с одной и той же оценкой может как сдать проект раньше, так и спихнуть его много позже срока.
Оценки должны основываться на прошлом опыте. Чтобы довать более менее адекватные оценки необходимо базироваться на базе знаний
К сожалению 60 летний опыт разработки ПО показывает, что такой подход не работает. Ни архитектор, ни менеджер, не могут сказать кто и за сколько сможет сделать ту или иную задачу.
Если речь о разработке ПО, то у исполнителей должен быть архитектор и менеджер. Они разбивают задачу на подзадачи, описывают элементы системы, устанавливают требования к ним, определяют порядок разработки и распределеют разработчиков.
Но самое главное - именно эти люди накапливают опыт работы по ТЗ! Поэтому они и должны этим заниматься.
Исследование как раз и делалось с декомпозицией и проработкой и все равно доказало что оценки - это гадание на кофейной гуще.
Тут вы совершенно правы, есть очень примечательный график, с кривой неопределенности оценки. Там как раз, это хорошо видно, чем больше вкладываемся в рассасывание деталей, тем больше "леса" мы строим и сами же в нем и запутываемся.
По опыту могу сказать, что психологические эффекты, описанные в исследовании, оказывают сильное влияние, когда время на оценку 100- и 500-страничного документа примерно одинаковое. Если же на оценку 500-страничного «ТЗ» потратить в 5 раз больше, то и оценки будут адекватнее.
Опять-таки, психологическое влияние оценок других команд будет так же сильно, если собственная оценка во многом делалась на глазок, или что называется «пальцем в небо». Если оценка делалась на основе проработки и декомпозиции документа на конкретные и понятные задачи, оценки всегда более-менее точны. Или, по крайней мере, куда точнее данных на глазок. Бороться с психологическими эффектами можно осознанностью принимаемых решений.
Третье, что хотелось сказать: есть ещё психологическое влияние прошлого опыта работы над подобными проектами. Проблемы других проектов заставляют людей перестраховываться и увеличивать оценку.
Наконец, оценки данные по исходному ТЗ чуть менее, чем всегда будут пальцем в небо. Мы обычно делаем их на основе тщательного обсуждения с заказчиком и изучения предметной области и существующего «багажа» системы. При этом фактически рождается ещё один документ, хоть и не 100-страничный, а оригинальный может сократиться и до 20 листов.
Ещё что интересно, при таком подходе оценки, данные по краткому документу, оказываются точнее, чем если бы у нас было подробное описание всех вариантов использования и пользовательского интерфейса. Мне кажется, дело тут в том, что в больших и подробных документах за деревьями сложно разглядеть лес, и времени на оценку уходит больше.
Адекватная оценка — это уже этап разработки системы, она требует соответствующего времени и ресурсов.
А исследование само по себе интересное.
Просто Murad похоже хотел сказать, что есть кто-то кто знает лучше :). В таком случае хочу спросить, может ли какой-нить эксперт по чтению книг, сказать мне, за сколько я прочитаю нового Гарри Поттера? Задумайтесь об этом...
Все таки разработка софта, это не приборостроение, и к сожалению, гораздо меньше проектов у нас, когда есть "аналогичные работы" с которыми мы можем что-то сравнить (если мы не друпал инсталлируем нашему 1000-ому клиенту). Скорее всего, никто не интегрировался до этого, с системами именно этого клиента, и прочие инновационные штучки, до нас тоже никто не делал.
Так исследование же это и доказывает :-) Оценивали же как раз те, кто собирался делать ;-). А если серьезно,
то действительно... начинаешь задумываться... надо ли отдавать оценку на откуп "не профессиональной" оценке. На днях узнал, как оценка делалась в советский времена в одном институте, занимающемся приборостроением (оценка делалась на работы по разводке печатных плат): оценка делалась начальником на основе плотности монтажа * на квалификацию исполнителя. Делаешь раньше срока - оплачиваемый отгул, не укладываешься - лишают премии или еще что. Знающие люди говорят, что система работала отлично :) Т.е. оценка это статистика по аналогичным работам * на квалификацию.
Очень хочу конструктивно с этим поспорить. А кто же еще может сделать оценку, кроме как те люди, которые непосредственно будут делать работу?
Просто оценкой не разработчики должны заниматься
[...] Дмитриев пишет в своем блоге о том что может оказать влияние на оценку [...]