Если есть Скрам (т.е. в частности нет начальников отделов), то непонятно как получается без скрам-мастера: на основные события может он и не особо нужен, но проводить 1-1 и справляться с блокерами и другими конфликтами кто-то должен.
Тут все просто - что такое команды? что такое отделы? а что такое домены? И еще - что такое холоны?
Чтобы ответить на этот вопрос - надо понимать все эти понятия и понимать как они связаны.
Там еще есть понятия про ко-лидерство.
Все это в целом сложно ) И если распутать тогда все становится по местам.
Условно чтобы уйти от старых понятий можно взять термины из Социократии - домены. Есть только домены и их поддомены. А у каждого домена могут быть лидеры, и они разные и может быть не один. Они могут заниматься чем угодно.
Домены могут взаимодействовать с любыми другими доменами в любых связях.
То что вы называете начальником отдела - это просто лидер домена. Его можно назвать руководителем, начальником отдела или департамента, или тим лидом, или лидом про что то - или как то еще.
Скрам это не про то что нет начальником отделов - они есть. Просто зовутся другими словами. Но суть всегда одна - если ты взял ответственность не только за себя, а еще и за какую то группу людей (команду, отдел, департамент ...) будь готов отвечать за всех.
Это сложно объяснить.
А еще сложнее объяснить что начальников или лидеров бывает много и они очень разные и зовутся по разному - можно почитать книги про ко-лидерство.
В одной команде даже атомарного уровня у одного сотрудника может быть 2-3-4 руководителя - и при грамотном балансе это тоже ок.
Но если это все переложить на карго культ и шаблоны - образуется ад. Что и бывает со скрамом )
В этом случае поможет только наличие грамотного консультанта или коуча который сможем навести баланс и объяснить как что работает ) так чтобы эти все типа лидеры не перегрызли себе глотки )
Беда бывает там где баланс нарушен и кто то из лидеров тащит одеяло на себя - например чел который отвечает за иерархию тащит одеяло на себя от человеков которые тащят ценность. Условно руководитель кодеров тащит одеяло на себя от руководителей проектов - вот там бывают взрывы и плохо.
Интересные формулировки, интересная точка зрения, 4й пункт первого списка забрал к себе в заметки :)
Однако размышляя над теми же напряжениями скрама я в итоге пришел чуть к иным аспектам: - скрам мастер может быть, если нужен, но может и не быть если не нужен. может быть как full time роль или part time? как внешний или внутренний игрок? руководитель или зам или кто то из верхней команды если мы говорим про молекулярные команды на 100 чел? или внешний консультант если мы говорим про атомарные команды 5-10 чел.
- еще интересно провести аналогии с Канбан - где есть деливери менеджеры - отвечающие за снятие блокеров и помех на пути доставки ценности. на мой взгляд очень созвучно со скрам мастером. в этом случае роль конечно должна быть полноценная.
- но там еще образуется туча но и если - все очень зависит от контекста процессов и особенностей команды.
Работая с 20+ командами, я пришел к выводу что в этом мире не все всегда и везде, а кое что иногда и местами.
Где то все ок было даже с 1 руководителем проектов во главе, без всяких там скрамов, продукт овнеров и скрам мастеров. хотя в других кейсах та же схема оказывалась провальна.
Где то есть эджайл-помесь: скрама, канбана и социократии. Скрам мастер или эджайл коуч или консультант - парт тайм - просто приходит на некоторые встречи и если есть проблемы - помогает решать - но при этом он технически подкован.
А где то все по науке - продукт овнер от бизнеса, скрам мастер полу психолог не бум бум в ИТ, и все артефакты на месте - но там сплошной карго культ и на такую команду и их результаты сложно смотреть без слез.
А еще я думаю скрам стал популярен не потому что у него простые формулировки, а потому что он проприетарный, платный и у него огромные бюджеты на рекламу и маркетинг.
Например его аналог Социократия S3 - опенсорсная, сильно понятней для меня, но не так популярна потому что не так сильно рекламируется.
Это обычные муки выбора.
Есть делема в таких выборах которая называется: Suite или Best of breed?
Ты либо выбираешь нечто универсальное, либо нечто узко специализированное.
У каждого подхода есть плюсы и минусы.
Бывало даже пытаешься разработать свое. Универсальное. Но там тоже фракталы и боли.
BPM & BPMN — это очень больная штука. Я в свое время наболелся и в итоге ушел в ACM (adaptive case management). По этой концепции работает AmoCRM, OmniDesk, FreeScout…
Это проще, гибче, легче.
В итоге я пришел к такой концепции:
1. Беру готовые best of breed без перегрузки функционала — типа AmoCRM, OmniDesk, GitHub…
2. Интегрирую их через IFTTT, Zapier или своими скриптами
3. На стыках процессов использую конструкторы типа Notion или Airtable.
Получается закрыть любые процессы. И при этом затраты на минималках.
Ну а в крупных бизнесах — многое пишется под себя. Но это очень рискованно, больно и дорого. Однако если все сделать хорошо, то бывает выгодно.
Модули разработаны с использованием пакета Laravel-Modules v2. Модули взаимодействуют с приложением через хуки (action и filter) как в WordPress, реализованные с помощью пакета Eventy. Модули могут даже добавлять свои собственные composer-пакеты в проект.
По сути там Eventy как диспетчер событий.
1. можно вставлять события в разные части кода ядра или модулей
2. затем из других модулей подписываться на них и реагировать
например:
1. событие — пришла заявка
2. реакция модуля — отправить сообщение в Телеграм чат с содержанием и контактами.
Не факт что там SSR, может быть SSG или fcgi-cache.
SSR иногда может быть быстрее чем клиент рендер. Особенно в части получения первого экрана и его видимости для посетителя.
Но почти всегда медленнее чем SSG или fcgi-cache. Где то тут было сравнение SSR NextJS vs SSG GatsbyJS. SSG оказывался быстрее.
Если вы сделаете сайт на вордпрессе, с кучей кривого кода, где SSR и TTFB будет в районе 1 минуты, то просто fcgi-cache позволит получать страницу в те же 50-100 мс что у dev.to — если верстка будет более мене адекватная, то и показываться тоже будет быстро.
Бывают гибриды. Когда основной контент это SSG или SSR. Или SSR с кешем в SSG.
А интерактивные элементы и фрагменты страницы, контент которых зависит от пользователя — рендерятся на стороне клиента. Например похожим образом работает GitHub.
На мой взгляд ничего нового тут нет. Просто хайп вокруг клиентского ренденринга проходит. И может быть его даже перестанут пихать всюду где надо и не надо. Он останется только там где и был придуман — интерактивные веб приложения и виджеты. Например аппки типа Трелло, Чаты или виджет чата для сайта. Которые нельзя или сложно сделать через чистый SSR.
Есть 3 условные стадии роста продукта:
— монолит со структурой function-first или MVC — так можно рости пока у вас 1-2 команды по 5-10 человек
— когда команд становится 5-10 штук, то начинаются конфликты и ростут блокировки. тогда выгодно переходить в монолит на модулях или монолит feature-first или компонентно-ориентированное программирование или DDD как вариант — чтобы команды работали каждый над своей частью системы и сильно не мешали друг другу
— когда команд становится 100 штук, а программистов под 1000, тогда выгодно начинать уходить в микросервисы
Конечно рост по количеству программистов не единственный критерий выхода в микросервисы. еще могут быть узкие горлышки, необходимость применять иные языки программирования и стеки, переиспользование функционала и т д.
Главное понимать что без веских причин усложнять не стоит. И усложнять систему стоит только тогда когда это решает реальные проблемы. Потому что это решение не бесплатно, затраты очень сильно увеличиваются, и потому выгода должна оказаться больше чем те затраты и проблемы которые придут в комплекте.
Решение выдуманных проблем на волне хайпа вокруг очередной модной технологии создает больше проблем чем решает их. О чем как я понял автор и говорит в данной статье.
Изучите что такое php Swoole.
На счет C# я готов поверить что он будет быстрее. Но только в виртуальном мире.
В реальном мире все сложнее. Там много чего и чаще всего качество кода.
Если хорошо писать код, то они все быстрые.
В реальном мире — все зависит от программистов. И тут вопрос культуры конкретной команды и уровня специалистов.
> Ничто не мешает иметь модульность и сообщения со статической типизацией
Согласен.
> При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
Тут важно отличать надежность от антихрупкости. Для этого нужно прочитать книгу. Объяснить это коротко боюсь не получится.
Плюс после этого поработать с большими и сложными системами построенными на статической типизации и на модулях с сообщениями и динамической типизацией. Сравнить их.
Да, может быть формулировка не очень.
Вот цитаты:
> Хрупкость и антихрупкость здесь – относительные понятия, а не абсолютные качества: объект, находящийся справа от точки отсчета, более антихрупок, чем объект, который находится слева.
> Как видит читатель, карта без каких-либо ограничений распространяется на любые области и сферы деятельности: культура, здравоохранение, биология, политические системы, технология, городское планирование, социально-экономическая жизнь и прочие явления
Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?
Ту же стратегию штанги отлично получается применять к покеру. Это вообще очень гибкая теория и ее применение возможно в самых разных областях.
Не совсем. Динамическая типизация это сторона расширяемых систем, которая дает плюсы. Но не обязательна. Да, если писать расширяемую систему на Java & C# то динамические штуки там делать сложнее. В пхп проще. Вот и все.
Опять же сама по себе динамическая типизация не дает хрупкости. Выше в комментах где то писал. Гораздо важнее это модульность и сообщения. Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости. Меньше проблем с поздним связыванием и взаимодействием между модулями через сообщения. Но если очень хочется использовать статическую типизацию — то это тоже возможно.
Тут все просто - что такое команды? что такое отделы? а что такое домены? И еще - что такое холоны?
Чтобы ответить на этот вопрос - надо понимать все эти понятия и понимать как они связаны.
Там еще есть понятия про ко-лидерство.
Все это в целом сложно ) И если распутать тогда все становится по местам.
Условно чтобы уйти от старых понятий можно взять термины из Социократии - домены. Есть только домены и их поддомены. А у каждого домена могут быть лидеры, и они разные и может быть не один. Они могут заниматься чем угодно.
Домены могут взаимодействовать с любыми другими доменами в любых связях.
То что вы называете начальником отдела - это просто лидер домена. Его можно назвать руководителем, начальником отдела или департамента, или тим лидом, или лидом про что то - или как то еще.
Скрам это не про то что нет начальником отделов - они есть. Просто зовутся другими словами. Но суть всегда одна - если ты взял ответственность не только за себя, а еще и за какую то группу людей (команду, отдел, департамент ...) будь готов отвечать за всех.
Это сложно объяснить.
А еще сложнее объяснить что начальников или лидеров бывает много и они очень разные и зовутся по разному - можно почитать книги про ко-лидерство.
В одной команде даже атомарного уровня у одного сотрудника может быть 2-3-4 руководителя - и при грамотном балансе это тоже ок.
Но если это все переложить на карго культ и шаблоны - образуется ад. Что и бывает со скрамом )
В этом случае поможет только наличие грамотного консультанта или коуча который сможем навести баланс и объяснить как что работает ) так чтобы эти все типа лидеры не перегрызли себе глотки )
Беда бывает там где баланс нарушен и кто то из лидеров тащит одеяло на себя - например чел который отвечает за иерархию тащит одеяло на себя от человеков которые тащят ценность. Условно руководитель кодеров тащит одеяло на себя от руководителей проектов - вот там бывают взрывы и плохо.
Интересные формулировки, интересная точка зрения, 4й пункт первого списка забрал к себе в заметки :)
Однако размышляя над теми же напряжениями скрама я в итоге пришел чуть к иным аспектам:
- скрам мастер может быть, если нужен, но может и не быть если не нужен. может быть как full time роль или part time? как внешний или внутренний игрок? руководитель или зам или кто то из верхней команды если мы говорим про молекулярные команды на 100 чел? или внешний консультант если мы говорим про атомарные команды 5-10 чел.
- еще интересно провести аналогии с Канбан - где есть деливери менеджеры - отвечающие за снятие блокеров и помех на пути доставки ценности. на мой взгляд очень созвучно со скрам мастером. в этом случае роль конечно должна быть полноценная.
- но там еще образуется туча но и если - все очень зависит от контекста процессов и особенностей команды.
Работая с 20+ командами, я пришел к выводу что в этом мире не все всегда и везде, а кое что иногда и местами.
Где то все ок было даже с 1 руководителем проектов во главе, без всяких там скрамов, продукт овнеров и скрам мастеров. хотя в других кейсах та же схема оказывалась провальна.
Где то есть эджайл-помесь: скрама, канбана и социократии. Скрам мастер или эджайл коуч или консультант - парт тайм - просто приходит на некоторые встречи и если есть проблемы - помогает решать - но при этом он технически подкован.
А где то все по науке - продукт овнер от бизнеса, скрам мастер полу психолог не бум бум в ИТ, и все артефакты на месте - но там сплошной карго культ и на такую команду и их результаты сложно смотреть без слез.
А еще я думаю скрам стал популярен не потому что у него простые формулировки, а потому что он проприетарный, платный и у него огромные бюджеты на рекламу и маркетинг.
Например его аналог Социократия S3 - опенсорсная, сильно понятней для меня, но не так популярна потому что не так сильно рекламируется.
React это ок ) он на своем месте. У него сообщество, компоненты, ui-kits ) в целом лидер без спора.
Если деать какой то большой продукт про систему Enterprise или Trello - все ок.
А что думаешь про SvelteJS? Он быстрее, легче, для классических сайтов он дешевле, проще, быстрее )
Интересно мнение )
в рф чтобы быть про вордпресс нужны яица )
но по миру все понятно.
топ компании мира переходят на вордпресс.
до рф это дойдет через 10-20 лет ) где то в 2032 году кто то что то поймет )
но рано или поздно дойдет )
там другая беда )
в WP ООП на основе сообщений, модулей и идей Алана Кея.
это в школе не преподают.
в школе преподают идеи Сазерленда про классы.
потому большинство кодеров имея знания про школу - думают так как Сазерленд и классы - идеал это Лара или Симфа.
а когда видят архитектуру на основе сообщений - это не понятно.
потому проще сказать что вордпресс плохо, чем понять что там просто другой тип ООП ) которому в школе не обучают )
чуть подробнее тут https://wpcraft.ru/blog/wordpress-eto-prosto/
Автор, не слушай местный токсицизм ) ты на верном пути )
WP это топ )
Просто 99% прогеров не понимают в чем сила )
А сила в правде, правда в том что это топ 1 в мире.
Там еще особый тип ООП - на базе сообщений - оч отличается от того чему учат всех в школах.
Потому 99% кодеров не понимают что это и думают что там все плохо.
Но правда в том что там все круто. Архитектура на столько сильная что большинство смогут понять это только через 10-20 лет ) если повезет )
Тут сравнение с симфой и ларой https://wpcraft.ru/blog/v-chem-raznicza-mezhdu-wordpress-symfony-laravel/
по мне так там все ограничено лишь желанием и усилиями. как и везде.
а так все ок. в 3-5 чел — вы входите. мы с вами на связи.
просто у вас сайтов много и не признал коллег по цеху ))
не ожидал такой статьи от вас. я думал у вас все ок ))
Я продаю плагины на ВП уже более 3 лет. И знаю еще 3-5 чел, которые делают тоже самое.
Понятно что большинство работают на западный рынок.
Но я работаю на РФ. Все ок )
Вообще не вижу проблем. Все проблемы в голове. Решаешь проблемы и дальше все хорошо.
Есть делема в таких выборах которая называется: Suite или Best of breed?
Ты либо выбираешь нечто универсальное, либо нечто узко специализированное.
У каждого подхода есть плюсы и минусы.
Бывало даже пытаешься разработать свое. Универсальное. Но там тоже фракталы и боли.
BPM & BPMN — это очень больная штука. Я в свое время наболелся и в итоге ушел в ACM (adaptive case management). По этой концепции работает AmoCRM, OmniDesk, FreeScout…
Это проще, гибче, легче.
В итоге я пришел к такой концепции:
1. Беру готовые best of breed без перегрузки функционала — типа AmoCRM, OmniDesk, GitHub…
2. Интегрирую их через IFTTT, Zapier или своими скриптами
3. На стыках процессов использую конструкторы типа Notion или Airtable.
Получается закрыть любые процессы. И при этом затраты на минималках.
Ну а в крупных бизнесах — многое пишется под себя. Но это очень рискованно, больно и дорого. Однако если все сделать хорошо, то бывает выгодно.
Что думаешь про подход, который выбрали в FreeScout? Тут описание habr.com/ru/post/477918
Цитирую:
По сути там Eventy как диспетчер событий.
1. можно вставлять события в разные части кода ядра или модулей
2. затем из других модулей подписываться на них и реагировать
например:
1. событие — пришла заявка
2. реакция модуля — отправить сообщение в Телеграм чат с содержанием и контактами.
SSR иногда может быть быстрее чем клиент рендер. Особенно в части получения первого экрана и его видимости для посетителя.
Но почти всегда медленнее чем SSG или fcgi-cache. Где то тут было сравнение SSR NextJS vs SSG GatsbyJS. SSG оказывался быстрее.
Если вы сделаете сайт на вордпрессе, с кучей кривого кода, где SSR и TTFB будет в районе 1 минуты, то просто fcgi-cache позволит получать страницу в те же 50-100 мс что у dev.to — если верстка будет более мене адекватная, то и показываться тоже будет быстро.
Бывают гибриды. Когда основной контент это SSG или SSR. Или SSR с кешем в SSG.
А интерактивные элементы и фрагменты страницы, контент которых зависит от пользователя — рендерятся на стороне клиента. Например похожим образом работает GitHub.
На мой взгляд ничего нового тут нет. Просто хайп вокруг клиентского ренденринга проходит. И может быть его даже перестанут пихать всюду где надо и не надо. Он останется только там где и был придуман — интерактивные веб приложения и виджеты. Например аппки типа Трелло, Чаты или виджет чата для сайта. Которые нельзя или сложно сделать через чистый SSR.
— монолит со структурой function-first или MVC — так можно рости пока у вас 1-2 команды по 5-10 человек
— когда команд становится 5-10 штук, то начинаются конфликты и ростут блокировки. тогда выгодно переходить в монолит на модулях или монолит feature-first или компонентно-ориентированное программирование или DDD как вариант — чтобы команды работали каждый над своей частью системы и сильно не мешали друг другу
— когда команд становится 100 штук, а программистов под 1000, тогда выгодно начинать уходить в микросервисы
Конечно рост по количеству программистов не единственный критерий выхода в микросервисы. еще могут быть узкие горлышки, необходимость применять иные языки программирования и стеки, переиспользование функционала и т д.
Главное понимать что без веских причин усложнять не стоит. И усложнять систему стоит только тогда когда это решает реальные проблемы. Потому что это решение не бесплатно, затраты очень сильно увеличиваются, и потому выгода должна оказаться больше чем те затраты и проблемы которые придут в комплекте.
Решение выдуманных проблем на волне хайпа вокруг очередной модной технологии создает больше проблем чем решает их. О чем как я понял автор и говорит в данной статье.
На счет C# я готов поверить что он будет быстрее. Но только в виртуальном мире.
В реальном мире все сложнее. Там много чего и чаще всего качество кода.
Если хорошо писать код, то они все быстрые.
В реальном мире — все зависит от программистов. И тут вопрос культуры конкретной команды и уровня специалистов.
В общем поменял в статье акценты. Сделал больше упор на модульность. DDD это лишь одна из вариаций. Сама по себе имеет ценность, но далеко не везде.
Сделал больше акцента на модульность и сообщения.
На мой взгляд это именно то что нужно для расширяемых систем.
SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.
Потому смотрим на что реально стреляет и применяется.
Системы на сообщениях — это когда модули общаются друг с другом и меняют поведение друг друга через сообщения.
В разных системах обмен сообщениям может быть построен через разные механики — события, хуки, триггеры.
Те примеры что приведены в статье — это малая часть, но там все именно так.
Согласен.
> При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
Тут важно отличать надежность от антихрупкости. Для этого нужно прочитать книгу. Объяснить это коротко боюсь не получится.
Плюс после этого поработать с большими и сложными системами построенными на статической типизации и на модулях с сообщениями и динамической типизацией. Сравнить их.
Но если брать его комменты из последних лет, то он уже пришел к мысли что речь была про модули и модульные системы )
Вот цитаты:
> Хрупкость и антихрупкость здесь – относительные понятия, а не абсолютные качества: объект, находящийся справа от точки отсчета, более антихрупок, чем объект, который находится слева.
> Как видит читатель, карта без каких-либо ограничений распространяется на любые области и сферы деятельности: культура, здравоохранение, биология, политические системы, технология, городское планирование, социально-экономическая жизнь и прочие явления
Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?
Ту же стратегию штанги отлично получается применять к покеру. Это вообще очень гибкая теория и ее применение возможно в самых разных областях.
Опять же сама по себе динамическая типизация не дает хрупкости. Выше в комментах где то писал. Гораздо важнее это модульность и сообщения. Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости. Меньше проблем с поздним связыванием и взаимодействием между модулями через сообщения. Но если очень хочется использовать статическую типизацию — то это тоже возможно.