У гибридов, в отличии от обычных бензиновых авто есть рекупирация. Именно за счёт неё достигается экономия. И батареи у гибридов маленькие. Они от этого"больше" бензина не жрут. Пообщайтесь с владельцамм последовательных гибридов, они вам хором скажут, что расход бензина гораздо меньше обычного бензинового авто.
Cursor это очень хорошо и полезно, особенно в умелых руках и с хорошими мозгами.
Но о чем статья - совершенно неясно. Я тоже восхищаюсь каждый день, как курсор мне ускоряет работу без потери качества. Но эти "вау" возгласы распространяю на ограниченный круг заинтересованных лиц.
Но конечно же, надо правильно измерить пушистость, почасовую ночную степень уплотнения, составить график износа, ассиметричности при попоротах головы и ещё 20-30 полезных атрибутов, чтобы подушки, наконец-то, можно было сравнить между собой. А то что они без шилдиков ходят...
А о командах, где есть системные аналитики( не бизнес аналитики)?
Как бы у вас взяты очень наколеночные стартап процессы,, где всё решают разработчики по ходу дела... это очень кустарный подход. Все продвинутые команды от этого уходят в сторону правильных процессов...
Почему вы под Системным аналитиком имеете ввиду фулстек аналитика???
Таких системных аналитиков делали 20 лет назад, когда бизнес не понимал что тако UI и разарботчики придумывали всё за бизнес.
В современном мире разработки , в совремнных компаниях, эти роли разделены.
Бизнес аналитик проектирует "Что" делает система. И вот там BPMN, CJM, юзкейсы и прочее... и ему пофигу, прокините вы это через 1 монолит или 20 микросервисов.
Системный аналитик проектирует "Как" это реализовано в системе. И вот тут начинаются БД, журналы, ресты и прочее, в купе с архитектурой.
Это две разные роли.
Объединять их в одну это устарело лет 5-10 назад.
А джуны читают этот ваш "полный гайд" и становятся недоаналитиками во всём.
Как бы адекватный SA должен проектировать. Но если проектируют разработчики "на коленках по ходу написания кода", то SA что может сделать? Пойти руководству настучать "у вас процессы говно"???
Как бы процессы обычно выстраивают либо сверху, и тогда надо делать вэбинар для руководителей, либо они сами ввстраиваются " кто как модет", и тогда разрабы, привыкшие писать отсеьятину, пошлют SA с его инициативами ... записывать за ними их гениальный код.
Из моего опыта упущен важный момент: вы рассматриваете команду как некий юнит, который решает задачи. В практике, где вся команда - универсалы и могут делать любые задачи (писать код, тестировать, писать доку) это работает.
Как только вы выделяете в команде роли ( системный аналитик, FE,BE разработчики, QA) то процесс ломается. Потому что для команды статус "в работе", а внутри это передача от этапа к этапу. И отслеживать это становится невозмодно и все виплимиты идут лесом...
Если есть опыт канбана в командах с несколькими ролями - опишите пожалуйста.
Вы никогда не думали, что делая подробное ТЗ вы делаете двойную работу? Вначале аналитик подробно описывает все алгоритмы и спецификации, а потом разработчик делает то же самое, но на другом языке.
Это некорректно сравнение. Разработчик производит код. Это результат.
Документация описывает этот код.
Вы же не будете утверждать, что план разводки розеток и сами провода, лежащие в стене, это одно и тоже???
Я пытаюсь себе представить аналогию с ремонтом. Вы взяли сантехника, электрика, и маляра и вовлекли в продумывание дизайна квартиры...
Сомнительная эффективность, как по мне.
Почему вы не стали выстраивать качественный процесс с системным анлаизом? Чтобы каждый занимался своим профессиональным делом, а не думал о "чужих" областях?
Самая лучшая стимуляция спроса - это повышение качества и доступности.
А у нас выпускаются электрические модели, которые летом проезжают в лучшем случае 350 км между подзарядками, а зимой около 100.
Поэтому этот рынок реально интересен только домовладельцам со своей розеткой.
Хотите продавать больше электричек ? Ставьте современные аккумуляторы с запасом хода 500+ в любых условиях.
Вообще-то это не так.
У гибридов, в отличии от обычных бензиновых авто есть рекупирация. Именно за счёт неё достигается экономия. И батареи у гибридов маленькие. Они от этого"больше" бензина не жрут. Пообщайтесь с владельцамм последовательных гибридов, они вам хором скажут, что расход бензина гораздо меньше обычного бензинового авто.
https://t.me/eu_academia_cs_ai не находит...
Хранение *.docx в гите это вообще не doc as code.
Соглашусь с комментами выше - ну очень странный путь...
Cursor это очень хорошо и полезно, особенно в умелых руках и с хорошими мозгами.
Но о чем статья - совершенно неясно. Я тоже восхищаюсь каждый день, как курсор мне ускоряет работу без потери качества. Но эти "вау" возгласы распространяю на ограниченный круг заинтересованных лиц.
Табличку "сарказм" надо вывешивать...
Потому что выглядит иначе...
У вас есть подушка.
Она либо удобная либо нет.
Но конечно же, надо правильно измерить пушистость, почасовую ночную степень уплотнения, составить график износа, ассиметричности при попоротах головы и ещё 20-30 полезных атрибутов, чтобы подушки, наконец-то, можно было сравнить между собой. А то что они без шилдиков ходят...
Очередной скрамбан.
Кажется 90% недовольных скра ом понятия не имеют, в чём же его суть.
Ритуалы ритуалят и удивляются, что не работает.
Ну так и канбан без понимания сути у вас не заработает.
Кажется, у вас не было скрама. Если ничего не сломалось от отмены церемоний, значит это были просто тупые церемонии.
Если вы не понимаете, зачем нужна ретра, то конечно она у вас работать не будет.
Вобщем, спасибо что поделились признанием ваших менеджерских способностей.
А вы о подходе documentation first знаете?
А о командах, где есть системные аналитики( не бизнес аналитики)?
Как бы у вас взяты очень наколеночные стартап процессы,, где всё решают разработчики по ходу дела... это очень кустарный подход. Все продвинутые команды от этого уходят в сторону правильных процессов...
Почему вы продолжаете это делать?
Почему вы под Системным аналитиком имеете ввиду фулстек аналитика???
Таких системных аналитиков делали 20 лет назад, когда бизнес не понимал что тако UI и разарботчики придумывали всё за бизнес.
В современном мире разработки , в совремнных компаниях, эти роли разделены.
Бизнес аналитик проектирует "Что" делает система. И вот там BPMN, CJM, юзкейсы и прочее... и ему пофигу, прокините вы это через 1 монолит или 20 микросервисов.
Системный аналитик проектирует "Как" это реализовано в системе. И вот тут начинаются БД, журналы, ресты и прочее, в купе с архитектурой.
Это две разные роли.
Объединять их в одну это устарело лет 5-10 назад.
А джуны читают этот ваш "полный гайд" и становятся недоаналитиками во всём.
Ну, тоесть ,SA должен своего техдира привести на вэбинар что ли?))
Я не понял для кого этот вэбинар....
Как бы адекватный SA должен проектировать. Но если проектируют разработчики "на коленках по ходу написания кода", то SA что может сделать? Пойти руководству настучать "у вас процессы говно"???
Как бы процессы обычно выстраивают либо сверху, и тогда надо делать вэбинар для руководителей, либо они сами ввстраиваются " кто как модет", и тогда разрабы, привыкшие писать отсеьятину, пошлют SA с его инициативами ... записывать за ними их гениальный код.
Да, но виплимиты тогда не работают.
Мне надо переводить в тестирование, а там уже 5 из 5ти...
Из моего опыта упущен важный момент: вы рассматриваете команду как некий юнит, который решает задачи. В практике, где вся команда - универсалы и могут делать любые задачи (писать код, тестировать, писать доку) это работает.
Как только вы выделяете в команде роли ( системный аналитик, FE,BE разработчики, QA) то процесс ломается. Потому что для команды статус "в работе", а внутри это передача от этапа к этапу. И отслеживать это становится невозмодно и все виплимиты идут лесом...
Если есть опыт канбана в командах с несколькими ролями - опишите пожалуйста.
О, и спасибо за минус! Что ещё ждать от российского автопрома!
Чушь какая!
Ничего оно не объединяет!
Очередное отдельностоящее приложение.
Ну добавили энергию москвы, а яндекс проигнорили.
Есть более охватывающие приложения, где действительно есть почти все зарядные станции. 2chargers например!
Это просто дребедень!
Это некорректно сравнение. Разработчик производит код. Это результат.
Документация описывает этот код.
Вы же не будете утверждать, что план разводки розеток и сами провода, лежащие в стене, это одно и тоже???
Эмм... нет, это компании с незрелыми процессами разработки так работают.
Компании со зрелыми процессами давно работают с documentation first. А те кто хотят это делать быстро и эффективно реализуют его через doc as code.
Я пытаюсь себе представить аналогию с ремонтом. Вы взяли сантехника, электрика, и маляра и вовлекли в продумывание дизайна квартиры...
Сомнительная эффективность, как по мне.
Почему вы не стали выстраивать качественный процесс с системным анлаизом? Чтобы каждый занимался своим профессиональным делом, а не думал о "чужих" областях?