Архив недели @TheRarestGuy
Понедельник
Привет! Меня зовут Миша ( @TheRarestGuy ), я руковожу командой из 4 фронтендеров, 4 бекендеров в @bizone_en ( нет это не пиццерия в долгопрудном а дочка Сбербанка, продающая иб )
В ближайшие 7 дней вас ждут рассуждения на разные темы, в основном касающиеся того как взаимодействовать разным командам. Но и про технику мы не забудем - обсудим инфраструктуру как код, кубер и CI-CD
План на неделю
1.методологии и скрам
2.Место менеджера (ответ созвучен с словом раша)
3.А что вообще делает ИТ отдел в компании
4.Культура разработки и лидства
5.День разговоров про технику! Инфраструктура, питон, девопс
6.Безопасность в организации
7.Свободный день
Твиттер я буду вести по гибкой методологии, поэтому темы могут меняться и объединяться!
Сегодня мы поговорим про методологии. Много споров о том, что лучше использовать. Кажется, что за спорами о самой лутшей участники спора забывают что все методологии существуют не ради самих себя, а для повышения эффективности работы разных людей и снижения общего уровня стресса
Мне никто не поверит, но слово «лутшей» это намеренная ошибка!
Кстати методологий чего? Разработки? Производства? Жизни? Я буду писать про разработку, потому что на производстве я не работал, а жизнь у меня беспорядочна, ввести планирования и ретро я планирую в следующем жизненном спринте
Гибких методологий тред.
Фраза "У нас разработка по аджайлу" часто означает "У нас полный пиздец, никто не понимает что происходит, а то что есть не описано»
Почему так вышло?
В опросе лидируют опции "Аджайл не всегда подходит" и "Аджайл не умеют готовить". Не будем обсуждать первый вариант - есть много рассуждений насчет того, когда можно использовать разные подходы. Аджайл хорош в условиях высокой неопределенности блаблабла вы знаете это и без меня
"Аджайл не умеют готовить" - тут намного интереснее!
Часто ли Вы замечали, что вокруг вас много бесполезных "ритуальных" встреч/процессов, которые не приносят никакой пользы?
@itunderhood Разработчики зачастую прогибаются под бизнес и из-за этого деградирует архитектура и растет техдолг
Имо это слишком инженерная тз. На мой взгляд часто у разработчиков не хватает умения «не душить», договориться и/или найти компромисс. Часто разработчики сконцентрированы на архитектуре, а не взаимодействии между собой. twitter.com/MrFlashAccount…
Бесполезные ритуалы. Почему-то очень многие люди превращают аджайл в карго-культ - при наличии всех видимых признаков аджайла отсутствует его дух. Проблемы могут решаться месяцами, планирования и синки могут длиться часами и это сильно демотивирует.
Планирования, например, могут не оставлять после себя эстимейтов, которые можно было бы использовать ради статистики. Наверно это связано с непониманием менеджерами природы методологии и процессов разработки и взаимодействия людей.
Интересно было открыть что планирования могут занимать 30 минут, а планинг покер служит не для эстимейтов, а больше для вовлечения всей команды в обсуждение задач. Не знаю как так вышло и получилось бы повторить это не с моей текущей командой
Сколько должно занимать планирование спринта в неделю с планинг покером на команду в 5 человек?
Кстати а есть ли у вас в команде планинг покер?
Комментарии противников покера были бы очень кстати!
@itunderhood У нас в команде каждый занимается своими фичами и пересекаемся очень редко. Поэтому покер просто не нужен, а планнинг у нас это просто "каждый себе задач для своих фич из бэклога набрал на спринт и готово".
Интересная тз, которая имеет право на жизнь
В нашей команде я активно борюсь с таким подходом, стимулируя коллег обсуждать задачи друг друга, чтобы находить лучшее решение. И в этом я нашёл главный плюс покера - во время оценки можно обсудить задачу и способы ее решения twitter.com/ryzzed/status/…
Первый день подошёл к концу, пора провести ретро:
Ну как вообще вцелом?
@itunderhood Это прямо боль, прийдя впервые в аджайл из бюрократической организации услышал слова: нам не нужны описания процессов и документация, у нас аджайл. У каждого на рабочем месте собственная методология работы и свои процессы.
Это жиза, но я до сих пор не понимаю как так вышло. Нигде я не видел фраз о том, что не надо описывать продукты или процессы. Кажется больным что тезис о том, что документация не должна мешать продукту и развитию превратился в то, что документации вообще нет twitter.com/avoborin/statu…
Вторник
Доброе утро!
Сегодня у нас день про место менеджера. Круто ли быть менеджером, что он должен делать и какого менеджера надо уважать, а какого нет?
Сразу скажем, что место менеджера довольно незавидное - об этом много пишут @vkozulya @igrekde ( о плюсах они тоже пишут ). Лучше я не расскажу, но попробую как-то собрать в одном месте то, к чему я пришёл
@terbiyarchitect @avoborin @itunderhood бордейль
В таком аджайле я бы поработал! twitter.com/vkozulya/statu…
Менеджер бесполезен:
В хорошей команде не нужен
А в плохой бесполезен
@itunderhood А менеджер - это кто?
Тут возник странный тред, которого я не ожидал. Я думал, что тимлид это менеджер команды, и представить не мог что это может вызвать недоумение. twitter.com/kalashnikovism…
Какие задачи стоят перед менеджером?
Имо, главная задача любого управленца - построение культуры команды. А что такое "культура команды"?
@itunderhood https://t.co/Y6yGzgVaUy
Неожиданный ответ! twitter.com/hex__0x29A/sta…
Я бы сказал, что культура - это набор ритуалов, привычек и способов взаимодействия участников между собой. Синки, планирования, покер - все это часть культуры, которая может отсутствовать, мешать или помогать. Задача менеджера- изменить культуру разработки, в лучшую сторону
Тимлид это
@itunderhood Культура это то, что крайне сложно изменить ("в огурце больше рассола, чем в рассоле огурца"). так что управленцу лучше заняться чем-то более реалистичным.
Чем например? twitter.com/wrong_habits/s…
Культуру тяжело изменить, уровень сложности сильно зависит от возраста и размера команды. Но даже в запущенных случаях это реально, если маленькими шагами менять процессы вокруг себя - помогать встречам проходить быстрее, убирать не нужные и добавлять полезные
Часто от тимлида ждут естимейтов по задачам, но часто ли от него спрашивают обоснование данных им эстимейтов?
«Ну там короче надо функцию написать» - это оценка наугад
Мы оценивали такие задачи примерно в n часов, ошибаемся мы в среднем на k часов - это уже не наугад
@itunderhood мы оцениваем сложность, а не время
А из сложности потом как-то оцениваете что успеете, а что нет? twitter.com/mattspring0/st…
Всегда было интересна ситуация в других командах
Кажется, что одной из задач тимлида является прозрачная и точная оценка роадмапов и планов компании. Но как мы видим из опроса это не всегда так. Почему так вышло?
Где-то читал, что главное в задаче тимлида - это делать довольными тех кто руководит лидом и тех, кто ему подчиняется.
Поэтому прозрачные эстимейты не всегда нужны - если начальство доверяет с оценкой, то делать их можно только для своего внутреннего спокойствия
День подходит к концу, давайте суммируем что мы сегодня узнали:
Тимлид это менеджер
Эстимейты не нужны
Что такое культура разработки
Чтобы построить культуру хорошо бы найти скрам мастера
Среда
Привет
Сегодня по плану рассуждения/обсуждения про ит отдел. Что он вообще должен делать, этот ит отдел?
В компаниях где я работал, ит занималось созданием сетевых связностей и нареканием общих учёток. Часто они делают это не так эффективно как хотелось бы
Довольны ли вы работой своего ит департамента?
@itunderhood Нет, потому что все они гондоны
А вот результаты опроса говорят об обратном ! twitter.com/emil_yangirov/…
ит обычно заворачивает все процессы на себя. Создание вм, ух, связности - везде нужно разрешение, ничего нельзя сделать без ит. Хорошо ли это? Иногда может быть, но чаще это играет против развития организации. Мне кажется, что в 2021 есть другие способы обеспечить порядок в инфре
@emil_yangirov @itunderhood Админские права не дали? ;)
с правами никогда не возникает проблем кстати twitter.com/lucid_flyer/st…
Четверг
@itunderhood Может, всё же, пусть каждый занимается своим делом? Не может быть человек непревзойдённым специалистом по всему.
А это тема сегодняшнего дня!
На каком уровне управленец должен разбираться в том, что делают его подчиненные?
Должен ли лид команды шарить лучше всех? А если команда кросс-функциональная?
( в этом споре побеждают те, кто раньше говорил что лид не сильно то и нужен ) twitter.com/caustikk/statu…
В ИТ сильно развито "лид команды должен быть технически круче всех своих подчиненных". Такая идеология подразумевает высокую ранговость, ставя тимлида выше подчиненных, и заставляя всех участников нервничать.
тимлид будет нервничать потому что ему тяжело будет успевать оставаться технически сильнее ( ему-то нужно на встречах сидеть и имейлы писать ), а команда будет нервничать, когда почувствует что лид не шарит.
@itunderhood вы, извините, какую-то чудовищную хуйню несете
Давайте обсудим! twitter.com/drunkandhopele…
На помощь тут приходит уход от роли лида, ее разделение на продакт овнера и скрам мастера - то что мы вскользь упомянули пару дней назад.
Имо, лиду сильнее нужен большой кругозор и умение сделать самому задачи, которые он ставит ( пусть и сильно хуже чем ее сделали бы специалисты ). Это нужно для того, чтобы не давать невыполнимые или абсурдные задачи.
@itunderhood а чо там обсуждать? комплекс бога у нонешних айтишников вполне объясним ввиду космических (относительно остальных отраслей) зарплат и иллюзии будто бы они дохуя что-то решают. а по сути компетенции тимлида должны позволять ему понимать где его хотят наебать, и при этом быть https://t.co/MpoMLLpSnh
Лучше я бы не сказал :)
К этой мысли я и хотел свести предыдущий тред. twitter.com/drunkandhopele…
Пятница
Привет
Сегодня у нас по плану технические вещи
Я расскажу о том, что сильно меня удивило в последнее время, со ссылками на интересные статьи - и да, все эти штуки будут очевидными
запускать и создавать докер контейнеры/образы можно и без докера и вообще, все эти контейнеры/образы - это OCI, а не докер .
C этим знанием намного легче уводить оркестраторы с докера
fly.io/blog/docker-wi…
даже в очень авторитетных либах могут быть критичные баги, которые не правятся годами
github.com/psf/requests/i…
gitlab.com/gitlab-org/git…
В энтерпрайзных продуктах все еще хуже конечно
k8s и гитлаб дают огромный простор для увеличения мощности разработки.
Неделя на то чтобы разобраться с мианифестами и хелмами, еще неделя на то, чтобы разобраться с гитлабом и интеграцией - и у вас готовы динамические стенды на каждую ветку в проекте - docs.gitlab.com/ee/ci/review_a…
А потом вы оборачиваетесь и понимаете что круче уже не сделать
Зачем вообще внедрять оркестраторы контейнеров, где и как они могут помочь ( спойлер очень сильно могут помочь навести порядок в инфре) а ещё каких ошибок можно избежать
m.habr.com/ru/company/mai…
medium.com/pinterest-engi…
Вторая статья очень интересная конечно
Воскресенье
Часто вижу такой антипаттерн - для сбора логов использовать не journalbeat и пересылку в елку, а накостыленный прямо в приложении эндпоинт /logz который авторы предлагают постоянно опрашивать чтобы забрать логи. Как вообще можно прийти к такому решению?
Обсудим сайберсек(с)
Как у вас с безопасностью дела? Как думаете, безопасность знает что происходит у вас в продукте? А саст внедряют? А в инфраструктуру лезут? А жизнь усложняют?
Штош, неделя подходит к концу, с вами был Миша Аксенов ( @TheRarestGuy ), подписывайтесь, ставьте лайки и до новых встреч!
