10 смертных грехов оценок задач в IT

Искусство и наука об оценки в IT:

• Наука оценки хорошо развита и хорошо поддерживается программными инструментами.

• Искусство оценки преимущественно основано на эмпирических правилах и их еще нужно немного доработать.

Эта статья основана на материалах Steve McConnell из Construx и часть материалов как были остались картинками.

Смертные грехи

Грех №1 Путать цели с оценками

Проводите различия:

• Установка целей — ключевая часть искусства оценивания.

• Когда вас попросят дать оценку, определите, действительно ли вы должны оценивать или лучше выяснить, как достичь цели.

• Лучше всего рассматривать это как итеративный процесс который выравнивание цели и оценки.

Грех №2 Говорить «да», когда вы действительно имеете в виду «нет»

Почему разработчики говорят «да».

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

Фред Брукс (1975)

Особенности коммуникаций в компании:

• Разработчики программного обеспечения, как правило, интроверты и относительно молоды

• Специалисты по маркетингу и продажам, как правило, более экстравертны и организационно выше разработчиков, с которыми они договариваются

• Очень легко скатиться в продавливание

Грех №3 Приверженность к ранним оценкам в конусе неопределенности

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

Самые точные оценки — поздние.

Грех №4 Предположение, что недооценка не влияет на результаты проекта

Ошибки планирования влияют нелинейно на проект. С течением времени накапливаются ошибки и дефекты, а также начинают все чаще выстреливать риски.

Грех №5 Оценка в «Невозможной зоне»

Загадка

• Предположим, вы едете вверх по холму 1 милю со скоростью 30 миль в час.

• Как быстро вам нужно ехать вниз по холму, чтобы в среднем за всю поездку средняя скорость составляла 60 миль в час?»

Вариация на тему греха #5

Общепринятное определение оценки гласит: ‘Оценка — это самое оптимистичное предсказание, которое имеет ненулевую вероятность сбыться’… Принятие этого определения неизбежно приводит к методу, называемому «какая самая ранняя дата, когда вы не можете доказать, что не закончите оценивание».

Том ДеМарко (1982)

Оценки — это вероятностные утверждения.

Что происходит, когда вы берете номинальную оценку и сжимаете ее? Не существует такого понятия, как «оценка в одной точке», которая была бы правильной или имела бы смысл. Все оценки включают по крайней мере неявные вероятности (даже если оценщик этого не знает).

Сжатие расписания и «Невозможная зона».

Компромисс между затратами и графиком.

Все исследователи находят некоторый компромисс между сжатием графика и затратами. Никто не считает, что компромисса нет. Предполагается, что максимально возможное сжатие графика составляет около 25%.»

Тут вспоминается старый пост: https://t.me/junior_pm/17

Не создавайте оценки в «невозможной зоне».

Вернемся к вопросу. Какое решение загадки?

Грех №6 Переоценка полезности от новых инструментов

Полезный эффект от новых инструментов или методов есть Есть и проблемы:

• Необходимо заплатить цену за обучение при первом использовании

• Максимальная эффективность не достигается при первом использовании

• Первое использование часто сопряжено с ошибками

• Ранние заявления об эффективности часто основаны на экспертном использовании — иногда разработчиками или авторами, изобретшими инструмент или метод!

• Результат меньше ожидаемого, когда он появляется

• Новые инструменты и методы увеличивают риски

Лучшее предположение — потери производительности от начального использования нового инструмента или метода.

Грех №7 Использование только одного метода оценки

Используйте несколько методов:

• Сложно быть уверенным в оценках, созданных только одним методом, — это способствует проблеме «энергичной защиты» Брукса.

• Ведущие организации используют несколько техник оценки.

• Создавайте оценки разными способами и ищите сходимость или разброс между оценками.

Грех №8 Не использование программного обеспечения для оценки

Используйте программное обеспечение для оценки:

• Лучшая поддержка для науки оценки — это инструменты.

• Оценки, созданные с помощью инструментов, могут иметь большую достоверность, чем оценки, созданные вручную.

• Хорошие инструменты для работы с оценками: https://github.com/FocusedObjective/FocusedObjective.Resources

Грех №9 Не включение в оценку влияния рисков

Учет рисков при оценке:

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

• Общий риск (RE) — это ожидаемое значение перерасхода бюджета на проекте.

• Оценка RE — это там, где начинается «буферное планирование».

Грех №10 Предоставление импровизированных оценок

Обращайтесь к оценке как к мини‑проекту.

Определите стандартизированную процедуру оценки.

Элементы стандартизированной процедуры:

• Четкое описание неопределенности оценки.

• Использование нескольких подходов к оценке.

• План повторной оценки на заранее определенных этапах проекта.

• Определение момента, когда «оценки» становятся «обязательствами».

Разбивайте большие оценки на меньшие оценки.

Разделяйте системы на модули Разделяйте большие задачи на маленькие задачи Используйте статистическое свойство, называемое «законом больших чисел» — высокие и низкие значения склонны уравновешиваться друг друга.

Заключение

• Плохие оценки (или цели) — это норма.

• Возможны хорошие оценки!

• Представленные здесь смертные грехи и эмпирические правила — это только верхушка айсберга.

Несмертные грехи, но тоже грехи

Грехи №20– №11

Грех №20

Давать оценку «этого», чтобы составить план прежде чем кто‑либо узнает, что «это».

Грех №19

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

Грех №18

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

Грех №17

Строить планы на новый проект опираясь на первоначальный план прошлого проекта. Игнорируйте фактические сроки и прошлый опыт.

Грех №16

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

Грех №15

Давайте оценку, игнорируя рабочие моменты:

• посещение встреч…

• переключения на другие проекты…

• поддержку ключевых клиентов…

• отпуска…

• болезни…

• чрезвычайные ситуации…

Грех №14

Представлять оценки с высокой степенью точности («67,5 часа»), которые поддерживаются только низкой степенью точности («±2 месяца»).

Грех №13

Считать, что инструменты оценки (такие как Монте‑Карло) не могут сравниться с вычислительной мощностью из системы менеджера, ручки и салфетки.

Грех №12

Рассуждать так: «Чем раньше мы профакапим сроки, тем больше времени у нас будет на их опережение».

Грех №11

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