Разработка ПО: дороже не значит лучше

Компания Quantitative Software Management (QSM) провела специальное исследование, чтобы выяснить эффективность методов ускорения разработки ПО.

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

 Изучив работу маленьких (5 и менее человек) и больших (20 и более человек) команд, разрабатывающих от 10 до 200 тысяч строчек кода, принимая во внимание такие параметры, как количество разработанных строк, соответствие расписанию и процент сделанных ошибок, специалисты QSM пришли к неожиданным выводам. Оказалось, что разработка 40 тысяч строк кода большой (29 человек) и маленькой (3 человека) командами оканчивается с разницей всего в 12 дней. При этом работы большой команды оцениваются в 191 человеко-месяц, маленькой — лишь 40, а разница по бюджету составила $1,8 миллиона. Такие затраты оправданы только в случае, если за «выигранные» подобным способом 12 дней использование результатов проекта принесет компании больше указанной суммы.

Одной из причин столь низкого роста продуктивности является тот факт, что большие команды делают почти в шесть раз больше ошибок, чем маленькие, а следовательно, увеличивается время, затраченное на их поиск, исправление и новое тестирование. Нетрудно подсчитать: при увеличении числа разработчиков почти в 12 раз, количество ошибок возросло в пропорции 2:1.

 Качество работы снижается, в частности, из-за слишком мелкой дефрагментации работ в большой команде. По этой причине растет число ошибок, вызванных отсутствием видения «общей картины» у каждого отдельного разработчика, найти и исправить которые можно лишь после того, как все «фрагменты» будут собраны воедино. В целом, эффективность работы в большой команде падает по вполне объяснимым причинам. Очевидно, что для координации работ в команде из 20 человек понадобятся специальные совещания, продуманные системы распространения информации, а следовательно, дополнительное время и ресурсы, которые просто не нужны в команде из 3 человек, где все вопросы можно решить оперативно.

 Таким образом, согласно приведенным данным, увеличение ресурсов значительно увеличивает стоимость проекта, но при этом не дает значительного сокращения сроков и негативно сказывается на качестве.