Искусство и наука об оценки в 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
Утверждать, что разработчики могут научить лучше оценивать. Выносить это как решения с ретроспективы
