Искусство и наука об оценки в IT: Наука оценки хорошо развита и хорошо поддерживается программными инструментами. Искусство оценки преимущественно основано на эмпирических правилах и их еще нужно немного доработать. Эта статья основана на материалах Steve McConnell из Construx и часть материалов как были остались картинками. Проводите различия: Установка целей — ключевая часть искусства оценивания. Когда вас попросят дать оценку, определите, действительно ли вы должны оценивать или лучше выяснить, как достичь цели. Лучше всего рассматривать это как итеративный процесс который выравнивание цели и оценки. Почему разработчики говорят «да». Очень трудно составить энергичную, правдоподобную и рискованную защиту оценки, которая не основана на количественных методах, подтверждена небольшим количеством данных и заверена в основном догадками менеджеров. Фред Брукс (1975)  Особенности коммуникаций в компании: Разработчики программного обеспечения, как правило, интроверты и относительно молоды Специалисты по маркетингу и продажам, как правило, более экстравертны и организационно выше разработчиков, с которыми они договариваются Очень легко скатиться в продавливание Брать на себя обязательства можно только по оценкам на поздних этапах, когда вы понимаете суть работы. Самые точные оценки — поздние. Ошибки планирования влияют нелинейно на проект. С течением времени накапливаются ошибки и дефекты, а также начинают все чаще выстреливать риски. Загадка Предположим, вы едете вверх по холму 1 милю со скоростью 30 миль в час. Как быстро вам нужно ехать вниз по холму, чтобы в среднем за всю поездку средняя скорость составляла 60 миль в час?" Вариация на тему греха #5   Общепринятное определение оценки гласит: 'Оценка — это самое оптимистичное предсказание, которое имеет ненулевую вероятность сбыться'... Принятие этого определения неизбежно приводит к методу, называемому «какая самая ранняя дата, когда вы не можете доказать, что не закончите оценивание».  Том ДеМарко (1982)  Оценки — это вероятностные утверждения. Что происходит, когда вы берете номинальную оценку и сжимаете ее? Не существует такого понятия, как «оценка в одной точке», которая была бы правильной или имела бы смысл. Все оценки включают по крайней мере неявные вероятности (даже если оценщик этого не знает). Сжатие расписания и "Невозможная зона". Компромисс между затратами и графиком. Все исследователи находят некоторый компромисс между сжатием графика и затратами. Никто не считает, что компромисса нет. Предполагается, что максимально возможное сжатие графика составляет около 25%.» Тут вспоминается старый пост: https://t.me/junior_pm/17 Не создавайте оценки в «невозможной зоне». Вернемся к вопросу. Какое решение загадки? Полезный эффект от новых инструментов или методов есть Есть и проблемы: Необходимо заплатить цену за обучение при первом использовании Максимальная эффективность не достигается при первом использовании Первое использование часто сопряжено с ошибками Ранние заявления об эффективности часто основаны на экспертном использовании - иногда разработчиками или авторами, изобретшими инструмент или метод! Результат меньше ожидаемого, когда он появляется Новые инструменты и методы увеличивают риски Лучшее предположение — потери производительности от начального использования нового инструмента или метода. Используйте несколько методов: Сложно быть уверенным в оценках, созданных только одним методом, — это способствует проблеме «энергичной защиты» Брукса. Ведущие организации используют несколько техник оценки. Создавайте оценки разными способами и ищите сходимость или разброс между оценками. Используйте программное обеспечение для оценки: Лучшая поддержка для науки оценки — это инструменты. Оценки, созданные с помощью инструментов, могут иметь большую достоверность, чем оценки, созданные вручную. Хорошие инструменты для работы с оценками: https://github.com/FocusedObjective/FocusedObjective.Resources Учет рисков при оценке: Проекты по разработке программного обеспечения по своей природе нестабильны и связаны с рисками. Общий риск (RE) — это ожидаемое значение перерасхода бюджета на проекте. Оценка RE — это там, где начинается «буферное планирование». Обращайтесь к оценке как к мини‑проекту. Определите стандартизированную процедуру оценки. Элементы стандартизированной процедуры: Четкое описание неопределенности оценки. Использование нескольких подходов к оценке. План повторной оценки на заранее определенных этапах проекта. Определение момента, когда «оценки» становятся «обязательствами». Разбивайте большие оценки на меньшие оценки. Разделяйте системы на модули Разделяйте большие задачи на маленькие задачи Используйте статистическое свойство, называемое «законом больших чисел» — высокие и низкие значения склонны уравновешиваться друг друга. Плохие оценки (или цели) — это норма. Возможны хорошие оценки! Представленные здесь смертные грехи и эмпирические правила — это только верхушка айсберга. Давать оценку «этого», чтобы составить план прежде чем кто‑либо узнает, что «это». Верить, что наиболее достоверные оценки происходят от людей с наиболее мощными голосовыми связками. Думать что все оценки конвертируются друг в друга. Переводить деньги в календарные сроки и сторипойнты в дни. Строить планы на новый проект опираясь на первоначальный план прошлого проекта. Игнорируйте фактические сроки и прошлый опыт. Предполагать, что отдел продаж лучше оценивает программные проекты, чем разработчики. Давайте оценку, игнорируя рабочие моменты: посещение встреч... переключения на другие проекты... поддержку ключевых клиентов... отпуска... болезни... чрезвычайные ситуации... Представлять оценки с высокой степенью точности («67,5 часа»), которые поддерживаются только низкой степенью точности («±2 месяца»). Считать, что инструменты оценки (такие как Монте‑Карло) не могут сравниться с вычислительной мощностью из системы менеджера, ручки и салфетки. Рассуждать так: «Чем раньше мы профакапим сроки, тем больше времени у нас будет на их опережение». Утверждать, что разработчики могут научить лучше оценивать. Выносить это как решения с ретроспективы.  Scrum master