День 2083. #УрокиРазработки
Уроки 50 Лет Разработки ПО

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

Характеристики ПО
Чтобы проанализировать опыт предыдущих проектов и составить более обоснованные планы, необходимо собрать некоторые характеристики. Люди могут измерять различные аспекты программных проектов на трёх уровнях: индивидуальный участник, проектная группа и организация-разработчик.

Знание следующих характеристик может дать довольно полное представление о вашей работе:
1. Объём
Выберите некую меру размера, значимую для той работы, которую вы выполняете. Это может быть количество требований, пунктов в списке функциональных особенностей, пользовательских историй, классов и количество строк исходного кода (хотя последний пункт выглядит довольно сомнительным).

2. Трудозатраты
Фиксируйте трудозатраты, необходимые для создания каждого проекта или отдельной его части. Понимая возможные трудозатраты и зная объём работы, вы сможете рассчитать производительность.

3. Время
Запишите расчётную и фактическую продолжительность выполнения работ в единицах календарного времени. На преобразование рабочих усилий в календарное время влияет большое количество факторов.

4. Уровень качества
Подсчёт дефектов, обнаруженных различными способами, показывает, с помощью каких методов обеспечения качества лучше выявлять ошибки и где можно изыскать дополнительные резервы для улучшения качества. Учёт времени, затраченного на доработку и исправление дефектов, тоже помогает в планировании. Если вы знаете, где возникла ошибка (конкретная итерация, требование или действие), то будете более отчётливо понимать, на чём следует сосредоточить дополнительные усилия, чтобы обеспечить качество в будущем.

В своей книге «Сколько стоит программный проект» Стив Макконнелл указывает на многочисленные проблемы, связанные с мерами измерения в каждой из этих категорий. Макконнелл подчёркивает важность чёткого определения каждой собираемой метрики, что позволяет людям записывать данные в единообразной форме. Если вы не сравниваете результаты с внешним эталоном, то согласованность внутренних измерений важнее абсолютной истины. Например, все члены команды должны одинаково оценивать свои усилия и подсчитывать дефекты. Предположим, одни члены команды добавляют время на отладку и доработку в общее время разработки, другие относят их к этапу тестирования, а третьи вообще не учитывают его. Такое смешивание не способствует обоснованному предсказанию будущего.

Необходимость записывать метрики, характеризующие ПО, нервирует некоторых людей. Определение характеристик ПО действительно является деликатной областью с множеством потенциальных ловушек. Золотое правило гласит, что данные нужно использовать для изучения и совершенствования, а не для наказания или вознаграждения кого-либо. Людей также часто беспокоит необходимость тратить время на сбор и анализ данных, но, как показывает опыт, запись базовой информации о проектной деятельности не требует особых затрат. Эта привычка быстро становится частью рабочего процесса.

Итого
Спустя долгое время после завершения работы у вас не получится точно восстановить её характеристики. Поэтому создайте механизмы для сбора и сохранения данных по мере продвижения. Ретроспектива в конце цикла разработки даёт хорошую возможность собрать данные для оценки прошлого и планирования будущего. Если вы потратите немного времени на запись происходившего сегодня, то завтра у вас будут исторические данные, которые помогут оценить следующую часть работы.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.