Как стать автором
Обновить
41
0
Асеева-Нгуен Анастасия @Travieso

engineering practices

Как победить legacy в головах и не дать ему вернуться

Время на прочтение 10 мин
Количество просмотров 5K

Изменения — это то, что происходит всегда. Мы можем переходить на новый язык программирования. Например, внедрять Kotlin или переходить на GO, как это сейчас многие делают. У нас могут появляться новые базы данных. Мы можем переезжать в облака (или обратно). Или можем захотеть внедрить у себя новый процесс, будь то Code review, постмортемы или Scrum с Канбаном. Даже для перехода на удаленку нужны новые процессы или инструменты.

Люди реагируют на изменения по-разному — кто-то активно включается в процесс, а кто-то просто мешает. Техлиды могут помочь внедрить изменения быстрее и легче, если будут знать, как влиять на команду. Сегодня Дмитрий Масленников, возглавляющий департамент SRE в Тинькофф, покажет, с каким поведением вы можете столкнуться при изменениях (видео его выступления на TechLead Conf 2020). В результате его 10-летнего опыта вы сможете не только что-либо продать командам, но и сохранить изменения.

Читать далее
Всего голосов 13: ↑12 и ↓1 +11
Комментарии 4

Как «продать» технические задачи бизнесу

Время на прочтение 12 мин
Количество просмотров 4.6K

Поддерживать высокое техническое качество кода — прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

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

Читать далее
Всего голосов 15: ↑14 и ↓1 +13
Комментарии 2

Моделирование микросервисов с помощью Event storming

Время на прочтение 8 мин
Количество просмотров 53K

Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?

При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.

Читать далее
Всего голосов 19: ↑18 и ↓1 +17
Комментарии 2

Как писать читаемый код

Время на прочтение 11 мин
Количество просмотров 21K

Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.

В этой статье пересекаются, казалось бы, непересекаемые вещи: нейрофизиология, проклятие нулевой цены копирования, когнитивная и социальная интуиция. И, конечно же, в ней поднимается тема сложности кода. Вы узнаете о том, откуда она берется, почему ее нельзя убрать и как с ней жить.

Читать далее
Всего голосов 47: ↑47 и ↓0 +47
Комментарии 30

Как инженеру вырасти в техлида

Время на прочтение 11 мин
Количество просмотров 8.7K
Кто такие тимлид, архитектор или QA и чем они занимаются, в IT представляют себе примерно все. Но с пониманием, кто такой техлид, за что отвечает и как им стать, возникают трудности. Мы провели десятки интервью со специалистами крупных компаний и узнали, что это инженер, который инициирует процессы: связывает людей и инструменты с целями организации. Он берёт инициативу и ответственность за технологическое развитие продукта и радеет за качество технических решений. При этом качество это не только тестирование, а архитектура, дизайн, инженерные практики и эксперименты, работа с техдолгом и техническое совершенствование компании в целом.



Также мы выяснили, что для техлидов есть много конференций. Но почти все они концентрируются на  инструментах, а не на инженерных практиках и процессах. Именно поэтому мы запустили новую конференцию TechLead Conf 2020 Online — для тех, кто хотел бы стать техлидом и разобраться с тем, что такое качество. 

На TechLead Conf 2020 Online вторичен вопрос «С помощью какого технического инструмента решалась проблема?». Эта конференция для тех, кто борется за качество технических решений и берёт на себя ответственность за технологическое развитие продукта. С 8 по 10 июня мы изучим опыт внедрения и использования практик, управления технологиями и процессами в компании. Подробнее о программе и о чём будем говорить на мероприятии, расскажем дальше.
Читать дальше →
Всего голосов 27: ↑24 и ↓3 +21
Комментарии 0

Проектируем bounded context с помощью Bounded Context Canvas: рецепт воркшопа

Время на прочтение 10 мин
Количество просмотров 13K
Среди тем предстоящей конференции TechLead Conf 2020 будет детальное обсуждение Domain-Driven Design и EventStorming. Помимо подготовки 2-слотового доклада Константина Густова о DDD, доклада Сергея Баранова об EventStorming и митапа, во время которого мы будем создавать DDD-радар, мы решили перевести статью об одном из самых популярных способов проектирования bounded context.

Как разбить большую систему на мелкие более управляемые компоненты? Мне часто задают этот вопрос, поэтому я собрал свои знания в эту статью.
Читать дальше →
Всего голосов 22: ↑21 и ↓1 +20
Комментарии 3

Кто такой техлид и почему он нужен команде

Время на прочтение 10 мин
Количество просмотров 62K
Мы недавно писали, как затеяли конференцию, полностью посвященную инженерным процессам и практикам. Наша цель — собрать в одном месте профессионалов, которые развивают техническое лидерство у компании, продукта и дать им возможность поделиться опытом, обсудить свои задачи и проблемы индустрии, вместе найти новые подходы. Мы долго думали, что объединяет таких людей, как их распознать. И поняли, что это техлиды. Именно они несут ответственность за технологический вектор, внедряют те самые инженерные практики и настраивают процессы.

Но в нашей индустрии даже градация должностей junior/middle/senior колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).

Читать дальше →
Всего голосов 28: ↑28 и ↓0 +28
Комментарии 3

За всё ответишь! Consumer Driven Contracts глазами разработчика

Время на прочтение 10 мин
Количество просмотров 11K
В этой статье мы расскажем про проблемы, которые решает Consumer Driven Contracts, покажем как это применять на примере Pact с Node.js и Spring Boot. И расскажем про ограничения этого подхода.


Проблематика


При тестировании продуктов часто используют сценарные тесты, в которых проверяется интеграция различных компонент системы на специально выделенном окружении. Такие тесты на живых сервисах дают самый достоверный результат (не считая тестов на бою). Но в то же время они — одни из самых дорогих.
Читать дальше →
Всего голосов 24: ↑21 и ↓3 +18
Комментарии 0

Разработка микросервисов с помощью BDD и IOD

Время на прочтение 7 мин
Количество просмотров 6.1K
BDD — разработка через поведение. BDD для микросервисов — это сотрудничество клиента, разработчиков и тестировщиков. BDD — это разработка, которая учитывает и технические интересы и бизнес-требования. Этот подход обычно применяется для описания интерфейсов приложений, а так как микросервисы — детали реализации системы, то BDD прекрасно походит и для разработки микросервисов. Как это сделать — в переводе материала Ken Pugh.

image

Об авторе: Ken Pugh обучает компании развивать гибкость, создает высококачественные системы с помощью Acceptance Test-Driven Development, BDD, ускорения DevOps. Кен написал несколько книг по разработке ПО, был лауреатом премии Jolt Award 2006 Prefactoring, один из создателей курса SAFe Agile Software Engineering.
Читать дальше →
Всего голосов 18: ↑18 и ↓0 +18
Комментарии 0

Введение в Example Mapping

Время на прочтение 6 мин
Количество просмотров 14K
Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете  ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.

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

Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.


Читать дальше →
Всего голосов 15: ↑15 и ↓0 +15
Комментарии 1

3 Амиго — способ коммуникации, для создания качественного продукта

Время на прочтение 11 мин
Количество просмотров 66K

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


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


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



Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.


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

Читать дальше →
Всего голосов 25: ↑22 и ↓3 +19
Комментарии 1

Вам не нужны разработчики автотестов

Время на прочтение 13 мин
Количество просмотров 23K

В эпоху вселенского внедрения agile-методологий и Devops уже никто не сомневается в том, что регрессия должна быть автоматизирована. Особенно, если в компании идет речь о Continuous Delivery. Все кинулись хантить разработчиков автотестов, от чего рынок становится перегретым.


В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.

Читать дальше →
Всего голосов 33: ↑26 и ↓7 +19
Комментарии 37

Ставим Selenium Grid на колеса Apache Mesos

Время на прочтение 13 мин
Количество просмотров 13K
Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.



Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.
Читать дальше →
Всего голосов 35: ↑35 и ↓0 +35
Комментарии 18

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирована
Активность