— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
1. Краткое введение в Agile и Scrum
2. Как и какие риски снижает применение Scrum?
3. Как планировать риски на итерацию и как это объяснить заказчику?
a. Стоит ли говорить заказчику о том, что вы планируете риски, и, если стоит, то как?
b. Что делать с «мега срочными» задачами от заказчика в середине итерации и как аргументированно сказать «нет»?
4. Что делать, что объём незапланированных задач больше объема запланированных?
5. Способы снижения рисков:
a. Снижение вероятности рисков
b. Снижение влияния на производительность команды
6. Управление рисками в самоорганизуемой команде
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...QAFest
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
1. Краткое введение в Agile и Scrum
2. Как и какие риски снижает применение Scrum?
3. Как планировать риски на итерацию и как это объяснить заказчику?
a. Стоит ли говорить заказчику о том, что вы планируете риски, и, если стоит, то как?
b. Что делать с «мега срочными» задачами от заказчика в середине итерации и как аргументированно сказать «нет»?
4. Что делать, что объём незапланированных задач больше объема запланированных?
5. Способы снижения рисков:
a. Снижение вероятности рисков
b. Снижение влияния на производительность команды
6. Управление рисками в самоорганизуемой команде
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...QAFest
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
В своей презентации Сергей Бондарь, Team Lead of BI Compute | OWOX, поделился тем как он вместе с командой использует Google Cloud Platform для построения прогнозов.
Как боты помогают Monobank обслуживать более 800 тысяч клиентовHOWWEDOIT
В своей презентации Илья поделился инсайдами как чат-боты помогают Monobank обслуживать более 800к клиентови удерживать позиции самого быстрорастущего необанка в мире!
Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією....HOWWEDOIT
— Ознаки, що проект потребує рефакторингу (крім кількості FAQ, що каже команда, коли дивиться на код). Вплив рефакторингу на бізнес — все стає простіше. Чому б не переписати «з нуля». Рефакторинг під час розробки вкрай дрібними кроками.
— Чотири ознаки, що пора зупинитися.
— Рефакторинг по-бойскаутські: «Залишай місце, з якого пішов, кращим, ніж воно було до тебе. При виконанні будь-якої задачі зменшуй технічний борг».
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук HOWWEDOIT
Многие аналитики и продуктовые менеджеры возлагают большие надежды на крутые аналитические системы. Но наблюдать за ростом и понимать и управлять им это две большие разницы. Сегодня мы поговорим о том, что может рассказать вам о вашем бизнесе ваша же база транзакций. Мы обсудим такие вещи как:
— почему рост это боль,
— почему привлечь больше клиентов не означает расти быстрее,
— обсудим можно ли расти вообще без привлечения,
— стоит ли заниматься существующими клиентами.
Еще будем говорить о бесполезности понятия конверсии, ценообразовании и его влиянии на рост и LTV, убедимся в том, что портрет клиента это миф и сформируем объективный график роста вашего бизнеса.
метрики ценообразования как интернет магазины используют цены конкурентов.але...HOWWEDOIT
Многие интернет-магазины «думают» что они знают цены конкурентов, и даже применяют их в ценообразовании, но так ли это?
Мы посмотрим реальные кейсы таких корреляций данных:
— Как измерять вес бренда? Доход от товара проданных по ценам выше рынка.
— Как измерять влияние конкуренции на спрос ?
— Расчет эластичности спроса в группе товаров, бренде, канале, как зависит конверсия от отклонения от цен конкурентов.
Использование нового инструмента Google Data Studio 360 для построения графиков и создания дашбордов из разных систем сбора, хранения и обработки данных.
2. 1. Необходимость измерения (ЗАЧЕМ);
2. Какие показатели команды важны, что измерять (KPI);
3. Примеры кейсов;
4. Какие инструменты понадобятся (КАК);
5. К чему нужно быть готовыми.
Сегодня в программе
4. Задаем себе вопросы
1. Мы работаем в оптимальном режиме или можно лучше?
2. Количество багов допустимое или должно быть меньше?
3. Все ли дедлайны мы выполняем вовремя?
4. Есть ли у нас узкое горлышко в процессе доставки задач в production?
5. Справляемся ли мы с планом выполнения работ на месяц?
6. Успеваем ли мы закрывать все тикеты, которые поступают?
5. Цель
1. Контролировать процесс разработки;
2. Принимать правильные решения на основе данных;
3. Сделать прозрачным для команды состояние работы
процессов.
22. Гипотеза
баги – не сложные функциональные задачи. Тестировать баг
достаточно 1 раз на приближенном окружении к production;
Анализ
количество багов, вернувшихся разработчику после локального
тестирования, 5%. После проверки на тестовом сервере – 30%;
Решение
сократить цикл тестирования багов, исключив локальное тестирование;
Профит
освободили ресурс тестирования;
улучшили скорость доставки исправления багов (жизненный цикл) в 2
раза.
Кейс 1 — двойное тестирование багов
23. Гипотеза
лучше доставлять задачи меньшими сборками, но чаще;
Анализ
сравнение количества задач в недельной и ежедневной сборке;
сравнение жизненного цикла задач до и после эксперимента.
Решение
изменить процесс доставки задач на ежедневный с количеством готовых
задач;
Профит
баги исправляются быстрее;
легче собирать и тестировать небольшие сборки.
Кейс 2 — доставка сборок с багами
24. Гипотеза
задачи долго ожидают тестирования;
Анализ
наибольший WastedTime в цепочке жизни задач не тестирование, а
ревью;
Решение
реализовать индикатор долгого нахождения задач в ревью тим-
лидеру;
построить уведомления о долгом нахождении задачи в статусе
менеджеру.
Профит
уменьшили задержку задач в ревью;
уменьшили WastedTime;
улучшили жизненный цикл.
Кейс 3 — узкое звено в доставке задач
28. 1. Волнение перед неизвестностью, чем-то новым;
2. Одинаковый взгляд на то, зачем вы хотите что-то измерять;
3. Ответ, как это будет использовано на команде;
4. Предложения от команды о дополнительных графиках;
5. Доверие к данным.
Сложности