Вопрос в контексте Agile разработки по ТЗ, которое может изменяться по ходу проекта. Нередко используют почасовую оплату за потраченное разработчиком время, а я предлагаю вместо этого в контексте поставленной задачи осуществлять биллинг за проделанную работу с помощью учёта количества строк кода, написанного для решения задачи.
Как думаете, сколько стоит качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices и т.п.?
Если оценивать построчно, подразумевается, что получается максимально компактный, эффективный код без читерства и копи пасты, максимально использующий готовые компоненты, стеки и тулсеты.
Преимущества учета стоимости кода по количеству написанных строк в Agile-проекте
Учет стоимости кода по количеству написанных строк – подход, который периодически обсуждается в IT-среде, в том числе и в вашем прикреплённом обсуждении. Хотя в современной разработке этот метод считается спорным и не всегда применимым, у него есть определённые преимущества, особенно если речь идёт о специфических задачах (например, DevOps-скрипты, IaC, CLI-утилиты) и при правильной постановке процесса.
1. Прозрачность и простота расчётов
- Лёгкость измерения: Количество строк кода – объективный, легко измеряемый показатель, который можно быстро получить с помощью инструментов анализа кода.
- Понятная метрика для заказчика: Заказчик может видеть «осязаемый» результат работы, что важно для непогружённых в детали разработки людей.
2. Мотивация к эффективности
- Фокус на результат: Такой подход мотивирует разработчика не растягивать задачи, а выдавать конкретный, измеримый результат.
- Возможность сравнения: Можно сравнивать производительность между разными исполнителями или командами, если задачи типовые и стандартизированы.
3. Гибкость при изменении требований (Agile)
- Простота пересчёта стоимости: При изменении требований (что часто бывает в Agile), можно быстро пересчитать стоимость, исходя из нового объёма кода.
- Удобство для коротких итераций: В спринтах, где задачи дробятся на небольшие части, оплата по строкам может быть удобна для микрозадач (например, написание шаблонов, конфигов, скриптов).
4. Контроль качества (при правильной постановке)
- Возможность учёта сложности: Если в стоимость строки закладывается качество (DRY, тесты, best practices), появляется стимул писать лаконичный и качественный код.
- Быстрая оценка вклада: В проектах с большим количеством рутинных изменений (например, поддержка DevOps-инфраструктуры), этот подход позволяет быстро оценить вклад каждого разработчика.
5. Применимость к DevOps и инфраструктурным задачам
- Стандартизированные задачи: В DevOps часто встречаются задачи, где результат – это скрипт или конфиг, и их объём хорошо коррелирует с трудозатратами.
- Меньше риска «раздувания» кода: Если стоимость строки высокая и есть контроль качества (ревью, автоматические проверки), разработчики заинтересованы писать компактно и эффективно.
Важно!
- Подход не универсален: Для сложных R&D-задач, архитектурных решений, оптимизаций, где ценность кода не в количестве, а в качестве и уникальности, этот метод не подходит.
- Риски злоупотреблений: Без контроля качества возможен «честинг» – искусственное раздувание кода, копипаст, бессмысленные строки.
- Лучше использовать в сочетании с другими метриками: Например, с оплатой за закрытие задач, code review, покрытие тестами и т.п.
Вывод
Учет стоимости кода по количеству строк может быть полезен в узких случаях – для стандартизированных, повторяющихся задач, особенно в области DevOps и инфраструктуры, при условии жёсткого контроля качества и прозрачных критериев оценки. В рамках Agile такой подход может упростить биллинг и сделать процесс более предсказуемым для обеих сторон, однако его не стоит рассматривать как универсальное решение для всех типов проектов.
