Очень больная ветка, я чуть не заплакал

А я боюсь читать вот такие вот истории, тк на своей работе этого не делаю. И типа когда пойду менять работу - мои скилы никому будут не нужны

да, огонь 🔥
еле урл нашел, не все жо пользуются твитором https://twitter.com/igrekde/status/1186925135158222849

Ну, у меня с этим проще, потому что я параллельно с работой занимаюсь тем, что формирую неформальное коммьюнити айтишников у себя в городе (провожу регулярные митапы, докладываюсь на конференциях, провожу игры типа getkanban и так далее), и, в случае чего, у меня будет возможность переквалифицироваться в коучи и/или открыть школу программирования  и/или открыть хакерспейс. Короче, параллельно с работой вкладываюсь в развитие личного имиджа.

это ужасно(((

Основное - заметное усложнение поиска новой работы, т.к. "Тимлид – это ❄️, потому что в каждой компании он уникален и неповторим", как написано на местном гитхабе, а еще тимлидов зачастую растят внутри компаний "из коммуникабельных синьеров", а не берут с рынка.
В прошлый раз месяца 4 ушло, чтобы найти интересное и с новыми вызовами.
Синьеру с понятными и прокачаными хард скилами на порядок проще, можно чуть ли не одним днём уволиться и найти новое.

про это уже зашутил 🙁

можно ещё про то, что если факап - то косяк тимлида, а если всё отлично - то программисты молодцы

Про отпуск ещё не было. Напиши, что если тимлид уйдёт в отпуск, и во время отпуска ничего плохого не случится, то нужно на ретре сказать, что команда и без него отлично работает.

Было!

это мой страшный сон

а, было про увольнение в отпуске

хмхмхм

норм, заберу, спасибо

Можно кстати шутки и в обратную сторону - в разработчиков - сделать, например, будет тебе 40+ ну и кому ты будешь нужен, программирование это дело молодых и т.д. 😁

Я этот страх за 3 года так и не поборол

@etolstoy
Это, может быть, получится переформулировать в что-то типа "не учи меня жить!"

прочитал утреннее обсуждение резануло немного вот это.
Человек написал, что у него налаживают agile. Следующее сообщение сразу про скрам -- "в скраме нельзя делать что-то наполовину. либо он есть полностью, либо это не скрам". И далее поехало.
Откуда берется эта мысль что agile ==  scrum? Что не разговор так сразу противопоставление водопадов и скрамов. И крайне редко про просто построение процесса на основе agile принципов.

По делу в похожей ситуации внедрили по результатом парочки ретроспектив лайтовый definitiof of ready для сторей и я создал дополнительный Kanban борд в Jira для процесса подготовки сторей к спринту, по которому попросил вести все задачи, которые планируется вкинуть в ближайшие спринты. В этом борде последней колонкой -- приемка у QA нашей команды (либо любой из исполнителей может этим заняться, если QA перегружены). Задачи которые не прошли приемку стараемся не допускать до планирования спринта, если это не что-то экстренное.

Что-нибудь про "Будьте токсичным, везде вставляйте свои едкие ценные замечания, особенно в командных чатиках и на ревью в пулл-реквестах, тимлиды обожают токсичных"? 🤨

А вот этот вопрос и меня много раз ставил в тупик. Пока для себя пришел к выводу, что если процесс выстроен в таком ключе, что есть цепочка зависимых задач, то лучше отказываться от спринтовой работы в пользу канбан досок  и в целом канбан метода, который хорошо заточен под такой флоу.
Ну или альтернатива -- идти в T-shaped где нет проблемы заняться смежной работой, но для меня это сложнее продать команде.