Тут важно с умом подходить к измерениям и к выбору метрик. Если метрика будет «точность попадания в оценку», например, то с рестом уже не будет такой ситуации. То, что люди разные, ещё Дедушка Брукс доказал и показал, когда деревья были сильно меньше. Это факт. Принимать решения только на основе цифр, которые тебе дала спец.тулза или экселька — путь в ад. Но мерять однозначно нужно и анализировать результаты тоже.
Все так. Но с определенного момента такой метод перестаёт давать ответы на интересующие вопросы, либо даёт большую погрешность. И вот здесь уже приходится подбирать измерения под себя и свою команду.
Здесь акцент стоит сделать на «целый квартал» и «почти 100%». Для небольших проектов — это и правда часто страшилка из книжек, а для больших — суровая правда жизни.
Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.
По опыту в большинстве проектов фиг кто даст выделить время и отдать часть итерации под техдолг. Почему-то считается, что это вообще не проблемы бизнеса. Мы пробовали разные сценарии: парко-хозяйственный день, когда 20% итерации идёт на техдолг (не очень работает), технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это). Аджайл в идеальном мире действительно не про это, но в реальном мире часто все идёт именно по пути замены требований по пути. Тоже самое касается внесения новых задач в уже стартанувшую итерацию. Интересен именно нехороший сценарий.
Выходит, что признание долгом долга вещь сугубо субъективная, я верно понял? Т.е. в задах системы живет пачка овнокода, но поскольку она работает и жить не мешает — она признается нормой?
Вспомнилось «highly likely”:))) Документация часто сама является техдолгом, потому как написать-написали, а поддерживать забыли:))
Спасибо за материал, тема, безусловно необъятная, и в одну статью не влезет, есть пара вопросов:
Вот вы пишете, что аджайл помогает решать проблему техдолга за счёт итераций и дробления скоупа. Но ведь тот же аджайл допускает изменения по ходу дела в пользу лучшего продукта здесь и сейчас. Как быть в такой ситуации? Ведь изменяющиеся постоянно требования в угоду рынку и есть причина отсутствия чёткой реализации и обилия костылей.
Мне кажется, что часто отменяющийся код хорош тем, что его часто читают разные скорее всего люди. Ведь тот код, который запилили на скорую руку с костылем или без и ушли из него надолго, закопав стюардессу, есть имхо основной источник техдолга и неожиданных эффектов в будущем, наряду с изменяющимися требованиями и нехорошей архитектурой кода, которую почему-то не упомянули. Вы каким-то образом решаете задачу отслеживания долга в таких случаях?
Куда-то подевалась мать всех костылей — плохая архитектура самого приложения и отдельно взятых модулей. Когда любое расширение несёт за собой боль и страдания. Но при этом вы указали документацию и отсутствие комментариев в коде, что само по себе не является маркером технического долга. Не могли бы вы прокомментировать, как предложенные методы помогут решить вопрос плохой архитектуры?
В массе своей это лишь говорит о том, что не читают и не слушают. Либо читают и слушают, но формат для должного восприятия не тот. Вот и эксперементируют все понемногу. Кому-то и это чтиво принесёт пользу, я надеюсь. Ваше же комментарии точно принесут пользу мне.
Пожалуйста:) Рад, что понравилось. Про вред глобальных переменных статей много, а переменных при этом меньше не становится. Про структуру программ тоже все знают, но код говорит про обратное. Про фреймворки рассказывали немало, а проблем при этом меньше не стало.
Про детали: когда вы упрётесь в проблему, что тормозит не тот код, который вы писали, а то, что под ним — тогда вы почувствуете этот минус.
Тут важно с умом подходить к измерениям и к выбору метрик. Если метрика будет «точность попадания в оценку», например, то с рестом уже не будет такой ситуации. То, что люди разные, ещё Дедушка Брукс доказал и показал, когда деревья были сильно меньше. Это факт. Принимать решения только на основе цифр, которые тебе дала спец.тулза или экселька — путь в ад. Но мерять однозначно нужно и анализировать результаты тоже.
Все так. Но с определенного момента такой метод перестаёт давать ответы на интересующие вопросы, либо даёт большую погрешность. И вот здесь уже приходится подбирать измерения под себя и свою команду.
Здесь акцент стоит сделать на «целый квартал» и «почти 100%». Для небольших проектов — это и правда часто страшилка из книжек, а для больших — суровая правда жизни.
Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.
Согласен, но если начать интерпретировать и выравнивать кривые фразы, всегда есть шанс подменить смысл. В любом случае учту на будущее.
Про аджайл спорить не буду, до не тот топик.
В п.2 меняющийся, вместо «отменяющийся». Прошу прощения.
Спасибо за материал, тема, безусловно необъятная, и в одну статью не влезет, есть пара вопросов:
Спасибо!
Про детали: когда вы упрётесь в проблему, что тормозит не тот код, который вы писали, а то, что под ним — тогда вы почувствуете этот минус.