Паша, Вы ж умный человек.

Делать ревью или нет, «покупать» еще 2 джуна, фиксить ли баги, рефакторить — просчитывается финансово.
Цепочка: ч/ч * на стоимость человека и так по каждому пункту.
Сравнили. Посчитали когда окупится выбранное решение. Реализовали.

Profit.

без метрик рассматривать просто нечего

Угу. Примеры метрик я приводил выше.

— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)

«какова вероятность встретить динозавра? — 50%. или встречу или нет.»

каждую на задачу обязательно должно было быть review от другого разработчика твоего ранга или выше

Вот конкретный вариант. Без динозавров. Ну, разве что с «динозаврами» в виде древних кусков исходников.

Это точка зрения QA, которые тестируют методом черного ящика.

Не только. Есть у меня в арсенале несколько толковых людей (реально толковых) который склонны нести подобную мысль в массы. Лучше пусть будет хоть что-то покрыто тестами, чем не будет покрыто ничего. Лучше пусть тест будет функциональным и покроет 5% функционала, но уже на эти 5% функционала можно опереться.

Без Unit не обойтись никак

О, ДА! А вот если их нет и их внедрение долго и невозможно, а с первого раза еще и не получается потому что ... (о, боже, сколько тут разных вариантов) ... и нужно с чего-то начать...
Ну и начинаем. Вот, например, с итерационки. Тоже нереально? Сильно связаны модули? Ну хорошо, тогда пусть это будет функционалка. Не попадайтесь в петлю «мы не можем начать рефакторить, у нас нет тестов, но мы не можем писать тесты, т.к. там ужас и мрак и нужен рефакторинг».

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

И это чистая правда! Значит вероятность подрыва растет.
бабах.... а вот и он!

Pavel Kruchina предлагал говорить не про абсолютные значени, а о процентах и тенденциях.

Да нивапрос. Метрики то у всех разные )

— Какой нормальный уровень (%) соотношения «шума» и фич?

1/10.
Почему?
Так получилось.

— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)
— Какой подход эффективнее и насколько: постоянный рефакторинг (каждый месяц) или рефакторинг при падении разработки на критический процент.

Нет ответа. Было несколько практик. И несколько практик было успешных.
1 день в неделю. Хороший ответ? Да. А, нет. Или да. Проверяли — работает.
А было такое, что каждую на задачу обязательно должно было быть review от другого разработчика твоего ранга или выше. Хороший ответ? Нет. Или да. Проверяли — работает. И хорошо работает.
А было такое, что вообще нет review. Меряли показатели эффективности функционала. Количество метрик зашкаливало там за 100. Метрики не удовлетворяли условию — выкинули функционал, выпилили, перепили заново или забыли и пилим другой. Хороший ответ? Да не знаю я уже. Но ведь работает же! Ну реально ж работает. Именно такой подход приносил наибольшую прибыль.

— Какой процент падения эффективности разработки является критическим (требует немедленно переходить к рефакторингу)

Никакой! А иногда любой. Но я больше склоняюсь к варианту никакой. Сначала разбираемся в причинах падения эффективности. Да может ребятам банально в отпуск нужно. А не... тут другая причина. Просто з/п не привязана к доллару, а курс вырос и у ребят пропала мотивация. Стали медленнее работать. А у команды из 3-го кабинете вообще третья причина.
Но когда ж тогда переходить к рефакторингу? Как вариант — всегда. (примеры есть выше). Или как вариант — никогда. (примеры есть выше). Или когда 3 из 5-ти разработчиков скажут, что этот модуль тяжело поддерживать. Технологии не те уже и еще 100500 причин. Вот тогда рефакторим. Но не весь проект, а только этот модуль. Отлично так и запишем. Цифра — 3/5 — на нее и будем ориентироваться.

---

Дак о каких процентах и тенденциях может идти речь, если мы уже перешли на цифры, не привязав их к конкретным случаям?

PS

Как я предупреждал выше — это мнение конкретно взятого человека и оно может (и должно) отличатся от любого другого мнения любого другого конкретно взятого человека (или группы людей).

©

Для рефакторинга нужно покрытие тестами, для плохого проекта это принципиально невозможно покрыть тестами все места, которые будете менять.

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

Отличный комментарий! Однозначно плюс.

Сейчас попробую частично со своей колокольни «фонариком посветить».
Первое. Какой бы крутой не был код, какие бы крутые спецы не работали на проекте, как бы круто его не вылизывали/рефакторили/переписывали и.т.д. — успешность или не успешность проекта определяют клиенты. Да. Бабло! Если этого понимания нет — поздравляю, вы пилите yet another фича-в-себе. Круто вылизанную, но нафиг никому не нужную.

Но тут, как я вижу, понимание клиента во главе есть.
А значит есть и построенная цепочка клиент -> функционал -> задачи -> (yet another profit ex. refactoring).
Вот тут и подходим к вопросу эффективности.
Нужно мерять. Что мерять? Как мерять?
Дальше будет ИМХО, которое может идти в разрез с любым другим мнением. (если что — я предупредил)
Первое — меряем маркетинг(!). Посетителей, клиентов, продажи, конверсии, затраты и.т.д. Это основные показатели при принятии любого решения.
Дальше меряем производительность системы. Скорость работы скрипта/модуля, «отклик» базы данных, «отклик» API, количество обрабатываемых запросов в секунду, и.т.д.
А теперь меряем «эффективность команды».
Вот тут мерять можно от забора и до обеда.
— количество закрытых задач (для того чтобы правильно это мерять, должны быть правильные задачи, а не задача-простыня на +/-20 дней работы)
— количество баг-тикетов
— количество reopen тикетов
А что там у нас еще есть? (у каждого свое)
— среднее кол-во времени на типичную задачу
— % покрытия тестами
— стабильность тестов
— количество строчек кода (нет, не прикалываюсь. да, видел)
— количество коммитов в репу
и.т.д.

Под каждый продукт у каждой компании свои метрики.
Главное понимать что значит та или иная метрика.

Что делаем дальше? Реагируем на показатели метрик. Тех что написаны выше, или тех что написаны где-то в другом месте, или те что еще не написаны, но есть где-то в голове у руководящего состава.
Сразу говорю — реагировать нужно не на все. Но причину изменения понимать нужно.
Меньше коммитов? Ну и ладно. Просто мы избавились от микрокоммитов и пушим только готовые задачи.
Больше/меньше строчек кода? Больше баг-тикетов стало прилетать? Так мы весь месяц занимались тем, что выкатывали новый функционал и забили на поддержку.
Решаем каждое изменение метрики индивидуально.

Посему, буду краток:

Так вот, предлагаю о этих цифрах и поговорить.

— 300
— что 300?
— а что приборы?
©
Я готов говорить цифрами, но это будут цифры привязанные к конкретно заданному проекту, с конкретно заданными требованиями, для конкретно взятых людей, в конкретно взятый промежуток времени. Иначе, я считаю, это опять будут сферические кони в вакууме.

Как я предупреждал выше — это мнение конкретно взятого человека и оно может (и должно) отличатся от любого другого мнения любого другого конкретно взятого человека (или группы людей).

-

Очень информативно и аргументированно. А главное ёмко и предельно лаконично.

требуется абсолютная культурность сотрудников

Можно потренировать их на игре в манчкина :)) Если небыло опыта этой игры — просто рекомендую для себя поиграть. Даже могу при желании пригласить поиграть в уютной домашней обстановке. Все равно все закончится «социальной неадекватностью».

проведите консультации со сторонним системным архитектором и аналитиком

Как это предполагается реализовывать.

Такие решения чаще всего (даже не так. читай НИКОГДА) не исходят от разработчиков, а исходят от инвесторов, владельцев бизнеса и.т.д.
Руководство видит проблему: упали продажи, упала посещаемость, не успеваем пилить новую функциональность, частые жалобы на старую функциональность ... индикатором может быть абсолютно любой внешний фактор (реже внутренний, например раздраженный сотрудник).
Теперь что подразумевается под «консультацией со стороны»:
1) Есть компании, которые предоставляют сторонний аудит продукта/процессов/архитектуры. Знаю не по наслышке. В свое время одна из компаний, в которых я работал, заказывала такой аудит со стороны. Да, делался он не один день. «Подрядчики» вникали во все, начиная от бизнес процессов, точек прибыли, архитектуры, постановки задач и.т.д.
Относительно недавно (в течении последнего года) натыкался на человека, который специализировался на code reviw, основал компанию и занимался внешним консультированием как правильно внедрять эту практику у себя в компании. Очень бы хотел сразу дать ссылки на это видео, но найти не могу. Найду — сброшу дополнительным комментарием.
2) «Бен! Это Данила! Ай нид хелп!» © Брат-2
В качестве Бена часто выступает знакомый(-ая), который(-ая) СПЕЦИАЛИСТ (с большой буквы реже) или «специалист» (в кавычках чаще) в требуемой отрасли. Получаем набор советов, что делалось, как, почему, к чему это привело и получив волшебный пендель бежим и нагибаем всех и все на проекте.
Ну, говорю как есть. И такое тоже поголовно у всех было.
3) Гораздо реже, чем предыдущие варианты, но и такое встречалось.
Ищется на самом деле требуемый Специалист, ставятся конкретные задачи, получаются конкретные ответы/решения, договорная оплата, спасибо, разошлись.
Примеры: 3.1) habrahabr.ru/.../AntonShevchuk + Yandex. Результат — yandex-php-library
3.2) youtu.be/dx_6oVFuP8Y — тут @yakov_sirotkin рассказывает пару слов о том, как они в свой проект привлекали Антона Коробейникова (anton.korobeynikov.info) (человек который внес свой вклад в gcc). Хотя видео не об этом. Совсем не об этом, но идею по 3-му пункту оттуда уловить можно.
Примеров тут подобрать можно много. Они имеют место быть. Вернее место быть они имеют не только лишь много. © КличкоМем

И второе:

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

— Шеф, все пропало, все пропало! Гипс снимают, клиент уезжает!
— СПОКОЙНО!
---
Решаем проблемы по мере поступления.
Если в проекте изначально все поставлено на нужные рельсы, то и проблем быть не должно... хотя... господи, ну кому я вру?
Всегда. Опять же в моем опыте. Ну вот всегда. Функционал устаревает. Модуль не расчитан на те нагрузки, под которыми он сейчас работает. Это писал Вася Пупкин, никто не знает как оно работает, а Васи уже нет.
Это я к чему. Возможно Вы правы, но... рано или поздно я ВСЕГДА попадал на проекте в ситуацию «шеф, все пропало!», с какими бы благими намерениями не создавался бы функционал/код/что-то еще — жди, то что ты написал вчера — завтра уже «с душком» (читай пропало!). Этот долбанный мир слишком быстро крутится. Новых технологий слишком много. Эти новые фичи так быстро устаревают. Блин! Пора смириться и быть честным с собой.
/me задумался и ушел медитировать (скоро вернусь).

Рецепт универсальный: деньги + полномочия.

В теории, а на практике

Андерс Хейлсберг (просто оставлю это имя здесь)
Если залезть в гугл можно найти еще больше примеров.
Или, например, такие цифры: «65% компаний переманивают ценных сотрудников у конкурентов»
Богдан, везде есть контр. примеры и универсального нету ничего. В каждой компании будет свой опыт и свои исключения.

Это 2 принципиально разных момента... «Неинтересно сопровождать» — это как раз проявление некомпетентности (инфантильности)

В большинстве случаев — да. Согласен. Чаще всего проблема «неинтересно» на уровне квалификации разработчика. Гораздо реже — проблема на уровне квалификации менеджемнта.

Сторонний человек не будет обладать всей необходимой информацией о проекте для принятия решения.

Если свои не в состоянии... Есть люди и компании, которые построили серьезный бизнес именно на такого рода консультациях. И первым этапом идет именно сбор информации.

Переписывание с нуля, как правило, просто не работает для проектов которые в продавшее уже давно.

Но и контр примеры же есть: PHP (да, opensource, но было же), VOX, Magento (сейчас пилится вторая версия). Тот же facebook переписал интерфейс групп в 10-ом году с нуля.

Везде (!) нужно смотреть конкретно по ситуации. А для того чтобы небыло

просто заипетесь

можно переписывать модульно. Если вообще есть такая необходимость переписывать с нуля.