Да твою-ж... Когда ты успокоишься?! твой `$mol` - это по дефолту +nn млн руб в мес, просто за счет разработчиков (а если взять качество кода - умножай на 2+). Говорю как человек, который взял vue / flutter / jquery / mol и сделал вывод (но да, я не "настоящий фронт")
если относится к "пет-проекту" (как же мне не нравится это словосочетание) как к хобби - всё становится на свои места (и про "нужность", и про "одиночество", и про время)
если относится как к бизнесу - нужен и подход как к бизнесу, тут сразу отпадает и "нужность" (производителю не нужно то, что он производит), и "одиночество" (делать бизнес в одно лицо - ОЧЕНЬ сложно), и про время
А команда остается одна, совсем одна, и ей должно быть с этим абсолютно нормально.
Имхо... Если команде нужен "скрам-мастер" - с командой что-то не так. Или с процессами. Или с руководством (настаивают на скраме там, где он не нужен или вреден).
Там очень много Скрам-мастеров и ещё больше команд, и действительно все команды зрелые, самостоятельные и просто обращаются к Скрам-мастерам с запросами провести ретро, профасилитировать определённое событие, создать тематический воркшоп
Вы сейчас серьезно? "Провести ретро"? "Профасилитировать"? Может проще создать мастер-классы для лидов тогда уж? Для чего еще один человек-то?
Общаясь со Скрам-мастерами в других организациях, я поняла, что многие могут вести по 2, 3, и даже 4 команды одновременно
"Многие"?! По опыту - 99.999%, на остальных просто команд не осталось.
Но как?
"Спустя рукава". Снова по опыту. Чаще всего это выглядит так:
"скрам-мастер": сегодня ретро, рассказывайте какие были проблемы за 2 недели
...
"скрам-мастер": я записал, встретимся через 2 недели
Или "от обратного":
"скрам-мастер": сегодня ретро, рассказывайте какие были проблемы за 2 недели
...
"скрам-мастер": ага, я понял, поставил всем встречи на следующие 2 недели
Команда поняла, какие процессы вы уже настроили?
Команда поняла, зачем вы настроили процессы таким образом?
Я правильно прочёл: "скрам-мастер" настроил процессы так, как он видит, без согласования с командой? Прям вспоминаю "продактов" - "скрам-мастеров" в ДеливериКлаб (
Моя команда сразу отменила Спринт-ретроспективу!
Причину озвучили?
Далее общалась с командой через one-to-one встречи
А, ну да, второй вариант: "ага, я понял, поставил всем встречи на следующие 2 недели"
Вывод 3: Контракт c командой
Бомба-пушка... Вопрос: а до этого момента реально не было такой мысли?!
Мы с командой за несколько встреч (только на Спринт Ретроспективах)
Видны подвижки... Правда не в ту сторону... Почему-бы не сделать обычный опрос через гугл-формы или аналог? Понять болевые точки и разработать план, который потом предоставить команде "НА ОБСУЖДЕНИЕ"? Ммм... Сорри, чёт меня понесло...
Вывод 4: Сразу отдавать команде то, что она уже может делать самостоятельно.
О, добрались до нужного... Но, не всё так радужно, да?)
Как мы это делали: есть люди в команде, которые могут как-то тащить Скрам-процессы, я попросила прекратить их это делать.
no comments
Мой вывод (никого ни к чему не призываю): скрам-мастера не нужны, это как риэлторы - вроде что-то делают, но по факту "делают" 0.01%, а остальные "делают вид что что-то делают".
ПыСы: отдельный "респект" за навязывание всяких "демо", "митапов" и пр.
С автором поста я не согласен (коммент выше), но вы пишите бред (сорян):
Скрам – это плохая практика управления для "небольшой команды"
Почему "плохая"? Почему "для небольшой команды"? Для "большой" уже "хорошая"? Где граница? Есть личный опыт использования "недо-скрама" для команд в 2-3 человека - норм.
Автор мог бы спросить у ChatGPT или Википедии.
А чего не у "дяди Васи"?
Например, ChatGPT выдал такое определение: "Методология проектирования (или проектирования систем) - это набор принципов, подходов, практик и процессов, используемых для разработки и построения технических и информационных систем".
Где тут противоречие скраму? Если вы уперлись в слово "проектирование" - у меня для вас плохие новости...
И скрама в определении нет.
А еще в определении нет разработчиков, девопсов, железа и пр. Они не участвую в "проектировании"?
Принципы проектирования программного обеспечения. Автор снова путается. Для него принципы проектирования сводятся к патернам. Вероятно, он сам не знает что такое принципы KISS, YAGNI, dry, SOLID и пр.
Тут полностью согласен, добавить нечего.
Знание нескольких языков программирования (включая любимый автором статьи питон) не делает из человека программиста.
А кто такой "программист"? Судя по названию - тот, кто пишет программы, верно? Тогда, вроде как, всё верно - знание языков ДЕЛАЕТ "из человека программиста".
Но, думаю, вы говорили про "инженера"?
Можно провести аналогию. Много людей умеют писать по русски (английски, французски, …), но большинство из них не может написать даже небольшой рассказ.
Значит ли это, что они не могут "писать"? Аналогия ОЧЕНЬ странная.
Кстати, такие известные писатели и поэты как, Пушкин, Баратынский, Маяковский, Кэрролл, Хемингуэй, Кристи и много других были безграмотными и писали с ошибками.
Что не мешает называть их поэтами/писателями/etc? Тогда почему нельзя человека, изучившего пару-тройку ЯП называть "программистом"?
Наверное, более правильно определять уровень программиста поговорив с ним о тех проектах, в разработке которых он принимал участие и какую роль выполнял в них.
Нет. Люди ОЧЕНЬ любят приукрашивать свои достижения (некоторые наоборот - приуменьшать).
Таки образом можно будет определить уровень сложности проектов, которые кандидат сможет разрабатывать.
А чем это отличается от алгоритмических задач? И то, и другое можно "зазубрить", не имея навыков искать решения проблем, выходящих за пределы рутины.
А если посмотреть как изменялась его роль в проектах, то можно оценить его амбициозность.
Ох, ок, мой опыт на одном из проектов: пришел 5м разработчиком, год стал лидом, через 2 руководителем отдела из 12 человек. Что вам это скажет?
Рекомендую вам более внимательно ознакомиться с паттернами проектирования
Rly? Часто встречал (да и чего уж там - сам точно такой-же), когда человек не знает названия паттернов, но успешно их применяет. Но на собесах, чаще всего, необходимы именно названия...
Самый смешной случай был, когда собеседующий спросил про mvc, но именно для него mvc === ооп. Чуть ушел в сторону и он "поплыл" со словами "без ооп невозможно реализовать mvc".
Умение заставить себя при программировании каждый раз выполнять самопроверку, продвинет вас на шаг вперёд.
Тут точно подразумевается "вспомнить, как называется паттерн"?
А хорошо ли вы знаете этот язык и то, как он работает «под капотом»?
Ну раз уж выше про python: сколько, на вашем опыте, разработчиков смотрели исходники python?
Опытные инженеры должны уметь руководить командой
Нет. Сысоев сделал классный инструмент, не умея руководить - он плохой инженер? Я могу сотни таких примеров привести.
Благодаря этой подписке я сумел получить мою нынешнюю работу.
Т.е. не благодаря кругозору, "софт-скиллам" (о чем говорится прям пунктом выше), а благодаря алгоритмическим задачам? Это ли не показатель "нормального" "сеньор-инженера"?
Именно этих навыков все ожидают от старшего инженера.
Ммм... Нет.
Пост - странный... Ощущение, что человек случайно стал "сеньором" и теперь раздает советы (
"ИИ не пострадала"... Вы так и не поняли? Пострадали те, кто читают пост и "вашу работу". Очень хочется ругаться, но да ладно, каждый выбирает свой путь...
что кто-то из них позднее сможет построить конкурента на стороне
Каких только "обоснований" микросервисам не слышал, но вот такое впервые... "Построить конкурента"? Вы серьезно? Вон, доступен код почти всех сервисов Яндекса. Много конкурентов появилось?
Цикл — разновидность управляющей конструкции в высокоуровневых языках программирования, предназначенная для организации многократного исполнения набора инструкций. Также циклом может называться любая многократно исполняемая последовательность инструкций, организованная любым способом (например, с помощью условного перехода).
А уж как опрос коррелирует с постом... А как в тему "О сервисе Онлайн Патент"... Вроде интересный пост, а итог - да идите на..уй. @Boomburumумоляю, дайте возможность блокировать в ленте хотя-б вот такое!!!
Да твою-ж... Когда ты успокоишься?! твой `$mol` - это по дефолту +nn млн руб в мес, просто за счет разработчиков (а если взять качество кода - умножай на 2+). Говорю как человек, который взял vue / flutter / jquery / mol и сделал вывод (но да, я не "настоящий фронт")
Это первый пункт моего коммента выше ;)
если относится к "пет-проекту" (как же мне не нравится это словосочетание) как к хобби - всё становится на свои места (и про "нужность", и про "одиночество", и про время)
если относится как к бизнесу - нужен и подход как к бизнесу, тут сразу отпадает и "нужность" (производителю не нужно то, что он производит), и "одиночество" (делать бизнес в одно лицо - ОЧЕНЬ сложно), и про время
Да кто-ж даст-то?)
Сейчас отхвачу, но всё-таки:
"Скраму", с большой буквы... Серьезно? Ну ок...
Имхо... Если команде нужен "скрам-мастер" - с командой что-то не так. Или с процессами. Или с руководством (настаивают на скраме там, где он не нужен или вреден).
Вы сейчас серьезно? "Провести ретро"? "Профасилитировать"? Может проще создать мастер-классы для лидов тогда уж? Для чего еще один человек-то?
"Многие"?! По опыту - 99.999%, на остальных просто команд не осталось.
"Спустя рукава". Снова по опыту. Чаще всего это выглядит так:
"скрам-мастер": сегодня ретро, рассказывайте какие были проблемы за 2 недели
...
"скрам-мастер": я записал, встретимся через 2 недели
Или "от обратного":
"скрам-мастер": сегодня ретро, рассказывайте какие были проблемы за 2 недели
...
"скрам-мастер": ага, я понял, поставил всем встречи на следующие 2 недели
Я правильно прочёл: "скрам-мастер" настроил процессы так, как он видит, без согласования с командой? Прям вспоминаю "продактов" - "скрам-мастеров" в ДеливериКлаб (
Причину озвучили?
А, ну да, второй вариант: "ага, я понял, поставил всем встречи на следующие 2 недели"
Бомба-пушка... Вопрос: а до этого момента реально не было такой мысли?!
Видны подвижки... Правда не в ту сторону... Почему-бы не сделать обычный опрос через гугл-формы или аналог? Понять болевые точки и разработать план, который потом предоставить команде "НА ОБСУЖДЕНИЕ"? Ммм... Сорри, чёт меня понесло...
О, добрались до нужного... Но, не всё так радужно, да?)
no comments
Мой вывод (никого ни к чему не призываю): скрам-мастера не нужны, это как риэлторы - вроде что-то делают, но по факту "делают" 0.01%, а остальные "делают вид что что-то делают".
ПыСы: отдельный "респект" за навязывание всяких "демо", "митапов" и пр.
Озон ;)
И четвертый - компании, живущие десятилетиями (а то и больше) на инвесторские деньги.
С автором поста я не согласен (коммент выше), но вы пишите бред (сорян):
Почему "плохая"? Почему "для небольшой команды"? Для "большой" уже "хорошая"? Где граница? Есть личный опыт использования "недо-скрама" для команд в 2-3 человека - норм.
А чего не у "дяди Васи"?
Где тут противоречие скраму? Если вы уперлись в слово "проектирование" - у меня для вас плохие новости...
А еще в определении нет разработчиков, девопсов, железа и пр. Они не участвую в "проектировании"?
Тут полностью согласен, добавить нечего.
А кто такой "программист"? Судя по названию - тот, кто пишет программы, верно? Тогда, вроде как, всё верно - знание языков ДЕЛАЕТ "из человека программиста".
Но, думаю, вы говорили про "инженера"?
Значит ли это, что они не могут "писать"? Аналогия ОЧЕНЬ странная.
Что не мешает называть их поэтами/писателями/etc? Тогда почему нельзя человека, изучившего пару-тройку ЯП называть "программистом"?
Нет. Люди ОЧЕНЬ любят приукрашивать свои достижения (некоторые наоборот - приуменьшать).
А чем это отличается от алгоритмических задач? И то, и другое можно "зазубрить", не имея навыков искать решения проблем, выходящих за пределы рутины.
Ох, ок, мой опыт на одном из проектов: пришел 5м разработчиком, год стал лидом, через 2 руководителем отдела из 12 человек. Что вам это скажет?
Тут снова согласен.
Закончим на этом?)))
Rly? Часто встречал (да и чего уж там - сам точно такой-же), когда человек не знает названия паттернов, но успешно их применяет. Но на собесах, чаще всего, необходимы именно названия...
Самый смешной случай был, когда собеседующий спросил про mvc, но именно для него mvc === ооп. Чуть ушел в сторону и он "поплыл" со словами "без ооп невозможно реализовать mvc".
Тут точно подразумевается "вспомнить, как называется паттерн"?
Ну раз уж выше про python: сколько, на вашем опыте, разработчиков смотрели исходники python?
Нет. Сысоев сделал классный инструмент, не умея руководить - он плохой инженер? Я могу сотни таких примеров привести.
Т.е. не благодаря кругозору, "софт-скиллам" (о чем говорится прям пунктом выше), а благодаря алгоритмическим задачам? Это ли не показатель "нормального" "сеньор-инженера"?
Ммм... Нет.
Пост - странный... Ощущение, что человек случайно стал "сеньором" и теперь раздает советы (
"ИИ не пострадала"... Вы так и не поняли? Пострадали те, кто читают пост и "вашу работу". Очень хочется ругаться, но да ладно, каждый выбирает свой путь...
Как связаны "сообщил" и ваши выводы?
А там ничего не меняется)))) План есть, а будет ли выполнен - зависит от... миллиарда вещей)
Это верно. Как и то, что в 99.99% случаев код не играет никакой роли, важны данные и процессы. Большинство сервисов не имеет каких-либо ноу-хау.
Каких только "обоснований" микросервисам не слышал, но вот такое впервые... "Построить конкурента"? Вы серьезно? Вон, доступен код почти всех сервисов Яндекса. Много конкурентов появилось?
А чего бы не сравнить кислое с мягким? О_о
Ваш случай? Ваш «автомат» - это «многократно исполняемая последовательность инструкций», организованная «внешним реализатором», так?
Это ваше утверждение ниже. И оно ложное. Повторяемый вызов и есть цикл.
Но, чёт я устал от троллинга или глупости (выбирать вам), пожалуй закончим диалог.
Вы сами с собой общаетесь? Я, вроде, задал простой вопрос.
И да, на скрине 2 разных алгоритма, один с циклом, другой нет.
Но вопрос был про то, что в посте.
По какому пункту не подходит?
А уж как опрос коррелирует с постом... А как в тему "О сервисе Онлайн Патент"...
Вроде интересный пост, а итог - да идите на..уй. @Boomburumумоляю, дайте возможность блокировать в ленте хотя-б вот такое!!!