Все правильно, не собирался обсуждать эту роль, поэтому ее и опустил для простоты. Мой комментарий ни в коем случае не полный, там очень все поверхностно, только чтобы обозначить несколько серьезных проблем.
В целом, да, много где плохо. При этом не согласен про «везение» в хороших командах. И не согласен, что не получится мотивировать (при изменениях часть людей начнет работать, часть уйдет).
При этом на Хабре рассуждать про управление достаточно неуместно, т.к. участники обсуждения слишком разные, чтобы донести свою мысль (а уж чтобы еще и мысль понравилась (из-за голосований), так вообще непонятно зачем).
Если совсем поверхностно, то уже существуют методологии, которые решают проблему сложности нахождения технических менеджеров. Например, не к ночи упомянутый Скрам. Там нет понятий менеджер, пм, тимлид и техлид. Есть плоская команда и скрам мастер. Скрам мастер — это скорее помошник-психолог (без ИТ образования), чем менеджер или технарь, т.к. она только организовывает процессы и разрешает личностные конфликты. Вместо техлидов возможны гильдии и коучи гильдий — при этом они не менеджеры и не техлиды.
При этом при типичном внедрении Скрама почему-то остаются менеджеры и техлиды. И Скрам не работает (или работает), хотя его даже не пробовали.
И понятно, что это не панацея, и нужно смотреть на конкретную компанию, чтобы понять как улучшить там процессы. Другое дело, что у кого-то не хватает знаний, где-то менеджеры боятся ухудшить текущую ситуацию, где-то что-то еще, но это не значит, что все случайно, и системного подхода не существует.
Тролинг понятен, но все же это игрушка, и AIBO — игрушка. Как по мне, отсутствие цели или другими словами замены человека в чем-то и определяют, что это игрушка.
Обычно это распадается на 2 подпроблемы:
* работа с миниатюрными нагрузками относительно обычного человека: например, этот робот не сможет утащить за мной пакеты с продуктами из магазина. Тут нужно учитывать, что чем больше веса, тем больше это стоит.
* развлекательный или обучающий характер: у робота нет реальной полезной цели:
— для робота-носильщика нужно доделывать куда класть груз (даже без увеличения мощности — например, лекарства по палатам развозить)
— для робота-охранника нужно доделывать ПО и реализовать возможность автоматической зарядки (да и несколько датчиков типа температуры и протечки на руке-манипуляторе не помешают)
Мне кажется, что нужно рассмотреть немного более сложный случай, т.к. ES все-таки не для hello world / CRUD. Например, добавить бизнес-правила:
1 задачу можно завершить не ранее, чем через 5 минут после создания
2 можно изменить описание задачи, но не более 5 раз
И добавить комментарии к задаче.
Так мы увидим
— как в команде реализуются бизнес-отказы
— как восстанавливается состояние объекта из событий, чтобы принять решение
— что при одном агрегаторе (таск) может быть несколько объектов (таск и комментарии).
> Все работали из дома, делали уроки и решали какие-то бытовые вопросы черт знает на чем.
Я же правильно понимаю, что была куплена Home версия, а на ней работать нельзя (можно только «домашнее задание для школы» делать)? В обычное время иногда нужно пару документов подправить по работе, а на изоляции гораздо больше. При этом в статье ничего про запрет коммерческого использования нет.
Вряд ли Spring Boot быстро наверстает поддержку GraalVM. Основная проблема в рефлексии. Quarkus как раз основное что делает — избавляется от рефлексии.
> Правда, эксперименты с Quarkus также помогли мне осознать, какие многочисленные несчастья ожидают тех, кто попытается применить Quarkus с классическими серверами приложений Jakarta EE.
С одной стороны — это не цель Quarkus (цель — cloud native микросервисы и функции). А с другой непонятно о чем речь.
Вопросы странные. Половину и так можно узнать, половина не влияет на принятие решения устраиваться или нет. Разве что зачем-то хочется «ответить» таким же количеством вопросов к «компании», что она задает.
Вместо 30 вопросов я бы определился что важно в новой работе, что нет. Часть критериев будет видно уже из описания, пару вещей можно и на собеседовании спросить. Например, я всегда спрашиваю про переработки, чтобы понять стиль работы компании и на сколько виртуально нужно уменьшать зп. А так же про общую схему найма и следующие шаги.
Сам вопрос подразумевает, что вы не верите, что написанное может быть реализовано. И не потому, что нет необходимых навыков у менеджера, а потому что это связано с некоей спецификой. Наверное, особого смысла менеджмент обсуждать на этом сайте нет…
«Настоящий» PR — как «настоящий» мужчина или «настоящая» женщина — понятие ускользающее… PR — это PR, вполне осязаемая вещь в гите и процесс вокруг этой вещи. Где противоречие с описанным в статье — непонятно.
Не, вы передергиваете. Есть задача как некая ценность для заказчика, а есть задача как квант работы для исполнителя. И можно выстроить много уровней между ними (эпик, стори, сабтаск — если в терминах Jira, например). Так вот нижний уровень всегда может быть достаточно маленьким.
Например, вы отводите ветку и начинаете разрабатывать новый офигенный алгоритм. Недели 3 по предварительной оценке на первый этап. Но в каждый конкретный день вы делаете вполне определенные вещи — их и можно класть в PR. Например, несколько вспомогательных функций для работы с многопоточностью.
И вовсе не обязательно, чтобы в первый же день были детально расписаны задачи на все 3 недели: достаточно описания общего плана, а конкретные работы создаются на ближайшие дни — на горизонт видимости. Или даже закрывать задачи по факту: отработали день, посмотрели что получилось в PR, описали.
Опять же, может задачка и не заканчивается PR — что-то попробовали, приложили к задачке отчет о неудачной гипотезе и пошли дальше.
А вот чтобы закончилось 100+ измененных файлов — это просто явное или не явное нежелание делать работу постепенно.
Другими словами PR — это процессный (менеджерский) инструмент. У него есть ограниченная применимость, как и у любого инструмента. Например, меньше 100 файлов в PR, а то отдача от процесса PR будет низкая. Для хорошей стыковки это накладывает ограничения на размер задач исполнителей. Можно ли их сделать небольшими? Да. Нужно ли? Отдельный вопрос, тут нужно смотреть на всю систему управления, но обычно это так же считается best practice. Искусство тут не в специфике задач, а в процессе разбиения задач на подзадачи: если кратко постфактум можно описать что исполнитель делал, то и задачу такую можно поставить и такой PR сформировать. Истории из серии «сегодня продолжаю работать и завтра над этим работаю» — просто нежелание по той или иной причине описать что реально делалось.
PS. Ладно, что-то много уже написал. Надеюсь, точка зрения понятна.
Что проверять всегда ясно — соблюдение соглашений разработки, best practices, опечатки, логические ошибки. Новый код покрыт тестами и не падает, но не весь старый функционал может работать. Никаких «финальных» PR.
> Про 95/5, я думаю, это от области работы зависит. У нас это, скорее, 30/70 — RnD.
Не верю. Просто не выработан навык разбивать большие задачи на задачи на 1-2 дня (1 задача — 1 PR и при таких временных рамках он редко большой).
Нужно это или не нужно в вашем случае — отдельный вопрос. Может вам PR вообще не нужны, если вы только прототипы делаете, а не production-код.
И что? В условиях аврала наоборот нужно достаточно часто показывать как получается, такое за 1 итерацию не сдается (и не заработает за 1 итерацию нормально). По идее накладных расходов на это не должно быть (если все пайплайны уже готовы до аврала).
раньше его добвляли в url (при включенных куках):
```
/some/;jsessionid=E85FAC04E331FFCA55549B10B7C7A4FA
```
а сейчас есть хранилища и без кук: localStorage, sessionStorage, indexeddb
так что по идее нет технических преград для приложений, а вот для слежки как раз только cookies и загрузка ресурсов (картинки, js) подходят, как я понимаю
Ну, все-таки, чтобы собиралось нужно стараться. А вот не все тесты прошли и не все функционально готово — да, иногда этим придется пожертвовать. Альтернатива — PR с багами, который особо не смотрели.
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Исключения всегда есть, но это исключения (5%/95%).
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
PR не означает, что новая функциональность доступна. Можно, например, включать через feature flags.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.
Если посмотреть на техническую часть, то удивил мониторинг процессов через Telegram: с ним борятся, время от времени сбоит, а тут коммерческая компания завязывается на запрещенный сервис. Уж легче бесплатный тариф Slack — вероятность, что будет работать все равно выше.
При этом на Хабре рассуждать про управление достаточно неуместно, т.к. участники обсуждения слишком разные, чтобы донести свою мысль (а уж чтобы еще и мысль понравилась (из-за голосований), так вообще непонятно зачем).
Если совсем поверхностно, то уже существуют методологии, которые решают проблему сложности нахождения технических менеджеров. Например, не к ночи упомянутый Скрам. Там нет понятий менеджер, пм, тимлид и техлид. Есть плоская команда и скрам мастер. Скрам мастер — это скорее помошник-психолог (без ИТ образования), чем менеджер или технарь, т.к. она только организовывает процессы и разрешает личностные конфликты. Вместо техлидов возможны гильдии и коучи гильдий — при этом они не менеджеры и не техлиды.
При этом при типичном внедрении Скрама почему-то остаются менеджеры и техлиды. И Скрам не работает (или работает), хотя его даже не пробовали.
И понятно, что это не панацея, и нужно смотреть на конкретную компанию, чтобы понять как улучшить там процессы. Другое дело, что у кого-то не хватает знаний, где-то менеджеры боятся ухудшить текущую ситуацию, где-то что-то еще, но это не значит, что все случайно, и системного подхода не существует.
Обычно это распадается на 2 подпроблемы:
* работа с миниатюрными нагрузками относительно обычного человека: например, этот робот не сможет утащить за мной пакеты с продуктами из магазина. Тут нужно учитывать, что чем больше веса, тем больше это стоит.
* развлекательный или обучающий характер: у робота нет реальной полезной цели:
— для робота-носильщика нужно доделывать куда класть груз (даже без увеличения мощности — например, лекарства по палатам развозить)
— для робота-охранника нужно доделывать ПО и реализовать возможность автоматической зарядки (да и несколько датчиков типа температуры и протечки на руке-манипуляторе не помешают)
Мне кажется, что нужно рассмотреть немного более сложный случай, т.к. ES все-таки не для hello world / CRUD. Например, добавить бизнес-правила:
1 задачу можно завершить не ранее, чем через 5 минут после создания
2 можно изменить описание задачи, но не более 5 раз
И добавить комментарии к задаче.
Так мы увидим
— как в команде реализуются бизнес-отказы
— как восстанавливается состояние объекта из событий, чтобы принять решение
— что при одном агрегаторе (таск) может быть несколько объектов (таск и комментарии).
Я же правильно понимаю, что была куплена Home версия, а на ней работать нельзя (можно только «домашнее задание для школы» делать)? В обычное время иногда нужно пару документов подправить по работе, а на изоляции гораздо больше. При этом в статье ничего про запрет коммерческого использования нет.
> Правда, эксперименты с Quarkus также помогли мне осознать, какие многочисленные несчастья ожидают тех, кто попытается применить Quarkus с классическими серверами приложений Jakarta EE.
С одной стороны — это не цель Quarkus (цель — cloud native микросервисы и функции). А с другой непонятно о чем речь.
Вместо 30 вопросов я бы определился что важно в новой работе, что нет. Часть критериев будет видно уже из описания, пару вещей можно и на собеседовании спросить. Например, я всегда спрашиваю про переработки, чтобы понять стиль работы компании и на сколько виртуально нужно уменьшать зп. А так же про общую схему найма и следующие шаги.
Сам вопрос подразумевает, что вы не верите, что написанное может быть реализовано. И не потому, что нет необходимых навыков у менеджера, а потому что это связано с некоей спецификой. Наверное, особого смысла менеджмент обсуждать на этом сайте нет…
Например, вы отводите ветку и начинаете разрабатывать новый офигенный алгоритм. Недели 3 по предварительной оценке на первый этап. Но в каждый конкретный день вы делаете вполне определенные вещи — их и можно класть в PR. Например, несколько вспомогательных функций для работы с многопоточностью.
И вовсе не обязательно, чтобы в первый же день были детально расписаны задачи на все 3 недели: достаточно описания общего плана, а конкретные работы создаются на ближайшие дни — на горизонт видимости. Или даже закрывать задачи по факту: отработали день, посмотрели что получилось в PR, описали.
Опять же, может задачка и не заканчивается PR — что-то попробовали, приложили к задачке отчет о неудачной гипотезе и пошли дальше.
А вот чтобы закончилось 100+ измененных файлов — это просто явное или не явное нежелание делать работу постепенно.
Другими словами PR — это процессный (менеджерский) инструмент. У него есть ограниченная применимость, как и у любого инструмента. Например, меньше 100 файлов в PR, а то отдача от процесса PR будет низкая. Для хорошей стыковки это накладывает ограничения на размер задач исполнителей. Можно ли их сделать небольшими? Да. Нужно ли? Отдельный вопрос, тут нужно смотреть на всю систему управления, но обычно это так же считается best practice. Искусство тут не в специфике задач, а в процессе разбиения задач на подзадачи: если кратко постфактум можно описать что исполнитель делал, то и задачу такую можно поставить и такой PR сформировать. Истории из серии «сегодня продолжаю работать и завтра над этим работаю» — просто нежелание по той или иной причине описать что реально делалось.
PS. Ладно, что-то много уже написал. Надеюсь, точка зрения понятна.
> Про 95/5, я думаю, это от области работы зависит. У нас это, скорее, 30/70 — RnD.
Не верю. Просто не выработан навык разбивать большие задачи на задачи на 1-2 дня (1 задача — 1 PR и при таких временных рамках он редко большой).
Нужно это или не нужно в вашем случае — отдельный вопрос. Может вам PR вообще не нужны, если вы только прототипы делаете, а не production-код.
```
/some/;jsessionid=E85FAC04E331FFCA55549B10B7C7A4FA
```
а сейчас есть хранилища и без кук: localStorage, sessionStorage, indexeddb
так что по идее нет технических преград для приложений, а вот для слежки как раз только cookies и загрузка ресурсов (картинки, js) подходят, как я понимаю
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.