Хм, по последнему гайду нельзя только цель спринта менять, все остальное - вполне допустимо. И изменение задач, и добавление новых и так далее - вполне разрешено.
Ну, в мире у эффективных компаний не так много скрама, кстати. И высококонкурентный бизнес не так уж сильно зависит от эффективности разработчиков, как ни странно. Ну и в индустрии вообще любят очень неудачные решения, так как про них проще рассказывать на конференциях.
Хм, в скрайм-гайде дофига странного. Регулярные ретро (которые нужны не слишком опытным командам), цель спринта (которая имеет смысл довольно редко), сами спринты (очень сильно увеличивают нагрузку на команду) и так далее.
Кстати, никакого "приоритет чтобы работало , а документация вторична" в скраме нет. Лидеров в скраме тоже нет никаких (только скрам-мастер, но он про другое). Плана дел на 24 часа, кстати, тоже нет (впрочем, это довольно сомнительная практика).
Но, чисто формально, скрам не соответствует agile-манифесту. Впрочем, большая часть скрама - и не противоречит манифесту (и вообще не касается его тем).
Хм, странная статистика. Во всех мне известных энтерпрайз-компаниях дофига котлина, сколь-нибудь крупных java-продуктов без kotlin я уже давно не видел. На бэке очень, очень много котлина. Но я больше про финтех.
Хм, а причем тут скрам? И agile manifest не про "ненужность процессов", а про "люди важнее процессов". И если людям удобно поменять процесс - его надо менять (даже если при этом придется отойти от скрамгайда). Скрам не является agile именно потому, что любое отклонение от скрамгайда уже не является скрамом.
В больших проектах можно уже найти хотя бы одного нормального менеджера, который настроит вменяемые процессы, а не скарм (в котором, заметим, вообще нет инструментов координации команд, там нужно идти в LeSS или SAFe, а это совсем грустные тяжелые жесткие методики).
Проблема совместной оценки сложных задач решается, в первую очередь, работой с архитектурой и обратным законом Конвея, скрам там вообще никак не поможет. А уж "субкоманды" - это явный скрамбат, к скраму отношения не имеющий.
Вообще, в скраме еще и очень медленная обратная связь (и нет никаких требований к ее ускорению). И это крайне грустно для любых более-менее нормальных процессов и продуктов.
Хм, в небольших командах скрам особенно избыточен и негибок. Там проще брать канбан, минимизировать количество ритуалов и нормально работать. Скрам там и дорог и неэффективен. Ну и, конечно, считать скрам - аджайл-методологией довольно странно, в гайде отчетливо "процессы важнее людей".
Да, хороший менеджер, играя роль скрам-мастера, может выкинуть или переосмыслить скрам-гайдт и нарисовать нормальный рабочий процесс. Но без гайда у него получится еще быстрее и проще.
Ну, оперативное изменение будет довольно дорогим и на большом объеме будет сильно тормозить или требовать очень много ресурсов. Но для небольших объемов решение на эластике или солре вполне допустимо. CH, увы, потянет, но до 10-100rps, дальше уже будет невыгодно. В общем, как всегда, нужно сначала смотреть на ФТ/НТФ, а потом уже решение выбирать.
Хм, а как в задаче поиска по множеству категорий поможет Mongo? Там для этого вообще нет никаких инструментов. Можно идти или в сторону специализированных поисков или таки по таблице на категорию или играть с селективностью запросов и дальше уже отбирать на уровне приложения. Впрочем, подход EAV (описанный в статье) вообще непригоден для подобных задач, он крайне неэффективен.
Был еще прекрасный Siemens SK65 (для того времени - гениальная штука, с максимальным удобством набора). Ну и QWERTY-смартфоны, да, их очень не хватает.
Я когда-то предлагал для дипломов собирать команды из разных факультетов и делать общие стартапы. Но пока даже в топовых вузах до этого не дошли, а жаль.
А зачем на позиции тимлида (менеджерской) кто-то, кто знаком с разработкой? Угробить процесс сможет любой некомпетентный менеджер - и у бывшего разработчика шансов только больше. Впрочем, команде отдельный лид вообще не нужен.
Вообще, стоит разделять мендежмент людей, процессов, проектов, продуктов, ресурсов - это все очень разные направления с очень разными компетенциями и лучше бы их не объединять в одном человеке. Но при этом все эти специалисты могут работать со многими командами одновременно. А в команде пусть останется техлид, без лишних менеджерских обязанностей и полномочий.
Ну и любой вменяемый менеджер на новом месте не будет сразу все ломать, а посмотрит на команду (команды), а потом уже попробует что-нибудь улучшать.
Хм, а в чем проблема с лишними знаками препинания? Любой нормальный редактор их автоматически проставляет.
А вот сложность yaml - вполне объективная, можно смотреть по объему кода для разбора или по объему документации. Сложность редактирования (вернее, простота допустить ошибку) - тоже вполне объективная. В Json опечатка приведет к нарушению синтаксиса. А вот в yaml опечатка приводит к изменению семантики, что гораздо грустнее. Ну и так далее.
Хм, по последнему гайду нельзя только цель спринта менять, все остальное - вполне допустимо. И изменение задач, и добавление новых и так далее - вполне разрешено.
Ну, в мире у эффективных компаний не так много скрама, кстати. И высококонкурентный бизнес не так уж сильно зависит от эффективности разработчиков, как ни странно.
Ну и в индустрии вообще любят очень неудачные решения, так как про них проще рассказывать на конференциях.
Ну, зачем для этого скрам? Проще канбан-доску отдать бизнесу и все )
Хм, в скрайм-гайде дофига странного.
Регулярные ретро (которые нужны не слишком опытным командам), цель спринта (которая имеет смысл довольно редко), сами спринты (очень сильно увеличивают нагрузку на команду) и так далее.
Кстати, никакого "приоритет чтобы работало , а документация вторична" в скраме нет. Лидеров в скраме тоже нет никаких (только скрам-мастер, но он про другое). Плана дел на 24 часа, кстати, тоже нет (впрочем, это довольно сомнительная практика).
Но, чисто формально, скрам не соответствует agile-манифесту. Впрочем, большая часть скрама - и не противоречит манифесту (и вообще не касается его тем).
Последняя версия - да, вполне абстрактна, но и там дофига довольно четких требований по ролям, активностям и так далее.
Хм, странная статистика. Во всех мне известных энтерпрайз-компаниях дофига котлина, сколь-нибудь крупных java-продуктов без kotlin я уже давно не видел.
На бэке очень, очень много котлина.
Но я больше про финтех.
Хм, а причем тут скрам? И agile manifest не про "ненужность процессов", а про "люди важнее процессов". И если людям удобно поменять процесс - его надо менять (даже если при этом придется отойти от скрамгайда).
Скрам не является agile именно потому, что любое отклонение от скрамгайда уже не является скрамом.
В больших проектах можно уже найти хотя бы одного нормального менеджера, который настроит вменяемые процессы, а не скарм (в котором, заметим, вообще нет инструментов координации команд, там нужно идти в LeSS или SAFe, а это совсем грустные тяжелые жесткие методики).
Проблема совместной оценки сложных задач решается, в первую очередь, работой с архитектурой и обратным законом Конвея, скрам там вообще никак не поможет. А уж "субкоманды" - это явный скрамбат, к скраму отношения не имеющий.
Так свойство товара - это и есть категория.
И поиск по свойствам - это поиск по множеству категорий, к которым отнесен товар.
Это одно и то же.
Я в 2008ом уже студентам рассказывал про проблемы Scrum и граничных условиях )
Вообще, в скраме еще и очень медленная обратная связь (и нет никаких требований к ее ускорению). И это крайне грустно для любых более-менее нормальных процессов и продуктов.
Хм, в небольших командах скрам особенно избыточен и негибок. Там проще брать канбан, минимизировать количество ритуалов и нормально работать. Скрам там и дорог и неэффективен. Ну и, конечно, считать скрам - аджайл-методологией довольно странно, в гайде отчетливо "процессы важнее людей".
Да, хороший менеджер, играя роль скрам-мастера, может выкинуть или переосмыслить скрам-гайдт и нарисовать нормальный рабочий процесс. Но без гайда у него получится еще быстрее и проще.
Ну, оперативное изменение будет довольно дорогим и на большом объеме будет сильно тормозить или требовать очень много ресурсов. Но для небольших объемов решение на эластике или солре вполне допустимо.
CH, увы, потянет, но до 10-100rps, дальше уже будет невыгодно.
В общем, как всегда, нужно сначала смотреть на ФТ/НТФ, а потом уже решение выбирать.
Хм, а как в задаче поиска по множеству категорий поможет Mongo? Там для этого вообще нет никаких инструментов.
Можно идти или в сторону специализированных поисков или таки по таблице на категорию или играть с селективностью запросов и дальше уже отбирать на уровне приложения.
Впрочем, подход EAV (описанный в статье) вообще непригоден для подобных задач, он крайне неэффективен.
Был еще прекрасный Siemens SK65 (для того времени - гениальная штука, с максимальным удобством набора). Ну и QWERTY-смартфоны, да, их очень не хватает.
Я когда-то предлагал для дипломов собирать команды из разных факультетов и делать общие стартапы. Но пока даже в топовых вузах до этого не дошли, а жаль.
А зачем на позиции тимлида (менеджерской) кто-то, кто знаком с разработкой? Угробить процесс сможет любой некомпетентный менеджер - и у бывшего разработчика шансов только больше. Впрочем, команде отдельный лид вообще не нужен.
Вообще, стоит разделять мендежмент людей, процессов, проектов, продуктов, ресурсов - это все очень разные направления с очень разными компетенциями и лучше бы их не объединять в одном человеке.
Но при этом все эти специалисты могут работать со многими командами одновременно. А в команде пусть останется техлид, без лишних менеджерских обязанностей и полномочий.
Ну и любой вменяемый менеджер на новом месте не будет сразу все ломать, а посмотрит на команду (команды), а потом уже попробует что-нибудь улучшать.
Вот да, и HOCON и Json5 - лучше и json и, тем более, yaml. Но пока не так популярны (
Хм, а в чем проблема с лишними знаками препинания? Любой нормальный редактор их автоматически проставляет.
А вот сложность yaml - вполне объективная, можно смотреть по объему кода для разбора или по объему документации.
Сложность редактирования (вернее, простота допустить ошибку) - тоже вполне объективная. В Json опечатка приведет к нарушению синтаксиса. А вот в yaml опечатка приводит к изменению семантики, что гораздо грустнее.
Ну и так далее.
А что в нем хорошего? Плохо читается, плохо редактируется, сложный.
Какой-нибудь json, конечно, тоже не идеален - но проще и удобнее.