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

Урок 44. Высокое качество естественным образом ведет к повышению продуктивности. Начало

Разработчики ПО хотели бы работать более продуктивно. Но этому могут мешать многие факторы, и проблемы с качеством — главный. Команды планируют выполнить установленный объём работы за определённое время, но затем им приходится устранять проблемы, обнаруженные в завершённом проекте, или выделять время на исправление работающей системы. Один из способов повысить продуктивность — создавать качественное ПО с самого начала.

Существуют два основных вида доработок ПО: исправление дефектов и погашение технического долга. Ранее мы рассмотрели, как со временем растут затраты на исправление дефектов. Точно так же чем дольше в коде сохраняются недостатки, тем больше накапливается технического долга и тем больше работы требуется для улучшения проектного решения. Рефакторинг упрощает поддержку и расширение кода, но иногда код необходимо рефакторить лишь потому, что он был создан в спешке на основе далеко не идеального проекта. Объёмная непредвиденная доработка — пустая трата времени, которая отвлекает разработчиков от создания дополнительной ценности для клиентов.

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

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

Организации, подсчитывающие, сколько сил и средств уходит на доработку ПО, могут получить пугающие цифры. Различные исследования показывают, что это может быть от 40 до 50% времени. Только подумайте, как подскочила бы продуктивность вашей команды, если бы они могли дополнительно тратить треть своего времени для разработки чего-то нового!

Если вы фиксируете некие показатели, характеризующие затраты на разработку, то постарайтесь отделить затраты на поиск дефектов от затрат на их устранение. Узнайте, сколько времени вы тратите на доработку, когда и почему. Эти данные раскрывают широкие возможности для повышения продуктивности. Спойлер: до 85% затрат на доработку приходится на дефекты в требованиях. Наличие неких исходных данных о затратах на доработку позволит вам наметить цели для улучшения и увидеть, снижают ли более совершенные процессы и методы разработки необходимость в доработках.

Окончание следует…

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