Archive for October, 2016

Evo.company serves few big marketplaces in Ukraine and USSR, the biggest one is prom.ua. We are running several hundred of bare metal servers in six data centers in four countries. Currently, we are in the process of migrating our applications from the traditional setup of ubuntu packages and pythonic virtualenv to containers and our own orchestration system.

This work includes setting up continuous integration and delivery pipeline, containers, monitoring, logging. And as usual, the biggest challenge is to train our colleagues to use new stuff, to prove that it’s not a waste of time and allow more people to know how to keep systems running. In this talk, I’ll discuss both the technical and organizational challenges we are facing and how we cope with them.

The practical story telling how Devops changed the culture of quality in the Bank. Recently Devops became mainstream topic. But only few people have a deep understanding how to apply it to the process of software quality assurance. Some believe that the Devops kills manual testing.

I will talk about changes it makes to the role of QA engineers themself. The discussion main point is NOT about tools or technologies. It’s NOT about the “silver bullet” for your problems with the quality of products.

Instead, I will show you an integrated approach which we used for quality assurance. It allowed us to significantly reduce the cost of finding and fixing defects. This approach has also accelerated the development and delivery value to our customers and made the whole process more transparent and predictable.

Rather than traditional departments, TransferWise is organised into several highly autonomous teams, each focused on solving a specific business or customer problem. It’s the very essence of a lean approach – effort invested is justified by quantifiable impact.

Why do we work this way? How did it change over time? What does this mean for engineering? How does this affect our practices and our culture?

Answer can be found in this talk.

It is not to complicated to keep new project with good code quality for half year. Maybe for one year. But what if team works on some project for years? Or even “”better””: you need to support and grow large project after another team. Presentation describes Continuous Inspection, main measures of code quality that will make your life better, and how to cook it with SonarQube.

When an application has been released to production or a new feature is done we know that our work is not over. With your application being used by real users, now is an ideal opportunity to collect valuable data.

In this presentation Igor will show how easy it is to instrument your app and get ambient monitoring out of the box, with almost zero effort. Also Igor will demonstrate how you can quickly build monitoring charts, dashboards, alerts and configure diagnostics logs to get a 360° view of your application. This presentation unlocks the best practices and the essentials based on real world stories from his practical experience to find performance bottlenecks, random exceptions, usage patterns of end users, availability and so on.

During a session Igor will give you a sense of metrics importance through the possibilities of New Relic and Application Insights tools and show few interesting stories.

Metrics @UBER is a first class citizen. Mantas in his talk will cover metrics collection, presentation and alerting based on metrics. It is all about how they deals with the scale in incredibly fast growing company. He will include details on the tools Uber currently uses, as well as their painful migration path from graphite based solution. The speaker will show their build-in-house query language based on tags they are using to query metrics. Mantas will share his experience building, migrating and supporting metrics system at the fastest growing startup in the history.

Описание тренинга

Если вы устали от FDD (fuckup-driven development), практикуемого в вашей компании – предлагаю рассмотреть историю трансформаций продуктовых команд под моим управлением, которые смогли выйти из замкнутого круга, повысили скорость и качество разработки, начали получать удовольствие от работы и построили изумительные процессы разработки.

Опыт перехода от “FDD” (не путаем c feature-driven наше все development) к нормальной разработке подсказывает, что большинство проблем связано с зашоренностью взгляда, неправильной расстановкой приоритетов и неумением пользоваться вытягивающими принципами, которые и обеспечивают те самые 20/80. А попытки бессистемно внедрить различные позитивные (или хорошо рекламируемые) практики часто приводят только к незначительному улучшению, а достигнутый результат быстро деградирует. Иными словами – типичные проблемы трансформации.

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

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

Программа

• Знакомство, синхронизация целей и ожиданий
• История и проблематика трансформируемых команд, веселые и грустные примеры факапов
• Теоретическая часть: дизайн процессов разработки и управления рисками жизненного цикла фичи
• Теоретическая часть: практики решения задач по дизайну процессов, метрики
• Пример жизненного цикла фичи: от требований и их тестирования до принятия обязательства (стоимость-качество) на разработку
• Пример жизненного цикла фичи: от начала разработки до релиза
• Пример жизненного цикла фичи: от релиза до смерти фичи, защита процесса от эррозии
• Сбор проблемных кейсов участников, отбор 3х наиболее актуальных для участников проблем путем голосования, разбиение на рабочие группы
• Выработка решений проблем в группах и их защита
• Подведение итогов, вопросы и ответы, литература

Что вы получите

• Познакомитесь с практиками дизайна процессов разработки и решения управленческих задач.
• Детально рассмотрите процесс разработки, успешно применённый к трансформации 2х совершенно разных команд, ставших успешными.
• Получите обоснование принятых решений и перечень учтённых рисков для каждого этапа разработки и сможете спроецировать на свои собственные процессы и проекты.
• Попробуете применить знания о полученных практиках дизайна процессов к решению ваших текущих проблем.
• Познакомитесь с практиками принятия решений, обсуждения, приоритизации и модерации.
• Смешные и грустные жизненные истории из более чем 18 летнего опыта тренера по разработке софта за деньги 🙂