IntelliJ IDEA - фактически основной инструмент наших разработчиков. Года полтора назад мы публиковали собрание полезных фишек IDEA. С тех пор прошло много времени, а мы насобирали новую подборку - теперь уже для тех, кто только начинает работать в IDEA с Git. Кому интересно - добро пожаловать под кат.
Снова рассказываем по мотивам внутреннего митапа.
— Иван Иваныч Иванов с утра ходит без штанов!
— А Иванов Иван Иваныч одевает штаны на ночь!
«Афоня» (1975)
Множество курсов, призванных подготовить DS специалистов «за полгода», создают впечатление, что уж сертифицированным датамайнером стать достаточно просто. А что? Немного основ DS языка, немного по структуре данных, немного по различным преобразованиям данных, немного SQL, немного математики (в ML не погружаемся, только знакомимся), немного визуализации, немного HTML+JS+CSS. Специалист готов?
На практике оказывается, что маловато будет.
Можно ли стать программистом без профильного образования? Нет, это не реклама очередных онлайн-курсов. Кандидат физико-математических наук Андрей Грицевич много лет назад, когда деревья были больше, трава зеленее и еще даже не вышел первый Angular, ответил для себя на этот вопрос однозначно: а почему бы и нет! И самоучкой пошел в UI. Сегодня он руководит отделом разработки Центра продуктов Dozor в нашей компании. Андрей уверен, что только счастливые люди выполняют свою работу хорошо, а значит, надо помочь им стать такими. Как этого добиться? Не бояться внедрять современные инструменты. Какие-то проблемы ушли в прошлое благодаря внедрению SCRUM, где-то сработали новые HR-практики, а для решения других задач вообще понадобилось убедить всех, что технологии самоуправления – это совсем не страшно. И все это в довольно консервативной команде, которая создает серьезные корпоративные ИБ-продукты.
Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной). Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах.
Вообще, мир не одно-полюсный и паттерн - не значит хорошо в абсолюте. Более того мир не двухполюсный, и чаще всего шаблонные решения работают путем минимальной пользы в формате "и так сойдет". Найм команды - одна из животрепещущих тем среди тех кто нанимать не умеет, среди тех кто думает что умеет, и среди тех кто разочаровался и думает, что управлять можно любыми, был бы процесс и деньги, а там пойдет.
Тенденции централизации и децентрализации управления в производстве ПО противоречивы и неоднозначны. Часть компаний впервые переходит к формализованному управлению проектами разработки с помощью некоторой организационной структуры (например, в Проектного офиса) после значительного укрупнения и усложнения бизнеса, часть же успешных мировых корпораций, наоборот, стремится к максимальной децентрализации, предоставляя отдельным успешным командам высочайший уровень автономности в части процессов производства и управления. Аналогичные противоречия мы видим в эволюции ролевой модели в каждой команде разработки: от упразднения роли проектного менеджера (Scrum, MSF) с заменой на скрам-мастера до тотальной и единообразной автоматизации и формализации каждого направления в разработке ПО в каждом проекте (управление требованиями, разработка, тестирование, документирование и т.д.). Более того, в составе «гигантов IT-рынка» такие противоположенные события происходят одновременно в разных продуктовых \ географических направлениях.
Вне зависимости от того, какой подход к управлению проектами разработки с соответствующей ему ролевой моделью выбран в организации почти всегда одна из важнейших областей управления остается недостаточно осознанной – это комплексное управление рисками.
В июне 2019 года открылся наш ML-отдел, и я решил, что неплохо будет попробовать поработать по Скраму. Неплохая идея, ведь правда?
Команда абсолютно новая, тимлидского опыта у меня было не так много, а начать с чего-то нужно....
Честно и прилежно мы попытались внедрить все принципы, практики и ритуалы из гайда и книжек. Это был интересный опыт, но буквально через год мы от Скрама мы отказались, о причинах я когда-то рассказывал на Датафесте, да и вообще я теперь считаю его узким инструментом, применимым в весьма ограниченном количестве ситуаций.
Решение это далось непросто, все привыкли работать по Скраму, и от команды посыпались вопросы - что делать с эстимейтами, как приходить к общему контексту без скрам-покера, как будем измерять выгоду или потери от перехода на канбан? Изменения - это всегда сложно, недаром теме change management посвятили целый сезон конфы Podlodka Teamlead Crew. Эта статья про то, как мы генерируем предложения и внедряем изменения у нас в отделе.
В рамках этой статьи мы бы хотели рассказать про разные способы организации команд разработки, которые онлайн-кинотеатр Национальной Медиа Группы more.tv прошел за три года: цели изменений, их плюсы и минусы и допущенные ошибки. Уверены, что для многих такой формат может быть более полезен, чем изучение теории по учебникам.
Я Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы пересмотрели свой подход к тимлидству, с какими трудностями столкнулись в процессе и какие результаты это дало.
Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).
Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.
В недавней статье я писал о том, что не всем нужно развиваться. Теперь встаёт вопрос: а как же развиваться тем, кто хочет развиваться?
Даже если ты стремишься к развитию, это не означает, что ты должен учиться 24/7, читать что-то новое каждый вечер после работы, запускать по пет-проекту в месяц или контрибьютить в десяток опенсорс-проектов.
Сегодня я расскажу, как можно развиваться так, чтобы иметь время и силы на жизнь за пределами профессии, а также о том, как это делать за деньги работодателя.
Меня зовут Сергей. Я – использованный техлид. Долго думал, что я такой один – невезучий, потерявший всякий интерес к любимому делу, работающий от звонка до звонка. Оказалось, нет.
Нас таких много. Начало, первые счастливые годы, безумный интерес к своему делу – у всех техлидов похожи. Середина – пик, душевный подъём, работа без устали сутки напролёт – один в один. Послушаешь любого техлида про его золотые годы, и скажешь – «во-во, у меня так же было!». Красная нить тех счастливых времён – невероятная востребованность, от которой буквально кружится голова.
Чем больше сложных задач решаешь, тем больше их становится. Чем качественнее, оптимальнее, эффектнее создаёшь, тем больше новых вызовов получаешь. Чем лучше помогаешь другим программистам – молодым, но уже увлечённым – тем сильнее хочется жить, работать, развиваться.
Ну а потом… Приходит умный эффективный дядя, который говорит: экой тут у нас талантище! Да зазря погибает в своём пыльном углу! Не годится. Не эффективно.
Надо его использовать.
Парное программирование является важной практикой для создания высококачественного, удобного в сопровождении программного обеспечения. Однако мы также не верим, что подходить к этому вопросу нужно догматично и обязательно работая в паре. Это зависит от того, насколько именно парное программирование может быть эффективным для вас, в какой степени и для каких задач.
Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании SimbirSoft. Сегодня хочу затронуть такую тему, как нефункциональные требования к ИТ-продукту, которым не всегда уделяется должное внимание, а зря. Их несоблюдение может привести к потере прибыли, клиентов, репутации, остановке производственных процессов и большим штрафам, хотя с первого взгляда их влияние на осуществление пользовательского функционала неочевидно.
В статье расскажу, как и почему это может произойти, а главное – что нужно учесть, чтобы избежать негативных последствий. Материал будет полезен аналитикам, командам разработки, а также владельцам продуктов, поскольку они больше всех разбираются в системе и заинтересованы в успехе проекта. Приятным бонусом станут чек-листы, которые помогут сформулировать наиболее важные нефункциональные требования к:
- мощности и производительности
- безопасности, соответствию стандартам и законодательству
- переносимости и совместимости.
Сейчас я расскажу, сколько будет стоить разработать и произвести пластиковый корпус для устройства, от 1 до 200 000 штук. Все максимально по делу — в сад лирику, только слайды цифры.
У нас в Газпромбанке сложилась довольно интересная ситуация. Банк относительно недавно начал активно работать с розницей, которая как локомотив начала тянуть все внутрибанковское IT и менять характер работы всех подразделений.
Одна из главных наших проблем (впрочем, как и у многих) — долгие релизы, низкое качество кода, недоступность и нестабильность систем на тестовых полигонах. Но главное — интеграционные релизы. Когда несколько команд одновременно пытаются зарелизить свои доработки, нужно много времени и средств, чтобы синхронизировать всех. При этом каждый привносит новые баги, все начинают бегать кругами, спотыкаться, фиксить, перенакатывать… В итоге качество продукта низкое, а пользователь смотрит на это все с недоумением.
Как с этим всем бороться? Вот короткий рецепт от нас: избавиться от интеграционных релизов. Вообще. Собрать автономные, кросс-функциональные команды, каждая из которых будет выполнять свою задачу, не толкаясь локтями с другими. Для этого перепилить пайплайн, повысить инженерную культуру, ввести стандарты и так далее. Подробнее — под катом.
Недостаточно просто написать инструкции — важно, как, в каком порядке и где вы их разместите.
Привет! Это Теодора — технический писатель Платформы, жизненно важного департамента Ozon. Документация для нас имеет большое значение, потому что вся компания пользуется нашими разработками: инфраструктурой as a service; фреймворками и библиотеками; инструментами для работы с базами данных и аналитикой и прочим. Сотни инженеров ежедневно обращаются к нашим сервисам и нуждаются в их описании.
Опираясь на свой опыт, я пошагово расскажу, как привести в порядок документацию технической команды, чтобы избавить коллег от однотипных вопросов и наладить межкомандную коммуникацию.
Мир IT довольно токсичен. Нас окружает успешный успех — он захлёстывает и сбивает нас с ног каждый раз, когда мы смотрим на публичных людей в нашей отрасли. Один — ворочает «маленьким кластером на тысячу машин», другой — уже три пет-проекта запустил за утро субботы, этот — за день подготовился к собеседованиям и лениво перебирает оферы из топовых компаний.
Из каждого утюга раздаются возгласы, что разработчик должен развиваться день и ночь, ведь у нас такая профессия! Каждый должен обладать солидным профилем на гитхабе, для чего, придя домой после дня работы, обязан контрибутить в опенсорс-проекты. Впрочем, отдохнуть тоже можно — например, запустив в перерыве свой пет-проект и поучаствовав в хакатоне. Ночью можно совсем расслабиться и понабивать себе профиль в литкоде, а во время походов в туалет — прочитать пару статей.
Но действительно ли всё это надо? Разработчик в самом деле обязан проводить всё своё свободное время за написанием кода? А обязан ли разработчик постоянно развиваться?
Как же глупы мнения некоторых людей из Ост-Индии, полагающих, что обезьяны и бабуины, которых там огромное количество, наделены рассудком и умеют разговаривать, но не делают этого из страха, что их возьмут на службу и заставят работать (Антуан Легран, около 1675 года).
Эту остроумную цитату я увидел в замечательной книге недавно ушедшего от нас Дэвида Гребера "Бредовая работа: Трактат о распространении бессмысленного труда", которая произвела на меня очень сильное впечатление. О ней я и хочу рассказать.
