«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
Проблемы и решения работы с контентом. Content preparing truobles and soltionsStepan Cheltsov
Чтобы контент появился на сайте, необходимо или полностью всем доверять, или очень много платить. Но есть варианты, при которых процесс будет и управляем и в рамках бюджета с нужным качеством.
«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
Проблемы и решения работы с контентом. Content preparing truobles and soltionsStepan Cheltsov
Чтобы контент появился на сайте, необходимо или полностью всем доверять, или очень много платить. Но есть варианты, при которых процесс будет и управляем и в рамках бюджета с нужным качеством.
Теория Agile, практика Scrum простым языком с кейсами Alexey Ruchkin
Как я пришел к работе по Scrum на примере ПРАГМАТИК и как он помог почти уложиться в дедлайн проекта. Теория работы по Scrum - каким должен быть бэклог, роли в скраме, какой софт лучше использовать и пример планирования 2х недельного спринта. Опыт Scrum в АДАМАС с внешним подрядчиком.
Особенности MVP в Enterprise / Владимир Васильев (Почта России)Ontico
- Зачем в Enterprise нужен MVP;
- что значит "минимально жизнеспособный" продукт для большой организации;
- как оргструктура влияет на продукт;
- какие ограничения может накладывать Enterprise на MVP;
- какие практики MVP наиболее полезны в Enterprise.
Сергей Смирнов, Виталий Александров. Оздоровление унаследованной информационн...ScrumTrek
В наши дни возраст многих информационных систем достигает нескольких десятков лет. Если за это время применяемые технологии и процессы разработки не эволюционировали, а уровень технического долга должным образом не контролировался, то дальнейшее развитие таких систем сильно затруднено, а стоимость внесения изменений чрезмерно высока. Не минует эта учесть и государственные системы, с одной из которых нашей команде и пришлось столкнуться. Нам было поручено дальнейшее развитие системы, автоматизирующей предоставление услуг населению в режиме 24х7. Разработка системы более 15 лет велась различными подрядчиками, качество работ в последние годы значительно ухудшилось, участились срывы сроков. Нам требовалось вывести процесс разработки на новый уровень и выполнить контрактные обязательства по развитию функционала! В докладе речь пойдет о том, как мы успешно прошли этот путь, применяя современные процессные и инженерные Agile практики: как провели аудит системы, какие риски учли, а какие нет, какие практики применили, какой порядок работ выработали. Материалы доклада можно рассматривать как практические советы.
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Теория Agile, практика Scrum простым языком с кейсами Alexey Ruchkin
Как я пришел к работе по Scrum на примере ПРАГМАТИК и как он помог почти уложиться в дедлайн проекта. Теория работы по Scrum - каким должен быть бэклог, роли в скраме, какой софт лучше использовать и пример планирования 2х недельного спринта. Опыт Scrum в АДАМАС с внешним подрядчиком.
Особенности MVP в Enterprise / Владимир Васильев (Почта России)Ontico
- Зачем в Enterprise нужен MVP;
- что значит "минимально жизнеспособный" продукт для большой организации;
- как оргструктура влияет на продукт;
- какие ограничения может накладывать Enterprise на MVP;
- какие практики MVP наиболее полезны в Enterprise.
Сергей Смирнов, Виталий Александров. Оздоровление унаследованной информационн...ScrumTrek
В наши дни возраст многих информационных систем достигает нескольких десятков лет. Если за это время применяемые технологии и процессы разработки не эволюционировали, а уровень технического долга должным образом не контролировался, то дальнейшее развитие таких систем сильно затруднено, а стоимость внесения изменений чрезмерно высока. Не минует эта учесть и государственные системы, с одной из которых нашей команде и пришлось столкнуться. Нам было поручено дальнейшее развитие системы, автоматизирующей предоставление услуг населению в режиме 24х7. Разработка системы более 15 лет велась различными подрядчиками, качество работ в последние годы значительно ухудшилось, участились срывы сроков. Нам требовалось вывести процесс разработки на новый уровень и выполнить контрактные обязательства по развитию функционала! В докладе речь пойдет о том, как мы успешно прошли этот путь, применяя современные процессные и инженерные Agile практики: как провели аудит системы, какие риски учли, а какие нет, какие практики применили, какой порядок работ выработали. Материалы доклада можно рассматривать как практические советы.
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Андрей Харченко, jocker3d@gmail.com, Game Developer
Независимая разработка игр. Что это такое и как правильно начать?
Создание собственной игры - увлекательный, но тем не менее достаточно сложный процесс.
Важно знать о многих аспектах, начиная от выбора технологии и заканчивая правильной организацией работы в команде.
В докладе будет рассмотрено:
- Плюсы и минусы технологий: Marmalade SDK, Unreal Engine, Unity, Cry Engine, Custom Engine
- Команда: Сколько нужно человек для разработки игры
- Объем проекта: Цифры на примере реального проекта
- Рабочий pipe line: Итерации в процессе разработки
- Фокус-тесты: Почему это очень важно
Что сделать, чтобы сто раз все не переделыватьТранслируем.бел
Катя Немкович
PRODUCT MANAGER @ CAPTIV8.IO
Мне отлично знакомо чувство паники, которое возникает, когда не понимаешь, как подступиться к документации. Что делать в первую очередь? На что нет смысла тратить время? Как поддерживать все это потом?
Я расскажу о своем чеклисте, абсолютном минимуме того, что стоит делать, чтобы избежать ошеломляющих открытий в самый разгар проекта.
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
2. План выступления
●
Определим термины
●
Почему это проблема и как это вас касается
●
Правильно поставленные задачи
●
Процессы CRISP-DM и ASUM
●
Проблемы и решения
●
CRISP курильщика — до входа в проект
●
CRISP курильщика — на проекте
●
Рекомендованная литература
3. "data scientists ... incorporate data
science into the operation
of a product or service,
using data in smart ways
to provide value."
Edo Wilder-James https://www.svds.com/how-do-you-build-a-data-product/
4. Договоримся о терминах
●
Дата-продукт — статичные данные
●
Дата-сервис — меняющиеся данные
●
Небольшой датасервис — 2-3 месяца работы
●
Внешний заказчик — соседний департамент
●
Вход в проект — работа до денег
●
Работа на проекте — работа за деньги
5. Заказчик (не о нас)
●
Ушли, зажав в передних лапах N миллионов.
●
Вернулись через полгода с непонятной
бесполезной моделью.
●
Не будем отдавать задачи на аутсорс
7. — Здравствуйте. Возьмите меня к себе
жить. Я вам буду всё охранять.
— Ещё чего! Мы сами нигде не живём.
Ты к нам через год прибегай, когда мы
хозяйством обзаведёмся.
(с) Трое из Простоквашино
8. CRISP-DM
Когда DS назывался DataMining
●
Business Understanding
●
Data Understanding
●
Data Preparation
●
Modeling
●
Evaluation
●
Deployment
ftp://ftp.software.ibm.com/software/analytics/spss/documentation/modeler/
14.2/en/CRISP_DM.pdf
9. Вам платят за то, чтобы вы
разобрались в бизнесе заказчика,
посмотрели его данные, поняли что
оттуда можно извлечь и помогли
поставить задачу.
Это может сработать.
11. Проблемы - 1
Предварительный анализ бизнеса:
– Мы хотим нанять профессионалов.
– Мы хотим, чтобы у них был опыт решения
нашей уникальной проблемы.
– Мы хотим провести тендер.
12. Проблемы - 2
Предварительный анализ данных
●
Данные нужно найти, собрать или купить.
●
Данные во внутренних системах, куда до
проекта могут и не пустить
(могут не пустить и после)
●
Данные стоят денег (идеальный рынок)
●
Непонятно, какие данные нужны
13. Проблема - 3
Задача поставлена плохо
●
Данные не те
●
Найти не то
●
Критерий не тот
Проблема возникает на стыках модели с
реальностью
14. ASUM
Когда DS и IT слились воедино:
●
Analyze
●
Design
●
Configure & Build
●
Deploy
●
Operate & Optimize
●
Project Management
ftp://ftp.software.ibm.com/software/data/sw-library/services/ASUM.pdf
15. Несмотря на слова Agile в тексте,
процесс ASUM подозрительно
напоминает процессы разработки
ПО начала 90-х
19. CRISP курильщика
●
Быстро делаем прототип.
●
Смотрим что получилось.
●
Повторяем, пока не кончатся деньги.
●
Просим еще.
●
Когда деньги кончились, продукт готов.
Прототипируем всё на каждом этапе.
20. До входа в проект
●
Ключевые слова
●
Готовые прототипы
●
Источники данных
●
Суррогатная модель
●
Изучаем суррогатную модель
●
Допрашиваем заказчика
21. Ключевые слова
●
Бриф, сайт и фейсбук заказчика.
●
Запоминаем ключевые слова.
●
Гуглим их значение.
●
Бегло просматриваем профильные журналы и
форумы.
●
Контачим со всеми, с кем удастся.
24. Суррогатная модель
●
Пробуем предсказать хоть что-то
●
Нет разметки?
Попробуйте предсказать косвенный признак.
(рекомендательная система → цена)
(здоровье → возраст)
●
Неинтерпретируемая, без валидации
●
Какой-нибудь бустинг
●
Чтобы понять, как устроен мир
26. Допрос заказчика
●
Есть учебники по допросу (см «Книги»)
●
Главное — список гипотез
●
Идеально — мимоходом
●
Несколько человек
●
Слушать и смотреть по сторонам
Идите в гембу.
●
Что не укладывается в вашу картину мира?
28. Визуализация
●
Визуализируйте входные данные
●
Pandas profiling
https://github.com/pandas-profiling/pandas-profiling
●
Гистограммы
●
Попарные графики
●
В любой непонятной ситуации визуализируйте
●
Даже если и так все понятно
29. Pipeline
●
Из конца в конец как можно быстрее
●
В середине что подвернется — константа,
таблица значений, простой if, random,
простая модель.
●
Проблемы обычно на входе и выходе
●
Пайплайн обучения
●
Пайплайн инференса
30. Метрика и бейзлайн
●
Метрика до начала работы над моделью.
●
Идеально — понятная заказчику
●
Не F1, а что-то в терминах денег, времени
●
Основа успеха проекта
●
И немедленно зафиксировал бейзлайн!
●
Бейзлайн до работы над моделью,
чтобы понимать — где вы сейчас.
32. Валидация данных
●
Пропадают и добавляются колонки в базе
●
Меняется формат данных, из текста в строку
●
Проверять предположения о диапазоне значений,
пропущеных данных, дублирующихся
идентификаторах и проч.
https://hypothesis.readthedocs.io/en/latest/numpy.html
●
…..
●
Валидация — часть пайплайна обучения
●
Разумный отвал в продакшене
33. Деплой и версионирование
●
Докер ваш друг
●
Версионирование API ваш второй друг
●
Как вы будете выкатывать новую модель?
●
Как вы будете откатывать модель назад?
●
Как вы будете поддерживать несколько
версий модели?
34. Оценка и мониторинг
●
Метрики после обучения:
– Качество на отложенной выборке
– Скорость работы
– ….
●
Метрики работающей модели (какие?)
●
Мониторинг ошибок (sentry?)
●
Показатели в динамике,
привязанные к версиям модели
35. Дообучение
●
Мир меняется
●
Распределение входных данных меняется
●
Как модель будет дообучаться?
– По запросу? Как поймем, что пора?
– Ежемесячно руками?
– Ежедневно автоматом?
– Онлайн?
●
Как контролировать качество?