Т.е. это обозначает, что бизнес и разработка всегда будут «говорить» про одно и то же. Если бизнес говорит «Заказ», то разработка понимает, что речь идёт о микросервисе «Заказ». Если бизнес говорит «Корзина», то разработка понимает, что речь идёт о микросервисе «Корзина». Если бизнес говорит «Поставка», то речь о микросервисе «Поставка».
Крайне рекомендую автору статьи и всем заинтересовавшимся посмотреть выступление https://www.youtube.com/watch?v=hev65ozmYPI ("All your aggregates are wrong") . В докладе рассматривается буквально такой же подбор компонентов как в упомянутой цитате, с разбором почему такое структурирование может вылиться в проблемы с работой и поддержкой системы.
По поводу модулей и зависимостей. Я думаю хорошая модель для объяснения и для нахождения плохо-спроектированных модулей это 1 - Coupling/Cohesion - модули должны иметь как можно меньше связей с другими модулям, а связанность должна быть инкапсулирована внутри модулей. 2 - Afferent/Efferent coupling - количество входящих/исходящий зависимостей классов/модулей. Если класс стабильный и от него многие зависят = ок, делать такой класс зависимым от других и следовательно менее стабильным = не ок.
Подробно не расписываю, рекомендую просто погуглить + небольшие книжки Роберта Матрина где он определяет эти понятия, разобраться с типами связанности. Плюсы такой модели в том что есть готовые инструменты которые автоматически подсчитают упомянутые метрики, и дадут хорошую базу для обсуждения возможного рефакторинга. Так же пользу упомянутых моделей легко объяснить исходя из предпосылки что держать в уме содержимое одного модуля проще проще чем содержимое нескольких связанных с собой модулей(к чему может принуждать высокий Coupling)
Тут такое дело, если делать коммуникацию бесполезной, то она будет бесполезной. Сделаешь полезной и жизнь заиграет новыми красками.
Да не просто и если не следить, не вкладываться, то будет плохо, но будет очень круто, если вложиться ?♂️
Я предлагаю вложиться здоровые методы коммуникации, а не в Скрам. Вот и всё :)
Опираться при этом на рациональные аргументы в пользу тех или иных подходов и методов, а не ориентироваться на то "как в Скрам гайде написано".
Отмечу, что цитату из скрам гайда с преимеществами Скрама вы не привели.
практики говорят, что хорошо, но вместо того, чтоб понять в чем отличие от мест, где плохо
Я не считаю что Скрам-гайд это непоколебимая и универсальная истина, дарованная нам богами. Соответственно, что хорошо и что нет определяю не тем что написано "в практиках".
Если в практике написано что делать что-то - хорошо, но при этом в пользу этого не приведено ни единого аргумента, грош цена такой практике.
p.s. Завершу цитатой из гайда:
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Так выкидывайте. Только не говорите потом, что "Скрам не работает".
Я не говорю "не работает". Я говорю что Скрам добавляет бесполезные ритуалы, нередко занимаюшие 5-10% общего рабочего времени, и идущие наперекор своевременной коммуникации.
Примеры проблем я привёл. Приведу ещё разнообразия ради:
Коммуникация по Скраму происходит по расписанию. Адекватная коммуникация(и соответствующая Agile-принципам, если вам это важно) должна происходить при появлении потребности в ней.
Итерация здоровой команды завершается на закрытии какой-то фичи/проекта/майлстоуна. Скрам-"итерация" завершается спустя фиксированное количество времени.
Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки.
А можно цитату из Скрам гайда про то, какие плюшки Скрам даёт?
Можно не оценивать каждую. Некоторые команды не оценивают баги и технические задачи. Например, по багам принимают соглашение, всегда делать "малой кровью" без серьёзных изменений кода и отдельно планировать серьёзные изменения по следам этих багов.
И не проводить планирование, ибо мероприятие это довольно бестолковое, но времязатратное и выматывающее :)
Кажется никогда не влияет? И всегда есть задачи, от которых не отвертишься. Если честно не понял в чем суть этого пункта, кажется это "мухи и котлеты", которые отдельно
Если не влияет, то зачем оценка?
Вопросом на вопрос: а зачем такая низкодискретная оценка, что она даст? Кроме последней, которая должна повлечь декомпозицию?
То же самое что и стори-пойнты, только на порядок проще и быстрее - понимание сложности задачи у менеджера, и общее понимание сложности у команды, при необходимости.
Потому что-тогда только этот человек и будет обладать экспертизой и станет узким местом команды. Что-то там про бас-фактор навевает )
Люди не станут экспертами предметной области, от того что поучаствуют в тыканьи пальцем в небо оценке задачи.
Если этот относится к теме спринта, тот каждый день есть Дейли
Ну то есть если одному разработчику необходима консультация другого по какой-то фиче, они делают это во время стендапа блокируя всех остальных?
Он их и не ограничивает, а манифест, прямо таки кричит, что взаимодействие людей важнее всего.
Изначальный тезис был, что в Скраме "чётко выделено время для общения на тему текущих задач".
А кричит о том что взаимодействие важнее всего Agile манифест. Scrum к Agile-манифесту не имеет отношения. В Скраме как раз появляются такие замечательные(нет) штуки как "проблемы решаем по расписанию, раз в спринт на ретро".
> Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
Проще, а ещё проще работать одному, когда сам отвечаешь за всё, но в команде нужно взаимодействие и его удобно формализовать. Скрам - не самый плохой способ такой формализации, если его правильно готовить ?
Я не спорю что взаимодействие нужно. Мой вопрос: "Зачем проверять общее понимание задачи людьми, которые ей не занимаются?"
Если представление о задаче изменилось во время выполнения, об этом тоже нужно устроить отдельный митинг с обсуждением на всю команду?
Вот прямо любопытно, вы видели реального аналитика, который может описать так, чтоб потом не было вопросов, со всеми форматами логов и ещё бог знает каких мелочей, которые потом понадобятся тестировщика и внедренцу?
А разработчика, который всё это реализует прямо так, как написано, и чтоб не подкопаться? Наверное, даже почти точно, если собрать такую команду, то скрам не нужен.
А зачем? Более точное понимание задачи приходит во время выполнения, и это нормально. Разработчик при обнаружении каких-то неясных моментов может обсудить это с аналитиком или разработчиком-экспертом. Зачем всю команду дёргать для этого?
Если хотите чтобы сложной задачей занимались несколько разработчиков - есть парное программирование, есть mob programming - подходы когда люди буквально вместе садятся и делают задачу. И это будет значительно эффективнее, чем если разработчик на условном дейли будет пытаться словами в подробностях объяснить чего он где поменял/добавил в рамках задачи
Тут важно понимать, что скрам у каждой команды свой и он постоянно меняется.
Мне кажется вы тут слово "скрам" используете просто в значении "процессы".
Скрам это когда разрешение реальных потребностей команды заменяется на "А давайте сделаем скрам", последующие проблемы решаются через "А как же нам по скраму правильно это сделать"?
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
чётко выделено время для общения на тему текущих задач, а в остальное время, неожиданно, можно эти задачи решать, а не отбиваться от вопросов коллег или заказчика
Скрам не выделяет время для того чтобы задавать вопросы по задачам. Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Скрам вообще никак не выделяет время для индивидуальных митингов(или с участием определенного набора заинтереснованных людей). Вы для решения любого вопроса привлекаете всю команду?
общее понимание задачи хорошо проверяется и утверждается тем самым покером (хотя мы его так и не внедрили на полную, но он действительно удобен)
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Зачем для этого понимания скрам-покер и стори-пойнты? Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
И да, есть команды, которые и без всякого срама отлично справляются)
И сколько времени и внимания разработчиков они экономят на этом?
Третий совет очень важный, но при этом не так уж и часто о нём говорят.
Если что, статья про "вредные советы", и то о чем я пишу имхо ужасные практики, которые перетекают из команды в команду только потому-что какой-нибудь менеджер где-то на курсах услышал что "Скрам это стильно, модно, молодёжно, весь мир уже использует скрам, присоединяйтесь".
Обычно говорят "планирование" - и имеют в виду следующий спринт. Такая схема может работать только в идеальном мире, где все оценки точны, весь код работает без фатальных ошибок и... нет изменений по ходу спринтов.
Зачем вам спринты, если вы планируете их несколько наперёд?
Где все оценки точны
Если итерация заняла больше времени чем команда ожидала, то вы либо доводите итерацию до конца, если считаете это целесообразным, либо завершаете её как неудачный эксперимент, и срезаете косты. Если у вас это работает иначе, то это просто не итерация.
Под планированием в таких командах, обычно, имеют ввиду: "Сейчас мы возьмём пачку задач которые нам принес менеджер, и потратим пол дня на споры о том как проставить каждой из них количество стори-пойнтов в джире, на которые никто никогда не посмотрит".
Простые вопросы:
Зачем вам оценивать каждую задачу?
Действительно ли их оценка влияет на их приоритеты, или может про какие-то задачи заранее известно, что их делать нужно? Если не влияет то зачем оценивать?
Действительно ли вам для оценки задачи нужны метрики более подробные чем "простая" / "могут быть подводные камни" / "сложная, нужно поработать и декомпозировать"?
Зачем вам оценка задачи каждым участником команды? Почему недостаточно одного человека обладающего нужной экспертизой?
А в чем конкретно обычно противоречие с манифестом? Я аж подумал, может забыл что, открыл перечитал сначала сам манифест, потом 12 принципов - для нашей скрам-команды все обстоит прям так как и написано, хоть галочки напротив каждой строчки ставь. Можете примеров привести, как оно не совпадает в тех случаях, про которые говорите вы?
Скрам на самом деле вводит довольно жесткие ограничения, которые одновременно являются ну оочень спорными, а иногда даже абсурдными. Например абсурдные:
Внутри Scrum Team нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели — Product Goal. Scrum Teams являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint
То есть Скрам-команда эта всегда команда фулл-стэков, каждый из которых одинаково хорошо занимается и дизайном, и фронтенд разработкой, и бэкендом, и мобильной разработкой.
Или отдельно команда бэкенд-разработчиков, отдельно фронт-енд разработчиков и пр., но тогда не понятно, как каждая команда по отдельности может создавать что-то ценное для пользователя.
Или вот, например:
Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Команды самоуправляемы, но есть СМ который контроллирует соответствие Скраму, и как быть?
Сверять точность стори-пойнтов действительно плохая идея. Как и в целом использовать их таким образом что подобная сверка может понадобиться.
планируем как хочется
Описанная схема планирования это ад который надо избегать. А как правильно это делать, и делать ли вообще, оставляю читателю на подумать.
Не планируем спринты в запас
Не планируем конечно. Исказить представление о том что такое "итерация" до такой степени, что планировать несколько итераций наперёд, нужно очень постараться.
Если границы спринта для вас не означают +- ничего, зачем вам спринты?
прогуливаем дейлики
Прогулять дейлик в том формате, который предложен в статье в качестве вредного совета, действительно может быть эффективнее для работы чем присутствовать на таком :)
Но долгий, блокирующий, итеративный(нашли проблему => вернули задачу в разработку => исправили => отправили на ре-ревью) код-ревью это действительно проблема. И для деливери, и для последующей интеграции кода, и для разработчиков, которым нужно либо ждать пока пройдет ревью, либо постоянно следить за статусами нескольких задач и постоянно переключаться между ними.
Если такое происходит регулярно, стоит подумать о том, как дать разработчикам удочку а не рыбу (передача знаний для достижения общего уровня команды / неблокирующий ревью / дизайн-ревью до разработки)
Впрочем, хакнуть возможно любую метрику по отдельности при желании
Хакнуть то можно. Вопрос в том, зачем делать это поощряемым поведением, создавая прямую связь между завышением оценок и повышением по грейду.
Нормальное поведение, где разработчик старается оценивать задачи честно, при этом, наоборот, оказывается невыгодным.
Автотесты - это как страховка, можно купить себе полное КАСКО и застраховаться от всего или почти от всего (читаем условия, написанные мелкими буквами), а можно застраховать только отдельные риски - угон, тотал. Каждый сам решает в соответствии с его бизнесом что ему важнее - принять риск или заплатить больше, но застраховаться от всего.
Имхо, автотесты это одно из обязательных условий для того чтобы:
а) Иметь хоть какие-то гарантии в долгосрочной перспективе;
б) Иметь возможность поддерживать короткий цикл обратной связи.
Без них цена и время ручного регрессионного тестирования будет постоянно увеличиваться.
Но ставить себе планку в какой-то процент покрытия тестами кода не стоит, т.к. это приведёт к излишним тратам.
Действительно, не стоит. К любым метрикам нужно относиться настороженно, чтобы они не приводили к излишним тратам.
Работа не ради метрик делается, всё таки - об этом оба мои комментария под вашей статьёй.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
...
% задач, которые были сделаны быстрее, чем их оценивали.
Секрет повышения в Skyeng - завышать эстимейты по задачам. Чем сильнее завысишь, тем лучше.
А если без сарказма, от всей статьи ощущение будто разработчиков по строчкам кода оценивают. Метрики то подобрали посложнее, но суть та же.
Как показатели для нахождения узких мест в процессе - да, конечно.
Как возможность заметить, что поведение конкретного разработчика изменилось, и спросить, что у него случилось - ок.
Как метрики чтобы оценивать грейд разработчиков - написание автотестов, кажется, должно быть более важной задачей, чем попытка вывести разработчика который баги не производит.
Писать код надо так, чтобы его было легко менять и выкидывать в случае, если ты ошибся, и тут помогают именно типы, описывающие, что и над чем код делает, а не некая слабая связность или слоёная архитектура с абстракциями и сервисами.
Связность, сервисы и прочие DDD скорее о том, как не терять продуктивности с ростом масштабов проекта, когда над ним работает много команд, и добавляются разные источники требований, а не для того чтобы сделать отдельный кусок кода более понятным
Нет, этими примерами я доказываю то, что вы намеренно вводите в заблуждение меня и остальных не указывая его. Непонятно только зачем вы это делаете, когда информация эта легко проверяема.
Я не указываю его, потому что в ситуации, когда происходит переписывание кода с php на другие языки, одним из языков в стеке будет php, неужели это действительно так неочевидно?
А кто вам сказал, что у Котлин экосистема богаче php?
А вам важно "кто мне сказал", или всё-таки экосистема?) Пока что у меня есть ощущение, что поставить галочку о победе в споре, и таким образом защитить полюбившуюся технологию вам важнее, чем реальные ответы на вопросы.
Будем сравнивать экосистемы PHP vs Java+Kotlin?)
Можем начать, например, с количества фреймвокров поддерживающих actor model, или как я выше писал, клиентами open telemetry, или даже клиентами к Кафке, из популярного :)
Ну и в целом есть много областей где Kotlin/Java как языки представляют сильно больше возможностей и юзкейсов для развития экосистемы, за счёт чего расширяют её, и позволяют решать более широкий класс задач(взять ту же асинхронность)
То есть таки иной язык, частично похожий, но не обратно-совместимый с PHP, и выбранный из-за наличия легаси.
По поводу остальных примеров - вы наличием языка PHP в стеке компаний доказываете, что переписывания не происходит. В отдельном случаях прямо указывая, что на ПХП существует в основном легаси код.
Ваши выводы не следуют из предпосылок, поэтому мне тут нечего ответить более :)
это вы похоже что на c++ и котлине хотите все писать.
А с каких пор котлин, с экосистемой богаче чем у PHP, и на который уже даже документация спринга переведена, не подходит для бэкенда?)
Крайне рекомендую автору статьи и всем заинтересовавшимся посмотреть выступление https://www.youtube.com/watch?v=hev65ozmYPI ("All your aggregates are wrong") .
В докладе рассматривается буквально такой же подбор компонентов как в упомянутой цитате, с разбором почему такое структурирование может вылиться в проблемы с работой и поддержкой системы.
Всё так. Это метрики для поиска совсем плохих мест, а не чтобы встроить их в пайплайн коммитов
По поводу модулей и зависимостей. Я думаю хорошая модель для объяснения и для нахождения плохо-спроектированных модулей это 1 - Coupling/Cohesion - модули должны иметь как можно меньше связей с другими модулям, а связанность должна быть инкапсулирована внутри модулей. 2 - Afferent/Efferent coupling - количество входящих/исходящий зависимостей классов/модулей. Если класс стабильный и от него многие зависят = ок, делать такой класс зависимым от других и следовательно менее стабильным = не ок.
Подробно не расписываю, рекомендую просто погуглить + небольшие книжки Роберта Матрина где он определяет эти понятия, разобраться с типами связанности. Плюсы такой модели в том что есть готовые инструменты которые автоматически подсчитают упомянутые метрики, и дадут хорошую базу для обсуждения возможного рефакторинга. Так же пользу упомянутых моделей легко объяснить исходя из предпосылки что держать в уме содержимое одного модуля проще проще чем содержимое нескольких связанных с собой модулей(к чему может принуждать высокий Coupling)
Я предлагаю вложиться здоровые методы коммуникации, а не в Скрам. Вот и всё :)
Опираться при этом на рациональные аргументы в пользу тех или иных подходов и методов, а не ориентироваться на то "как в Скрам гайде написано".
Отмечу, что цитату из скрам гайда с преимеществами Скрама вы не привели.
Я не считаю что Скрам-гайд это непоколебимая и универсальная истина, дарованная нам богами. Соответственно, что хорошо и что нет определяю не тем что написано "в практиках".
Если в практике написано что делать что-то - хорошо, но при этом в пользу этого не приведено ни единого аргумента, грош цена такой практике.
p.s. Завершу цитатой из гайда:
Я не говорю "не работает". Я говорю что Скрам добавляет бесполезные ритуалы, нередко занимаюшие 5-10% общего рабочего времени, и идущие наперекор своевременной коммуникации.
Примеры проблем я привёл. Приведу ещё разнообразия ради:
Коммуникация по Скраму происходит по расписанию. Адекватная коммуникация(и соответствующая Agile-принципам, если вам это важно) должна происходить при появлении потребности в ней.
Итерация здоровой команды завершается на закрытии какой-то фичи/проекта/майлстоуна. Скрам-"итерация" завершается спустя фиксированное количество времени.
А можно цитату из Скрам гайда про то, какие плюшки Скрам даёт?
И не проводить планирование, ибо мероприятие это довольно бестолковое, но времязатратное и выматывающее :)
Если не влияет, то зачем оценка?
То же самое что и стори-пойнты, только на порядок проще и быстрее - понимание сложности задачи у менеджера, и общее понимание сложности у команды, при необходимости.
Люди не станут экспертами предметной области, от того что поучаствуют в
тыканьи пальцем в небооценке задачи.Ну то есть если одному разработчику необходима консультация другого по какой-то фиче, они делают это во время стендапа блокируя всех остальных?
Изначальный тезис был, что в Скраме "чётко выделено время для общения на тему текущих задач".
А кричит о том что взаимодействие важнее всего Agile манифест. Scrum к Agile-манифесту не имеет отношения. В Скраме как раз появляются такие замечательные(нет) штуки как "проблемы решаем по расписанию, раз в спринт на ретро".
Я не спорю что взаимодействие нужно. Мой вопрос: "Зачем проверять общее понимание задачи людьми, которые ей не занимаются?"
Если представление о задаче изменилось во время выполнения, об этом тоже нужно устроить отдельный митинг с обсуждением на всю команду?
А зачем? Более точное понимание задачи приходит во время выполнения, и это нормально. Разработчик при обнаружении каких-то неясных моментов может обсудить это с аналитиком или разработчиком-экспертом. Зачем всю команду дёргать для этого?
Если хотите чтобы сложной задачей занимались несколько разработчиков - есть парное программирование, есть mob programming - подходы когда люди буквально вместе садятся и делают задачу. И это будет значительно эффективнее, чем если разработчик на условном дейли будет пытаться словами в подробностях объяснить чего он где поменял/добавил в рамках задачи
Мне кажется вы тут слово "скрам" используете просто в значении "процессы".
Скрам это когда разрешение реальных потребностей команды заменяется на "А давайте сделаем скрам", последующие проблемы решаются через "А как же нам по скраму правильно это сделать"?
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
Скрам не выделяет время для того чтобы задавать вопросы по задачам. Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Скрам вообще никак не выделяет время для индивидуальных митингов(или с участием определенного набора заинтереснованных людей). Вы для решения любого вопроса привлекаете всю команду?
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Зачем для этого понимания скрам-покер и стори-пойнты? Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
И сколько времени и внимания разработчиков они экономят на этом?
Если что, статья про "вредные советы", и то о чем я пишу имхо ужасные практики, которые перетекают из команды в команду только потому-что какой-нибудь менеджер где-то на курсах услышал что "Скрам это стильно, модно, молодёжно, весь мир уже использует скрам, присоединяйтесь".
Зачем вам спринты, если вы планируете их несколько наперёд?
Если итерация заняла больше времени чем команда ожидала, то вы либо доводите итерацию до конца, если считаете это целесообразным, либо завершаете её как неудачный эксперимент, и срезаете косты. Если у вас это работает иначе, то это просто не итерация.
Под планированием в таких командах, обычно, имеют ввиду: "Сейчас мы возьмём пачку задач которые нам принес менеджер, и потратим пол дня на споры о том как проставить каждой из них количество стори-пойнтов в джире, на которые никто никогда не посмотрит".
Простые вопросы:
Зачем вам оценивать каждую задачу?
Действительно ли их оценка влияет на их приоритеты, или может про какие-то задачи заранее известно, что их делать нужно? Если не влияет то зачем оценивать?
Действительно ли вам для оценки задачи нужны метрики более подробные чем "простая" / "могут быть подводные камни" / "сложная, нужно поработать и декомпозировать"?
Зачем вам оценка задачи каждым участником команды? Почему недостаточно одного человека обладающего нужной экспертизой?
Как команда совмещающая в себе людей с разными навыками соответствует требованию "Отсутствие подкоманд и иерархий"?
Я то только за кросс-функциональные команды, но против Scrum :)
Скрам на самом деле вводит довольно жесткие ограничения, которые одновременно являются ну оочень спорными, а иногда даже абсурдными. Например абсурдные:
То есть Скрам-команда эта всегда команда фулл-стэков, каждый из которых одинаково хорошо занимается и дизайном, и фронтенд разработкой, и бэкендом, и мобильной разработкой.
Или отдельно команда бэкенд-разработчиков, отдельно фронт-енд разработчиков и пр., но тогда не понятно, как каждая команда по отдельности может создавать что-то ценное для пользователя.
Или вот, например:
Команды самоуправляемы, но есть СМ который контроллирует соответствие Скраму, и как быть?
Сверять точность стори-пойнтов действительно плохая идея. Как и в целом использовать их таким образом что подобная сверка может понадобиться.
Описанная схема планирования это ад который надо избегать. А как правильно это делать, и делать ли вообще, оставляю читателю на подумать.
Не планируем конечно. Исказить представление о том что такое "итерация" до такой степени, что планировать несколько итераций наперёд, нужно очень постараться.
Если границы спринта для вас не означают +- ничего, зачем вам спринты?
Прогулять дейлик в том формате, который предложен в статье в качестве вредного совета, действительно может быть эффективнее для работы чем присутствовать на таком :)
Спасибо, переименовал заголовки советов таким образом, чтобы их дословная трактовка не создавала двусмысленность.
Но долгий, блокирующий, итеративный(нашли проблему => вернули задачу в разработку => исправили => отправили на ре-ревью) код-ревью это действительно проблема. И для деливери, и для последующей интеграции кода, и для разработчиков, которым нужно либо ждать пока пройдет ревью, либо постоянно следить за статусами нескольких задач и постоянно переключаться между ними.
Если такое происходит регулярно, стоит подумать о том, как дать разработчикам удочку а не рыбу (передача знаний для достижения общего уровня команды / неблокирующий ревью / дизайн-ревью до разработки)
Хакнуть то можно. Вопрос в том, зачем делать это поощряемым поведением, создавая прямую связь между завышением оценок и повышением по грейду.
Нормальное поведение, где разработчик старается оценивать задачи честно, при этом, наоборот, оказывается невыгодным.
Имхо, автотесты это одно из обязательных условий для того чтобы:
а) Иметь хоть какие-то гарантии в долгосрочной перспективе;
б) Иметь возможность поддерживать короткий цикл обратной связи.
Без них цена и время ручного регрессионного тестирования будет постоянно увеличиваться.
Действительно, не стоит. К любым метрикам нужно относиться настороженно, чтобы они не приводили к излишним тратам.
Работа не ради метрик делается, всё таки - об этом оба мои комментария под вашей статьёй.
Секрет повышения в Skyeng - завышать эстимейты по задачам. Чем сильнее завысишь, тем лучше.
А если без сарказма, от всей статьи ощущение будто разработчиков по строчкам кода оценивают. Метрики то подобрали посложнее, но суть та же.
Как показатели для нахождения узких мест в процессе - да, конечно.
Как возможность заметить, что поведение конкретного разработчика изменилось, и спросить, что у него случилось - ок.
Как метрики чтобы оценивать грейд разработчиков - написание автотестов, кажется, должно быть более важной задачей, чем попытка вывести разработчика который баги не производит.
Связность, сервисы и прочие DDD скорее о том, как не терять продуктивности с ростом масштабов проекта, когда над ним работает много команд, и добавляются разные источники требований, а не для того чтобы сделать отдельный кусок кода более понятным
Как по мне, основной смысл таких набросов про rest/ооп/agile etc. в том, чтобы людей подтолкнуть к более осознанному выбору подходов.
Часто за подобными баззвордами оказывается карго культ проталкиваемый не очень честными консультантами
Я не указываю его, потому что в ситуации, когда происходит переписывание кода с php на другие языки, одним из языков в стеке будет php, неужели это действительно так неочевидно?
А вам важно "кто мне сказал", или всё-таки экосистема?) Пока что у меня есть ощущение, что поставить галочку о победе в споре, и таким образом защитить полюбившуюся технологию вам важнее, чем реальные ответы на вопросы.
Будем сравнивать экосистемы PHP vs Java+Kotlin?)
Можем начать, например, с количества фреймвокров поддерживающих actor model, или как я выше писал, клиентами open telemetry, или даже клиентами к Кафке, из популярного :)
Ну и в целом есть много областей где Kotlin/Java как языки представляют сильно больше возможностей и юзкейсов для развития экосистемы, за счёт чего расширяют её, и позволяют решать более широкий класс задач(взять ту же асинхронность)
То есть таки иной язык, частично похожий, но не обратно-совместимый с PHP, и выбранный из-за наличия легаси.
По поводу остальных примеров - вы наличием языка PHP в стеке компаний доказываете, что переписывания не происходит. В отдельном случаях прямо указывая, что на ПХП существует в основном легаси код.
Ваши выводы не следуют из предпосылок, поэтому мне тут нечего ответить более :)
А с каких пор котлин, с экосистемой богаче чем у PHP, и на который уже даже документация спринга переведена, не подходит для бэкенда?)