Артем Каличкин, Тактика и стратегия DevOps в Enterprise: роль вирусов в поеда...ScrumTrek
Я расскажу реальную историю перехода махровой Enterprise команды на DevOps практики поставки и управления конфигурацией. Итак...
Представьте себе экосистему финансовых enterprise-решений. Непрерывное и гиперактивное развитие, постоянный запуск новых сервисов, потребность в быстром и гибком внесении изменений. И все это под флагом «Mission Critical & 99,99% SLA».
Перед нами стояла задача стать гибкими и при этом сохранить надежность.
Решение? Внедрить практики DevOps в Enterprise экосистему!
В докладе мы пройдемся по выводам, полученным в ходе реализации этого амбициозного проекта:
- Требуется определенный уровень зрелости процессов еще ДО, иначе действительно можно получить «х--к х--к и в продакшен»
- DevOps невозможно внедрить, этим вирусом надо заразить
- Основная работа для «менеджера внедения» — не быть менеджером внедрения, а быть евангелистом
- Только через непрерывное совершенствование — такого слона можно скушать только частями
- Доверять команде.
Для этого нужны действительно сильные специалисты, действительно болеющие за сервис, действительно старающиеся, как для себя. Одним словом, правильные люди — без этого фейл.
- Постоянно ловить момент.
Новые продукты, новые вехи в развитии старых продуктов. Постоянно искать возможности для внедрения желаемых технологий
- Евангелизм в квадрате.
Для успешности нужно распространять «вирус» за пределы команды, смежные подразделения, ИТ, безопасность.
- Неожиданные повороты судьбы.
2012 год - я внедряю CMDB, 2015 год - я воюю против CMDB
- 'Water-agile-flow' (с) Jez Humble — пожалуй, главное препятствие в Enterprise.
В докладе я рассказываю о практиках, которые мы активно используем в компании Банки.ру. Как мы добились стабильного процесса выкладки изменений на бой. Как мы отслеживаем, что наши изменения действительно приводят к успеху.
The report I talk about practices that we actively use in the Banki.ru company . As we have achieved a stable process calculations of changes in the fight. How do we keep track of our changes do lead to success .
Артем Каличкин, Тактика и стратегия DevOps в Enterprise: роль вирусов в поеда...ScrumTrek
Я расскажу реальную историю перехода махровой Enterprise команды на DevOps практики поставки и управления конфигурацией. Итак...
Представьте себе экосистему финансовых enterprise-решений. Непрерывное и гиперактивное развитие, постоянный запуск новых сервисов, потребность в быстром и гибком внесении изменений. И все это под флагом «Mission Critical & 99,99% SLA».
Перед нами стояла задача стать гибкими и при этом сохранить надежность.
Решение? Внедрить практики DevOps в Enterprise экосистему!
В докладе мы пройдемся по выводам, полученным в ходе реализации этого амбициозного проекта:
- Требуется определенный уровень зрелости процессов еще ДО, иначе действительно можно получить «х--к х--к и в продакшен»
- DevOps невозможно внедрить, этим вирусом надо заразить
- Основная работа для «менеджера внедения» — не быть менеджером внедрения, а быть евангелистом
- Только через непрерывное совершенствование — такого слона можно скушать только частями
- Доверять команде.
Для этого нужны действительно сильные специалисты, действительно болеющие за сервис, действительно старающиеся, как для себя. Одним словом, правильные люди — без этого фейл.
- Постоянно ловить момент.
Новые продукты, новые вехи в развитии старых продуктов. Постоянно искать возможности для внедрения желаемых технологий
- Евангелизм в квадрате.
Для успешности нужно распространять «вирус» за пределы команды, смежные подразделения, ИТ, безопасность.
- Неожиданные повороты судьбы.
2012 год - я внедряю CMDB, 2015 год - я воюю против CMDB
- 'Water-agile-flow' (с) Jez Humble — пожалуй, главное препятствие в Enterprise.
В докладе я рассказываю о практиках, которые мы активно используем в компании Банки.ру. Как мы добились стабильного процесса выкладки изменений на бой. Как мы отслеживаем, что наши изменения действительно приводят к успеху.
The report I talk about practices that we actively use in the Banki.ru company . As we have achieved a stable process calculations of changes in the fight. How do we keep track of our changes do lead to success .
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?
Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.
«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
От заката до рассвета | Максим Безуглый | Zlit TechZlit
Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?
Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.
«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
От заката до рассвета | Максим Безуглый | Zlit TechZlit
Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
JS-тусовка сейчас переживает взрывообразный рост. Огромное количество людей приходят к нам из других языков программирования, "с улиц" и университетов. Все мы превосходно знаем Angular, восторгаемся React и хвалим Ember.
Чего же мне не хватает для полного счастья? Почему каждый раз, будучи привлеченным как консультант, я вынужден повторять очевидные вещи? Как стать лучше как программист не изучая новых технологий, фреймворков и прочего хайпа
Детали доклада:
Я разберу типичные ошибки JS-программистов, с которыми мне пришлось столкнуться за 3 года работы собственной компании и консалтинга, и покажу, как "код" мешает нам увидеть реальную картину того, что происходит в отрасли. Постараюсь по минимуму задевать избитую тему soft skills.
Скорее этот доклад - набор наболевших историй "из жизни", каждая из которых должна заставить слушателя задуматься. И да, почти все "со вкусом JS" - часто камнем преткновения становятся особенности языка, поддержка браузеров и т.д. - всё то, что так знакомо всем фронтендерам.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2991.html
Нынче стало модно выделять UI-компоненты в отдельную библиотеку и использовать её в нескольких проектах. Мы в команде почты Mail.ru делаем так же, но столкнулись с проблемой: каждый разработчик, меняя библиотеку под свои нужды, обязательно ломает что-нибудь, что работало у других.
Я расскажу о том, как мы решили эту проблему, и о том, какие инструменты для этого можно использовать. Storybook, BackstopJS, Jest, Webdriver.io, TypeScript - в их числе.
Elena will tell about a 16-month path that LingPlay has walked from a prototype to 1,000,000 installs in the first post-release week. After falling into many traps, a young team of developers did won the love of App Store and Google Play by getting 3 million downloads all over the world. The speech may be useful for both novice and experienced mobile developers, small indie teams and independent pros who are planning to create a game that would make a stir throughout the whole world.
Similar to От идеи до 10 миллионов скачиваний: King of Thieves (Олег Якубенков, Zeptolab) (20)
2. Олег Якубенков
• 2 года назад я ушел из Яндекса, где
занимался аналитикой
• И пришел в Zeptolab, где спустя некоторое
время начал заниматься новым продуктом
32. Урок 11.
Лучше, когда несколько человек
работают над продуктом
но должен быть понятный процесс принятия решений
33. Версия 4
Что делаем
• HP вора и прокачка ловушек
• Покупка слотов камней
• Прямая атака в лигах
34. Версия 5
Что сработало
• HP вора и прокачка ловушек (yes)
• Покупка слотов камней (so-so)
• Прямая атака в лигах (no)
35. Версия 4
Результаты
v1 v2 V2.1 v3 v4 v5 WW v1
Retention 1d 26% 41
%
41% 45% 44%
Retention 7d 9% 20
%
21% 23% 22%
LTV x x 2,5x 10x 18x
36. Урок 12.
Lean методология о многом
умалчивает.
Число экспериментов, которые вы
можете провести, ограничено.
Повышайте конверсию в успешные эксперименты
40. На дворе ноябрь, намеченная дата релиза – 12
февраля.
У нас 3 месяца.
41. 3 месяца и много дел
• Технический долг
• Нагрузочное тестирование
• Доработки по продукту
• Миграция старых пользователей
• Локализация на все основные языки
• Доработка версий на все ключевые платформы
• Тестирование разных аспектов продукта
• Китайская версия через паблишеров
• PR, промо материалы, маркетинг
• Юридические аспекты
42. Продолжаем продуктовые
тренировки
• Эксперимент «С рекламой или без»
• Эксперимент «Разные версии баланса»
• Эксперимент «Проигранный уровень при HP =
0 или нет»
• Эксперимент «С ревайвом или нет»
• Эксперимент «Новый интерфейс»
• Поиск и тестирование каналов трафика
• Определение целевой аудитории
• Тестирование иконок приложения
• И многое другое…
Но путь был долгим и тернистым
2 года разработки
1 год софт лонча
LTV первой версии улучшили в 40 раз
Идея
Прототип
Люди стали активно играть
Весело
Новая версия каждую неделю
Играем обсуждаем брейнштормим меняем тестируем
Технически стабилизируется
Много вовлеченных людей с самого старта
Вовлеченное сообщество (пусть и внутри компании)
Много крутых идей, фидбека
Многие фичи, которые в итоге очень хорошо сработали были предложены или развиты ребятами, кто просто играл
Мы готовы к софт лончу
Что мы делаем? Долго обсуждаем важные вопросы, что надо доделать, расставляем приоритеты и тд
Пользователи не нашли мультиплеер
Но! Приятный сигнал - Те немногие, кто нашли, играют активно и хорошо
Делаем новый туториал, ведем людей сразу по пути тех, кто нашел мультиплеер
Выделяем кнопку мультиплеера, добавляем анимации пока не нажмешь
Добавляем респин на камни
Делаем сильные изменения, чтобы заметить на маленьких цифрах изменения
В продолжение темы экономики
За время софт лонча у нас было 2 дефолта
Придумывать идеи – это не супер сложное дело – почитатайте фидбек пользователей…
Идеи это кирпичики
Ключевая сложность и уже более похожее на работу – найти способ встроить эти идеи в продукт, не плодя сущностей и не ломая
Предвзят к своим идеям , что плохо
1000 пользователей в Канаде = 3-4k$
1 эксперимент – минимум 2-3 недели
Собрать и детально проанализировать результаты – тоже время
Делали вслепую, часть фичей достаточно рискованные, на всякий случай обновили старых пользователей
Первая версия игра была очень похожа по механике на итоговый вариант
У нас были инапы в первой версии игры
Просто игра была разобрана, игровой цикл не работал