Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

Клуб по интересам: как и зачем создавать сообщество

Часто, когда мы говорим о крупных компаниях, у нас возникают ассоциации вроде "кровавый enterprise", бесконечные NDA и тщательное регулирование всех процессов разработки.

В докладе я попробую побороться с таким имиджем, рассказав три истории о том, как внутри банка развивалось и продолжает развиваться совместное владение кодом, основанное на принципах inner source. У каждой из историй разные предпосылки и особенности, но все они про совместную разработку на основе открытости и сотрудничества. В процессе рассказа разберемся, откуда берется InnerSource и как его создать внутри вашей компании.

Доклад принят в программу конференции

Команда разработки не успевает реализовывать запрашиваемый соседними командами функционал, и единственный способ получить от них необходимое — это эскалировать вопрос начальству. Разработчики демотивированы переработками и постоянной рутиной, а бизнес — вклиниванием в бэклог инородных задач и частой переприоритизацией. Код и проектная информация заперта по командам, а чтобы банально запустить приложение, нужны секретные знания человека, который сейчас в отпуске...

Со временем зрелые команды по наитию решают эти проблемы инженерными практиками и подходами, даже не подозревая, что пришли к InnerSource. Хорошая новость в том, что сообщество энтузиастов из мировых компаний InnerSource Commons делится лайфхаками и правильными рецептами приготовления InnerSource. Принципы open source, уже давно доказавшие свою состоятельность в разработке сложных программ, отлично перекладываются на корпоративные реалии.

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

Доклад принят в программу конференции

Все слышали о community в IT. Но начни спрашивать, что же это такое, и окажется, что вариантов великое множество. Одни скажут, что это исключительно недостижимые команды Google и Apple. Другие — что это какие-то митапчики с пиццей. Третьи — что это чатик IT-шников города N в Telegram. Что объединяет всех этих людей? То, что большинство из них считает, что community — это какая-то внешняя сущность, и многим даже в голову не приходит попробовать создать его прямо внутри своего отдела.

Есть и те, кто задумываются о строительстве внутреннего community, но часто оставляют идею нереализованной, потому что считают, что это очень долгосрочная инвестиция, выгода от которой неочевидна, ведь мир так быстро меняется. Вложить в создание и поддержку сообщества от 50 до 150% своего рабочего времени, в то время как в должностные обязанности это часто не входит, и получить… что? Уж лучше писать код, потому что окупаемость понятна: есть код — есть зарплата.

Так может ли community существовать внутри конкретной компании или отдела? И стоит ли в него инвестировать? Вот с этим мы и попытаемся разобраться.

Я хочу поделиться опытом и рассказать, как можно организовать community таким образом, чтобы оно начало отвечать за отдельные области настройки рабочих процессов. Обсудим форматы взаимодействия с community и подготовку к встречам, а также проблемы, которые вам придется решать, если вы созреете на создание собственного внутреннего сообщества. Также на примере покажу, как окупаются инвестиции в профессиональное community, когда вдруг резко пришлось масштабироваться.

В общем, это краткий курс по инвестированию в людей, который точно даст вам пару применимых на практике инструментов.

Доклад принят в программу конференции

65536 путей развития техлида

Все хотят расти, и техлиды — не исключение. Но иногда возникает ощущение, что вы достигли потолка — и совсем непонятно куда же расти дальше. Это обманчивое ощущение я и попытаюсь развеять. :)

Мы посмотрим на то, как в принципе профессиональные навыки развиваются у техлидов, и на список навыков уже состоявшегося техлида. А также подумаем, что делать тем, у кого все эти навыки уже отлично развиты.

Доклад принят в программу конференции

Нетривиальное качество

- Мутационное тестирование. Что это и зачем.
- Как внедрить мутационное тестирование на большое количество сервисов усилиями одной команды.
- Как донести результаты мутационного тестирования до разработчиков.
- Какой профит может принести внедрение мутационного тестирования.

Доклад принят в программу конференции

Пропаганда инженерных практик

В 2016 году команда Хекслета полностью перевела разработку своих проектов в облака. Сначала это было вынужденное решение, но потом нам понравилось. Оказалось, что у такого подхода есть масса неочевидных плюсов.

В этом докладе я расскажу про историю нашего перехода, адаптацию, использование разных редакторов, докер и многое другое.

Темы:
* Проблемы разработки на Маке: память, докер, среда.
* Провайдеры (aws, google, do), коннекты, задержки.
* Ненапряжная работа в Vim, VScode.
* Правильные терминалы и интеграция с Tmux.
* Совместная работа и внешние домены.
* HTTPS, веб-хуки, интеграции с внешними системами.
* Terraform, Ansible и друзья.
* Батарейка!

Доклад принят в программу конференции

Техлид и его команда

Многие компании сейчас сталкиваются с задачей сохранить текущие позиции на рынке и завоевать новые за счёт экспериментов и инновационных продуктов.

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

Доклад принят в программу конференции

Вроде бы понятно, зачем техническому специалисту выступать.

Можно таким образом найти единомышленников, вместе с которыми можно совершенствовать подходы, в которые верите.
Можно найти будущих коллег: допустим, кто-то из зрителей не согласен с вами и пришёл об этом сказать. Вы взяли по чашке кофе, поспорили, остались каждый при своём мнении, а через месяц уже работаете в одной компании. Так бывает.
Наконец, выступления помогают строить личный бренд. Поиск по вашему имени в youtube — такая же строчка в резюме, как и профиль на github.

Однако многим классным специалистам мешает внутренний барьер. Все рабочие задачи делятся на два типа:
1) абсолютно тривиальные,
2) те, которые вы ещё не решили.

Про первые говорить как-то совестно, они же тривиальные, а про вторые и сказать нечего, вы же их ещё не решили. Вы сталкивались с этой проблемой? Тогда мы идём к вам! Точнее, это вы приходите на доклад, и я поделюсь с вами своим алгоритмом поиска в работе того, что может быть интересно другим.

Обсудим список вопросов, которые имеет смысл себе задать. Выработаем углы зрения, под которыми стоит на свою работу посмотреть. Надеюсь, в конце у каждого будет хотя бы одна идея доклада.

Доклад принят в программу конференции

Как правильно масштабироваться

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

Классические диаграммы, UML и другие, придуманные в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием. Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах. И проиллюстрирую ее использование конкретными примерами. Визуализация сильно помогает в проектировании и коммуникации, а также в объяснении работы приложения.

Доклад принят в программу конференции

Реструктуризация тех.долга

Рано или поздно любой разработчик сталкивается с ним... Он разрушает судьбы и компании, но вместе с тем и создаёт новые рабочие места, из-за него вы продолбали выпустить в срок последний релиз... И имя ему — legacy-код!

На мастер-классе мы рассмотрим:
- Каковы причины появления legacy-кода?
- Почему это проблема не только разработчиков, но и в целом всего бизнеса.
- Какие техники существуют для того, чтобы бороться с причинами и последствиями.
- И конечно, практика на реальном коде, а как же без него!

Доклад принят в программу конференции

Я работаю в заказной разработке и моя "спецификация" — помогать легаси-проектам, которые оказались в "сложном положении": предыдущая команда "не справляется" и нужно "починить" ситуацию. Часто это означает частичную или полную замену команды разработки, а иногда и менеджмента проекта. Здесь есть много специфики: может не быть истории изменений, документированного деплоя, процессы "хромают" или и вовсе не "настроены"... В конец концов, почему этот проект приходится "спасать"?

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

Доклад принят в программу конференции

Мастер-класс

Как мы обычно планируем и делаем работу в команде? Вася берет фичу A, Петя — фичу B, а Женя — С. Потом мы расходимся на несколько дней и каждый вдумчиво делает свою работу. И все бы хорошо, но с этим подходом есть несколько проблем:
* Некоторые (обычно крупные фичи) доползают до релиза медленно, потому что ими занимаются 1-2 человека. А именно такие фичи обычно самые важные и ценные!
* Время доползания до релиза увеличивается, если Вася заболеет. Перехватить то, над чем Вася работал уже несколько дней, не так-то просто, да и свою фичу надо доделывать!
* Синергии от коллективной мудрости команды не происходит или она случается поздно — на code review, когда принципиально переделывать решение, может быть, уже не хочется.

Помогает подход “навалиться и сделать”: внучка за бабку, бабка за дедку — но если в случае с репкой все понятно, то как быть нам?

На воркшопе мы разберем различные форматы того, как можно “навалиться и сделать” одной или даже несколькими командами, а самое главное — как правильное проектирование в начале может помочь организовать эту работу.

Доклад принят в программу конференции