Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
На конкретном примере рассматривается: как выбрать момент для внедрения процессов, как показать пользу от внедрения процесса, как выбрать авторов и формат описания, и, самое главное - как проконтролировать внедрение процесса.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Презентация показывает значимость процесса Инициирования Проекта (Project Initiation), а также его основного артефакта - Устава Проекта (Project Charter). Устав Проекта описывает Правила взаимодействия с заказчиком и решает многие проблемы на ранних стадиях. Но к сожалению Устав не всегда делают качественно, или вообще не делают, что и приводит ко множеству разочарований, взаимных претензий и т.п.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
На конкретном примере рассматривается: как выбрать момент для внедрения процессов, как показать пользу от внедрения процесса, как выбрать авторов и формат описания, и, самое главное - как проконтролировать внедрение процесса.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Презентация показывает значимость процесса Инициирования Проекта (Project Initiation), а также его основного артефакта - Устава Проекта (Project Charter). Устав Проекта описывает Правила взаимодействия с заказчиком и решает многие проблемы на ранних стадиях. Но к сожалению Устав не всегда делают качественно, или вообще не делают, что и приводит ко множеству разочарований, взаимных претензий и т.п.
PRojects IN Controlled Environments 2 (PRINCE2) - это структурированный метод управления проектами, одобренный правительством Великобритании в качестве стандарта управления проектами и признанный во всем мире. Презентация посвящена особенностям применения методологии PRINCE2 на практике в российских условиях
Бесплатный вебинар по QA Александра Кузняка от проекта GoITGoIT
Состоялся QA-вебинар от опытного QA инженера — Александра Кузняка. Ребята зарядились энергетикой нашего спикера и вдохновились на поиск новых возможностей для развития.
На QA-вебинаре от образовательного проекта GoIT участники:
1. Узнали об основах профессии QA инженера
2. Записали какими скиллами должен владеть толковый тестировщик
3. Получили советы о том, что учить и как развиваться для успешной карьеры в QA
4. Узнали о потенциальных вариантах карьерного развития и роста в профессии QA
5. Узнайли что будет на предстоящих Мастер-классах от Александра Кузняка
6. Получили информацию о грядущем курсе QA по системе blended learning
7. Узнали подробности об ивенте IT Fest (пройдет в Киеве 19го сентября).
8. Задали любые вопросы спикеру и получи на них ответы.
Проводил Вебинар:
Александр Кузняк — QA Consultant & Practice Leader в компании Ciklum. Более 11 лет работает в IT, более 6 лет — в разработке программного обеспечения.
Участвовал в 100+ проектах и провел более 350 собеседований.
С 2012 года — глава судейского комитета в направлении QA всеукраинского конкурса веб-разработки — UA Web Challenge.
Управлял QA-командами и отделами, создал и развил сервисный QA-департамент в рамках компании, обучил и трудоустроил десятки QA-инженеров.
Спасибо всем, кто уделил время своему развитию. Верим, что наши активности вдохновляют и помогают вам двигаться вперёд к своей цели — успешной карьере в IT!
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Национальные особенности подготовки к сдаче экзамена PMPЕвгений Пикулев
Презентация построена на основании трехлетнего опыта подготовки к эказмену PMP в Екатеринбурге в рамках "Школы PMP". Подробнее здесь http://gibtech.ru/pmp_school/
PRojects IN Controlled Environments 2 (PRINCE2) - это структурированный метод управления проектами, одобренный правительством Великобритании в качестве стандарта управления проектами и признанный во всем мире. Презентация посвящена особенностям применения методологии PRINCE2 на практике в российских условиях
Бесплатный вебинар по QA Александра Кузняка от проекта GoITGoIT
Состоялся QA-вебинар от опытного QA инженера — Александра Кузняка. Ребята зарядились энергетикой нашего спикера и вдохновились на поиск новых возможностей для развития.
На QA-вебинаре от образовательного проекта GoIT участники:
1. Узнали об основах профессии QA инженера
2. Записали какими скиллами должен владеть толковый тестировщик
3. Получили советы о том, что учить и как развиваться для успешной карьеры в QA
4. Узнали о потенциальных вариантах карьерного развития и роста в профессии QA
5. Узнайли что будет на предстоящих Мастер-классах от Александра Кузняка
6. Получили информацию о грядущем курсе QA по системе blended learning
7. Узнали подробности об ивенте IT Fest (пройдет в Киеве 19го сентября).
8. Задали любые вопросы спикеру и получи на них ответы.
Проводил Вебинар:
Александр Кузняк — QA Consultant & Practice Leader в компании Ciklum. Более 11 лет работает в IT, более 6 лет — в разработке программного обеспечения.
Участвовал в 100+ проектах и провел более 350 собеседований.
С 2012 года — глава судейского комитета в направлении QA всеукраинского конкурса веб-разработки — UA Web Challenge.
Управлял QA-командами и отделами, создал и развил сервисный QA-департамент в рамках компании, обучил и трудоустроил десятки QA-инженеров.
Спасибо всем, кто уделил время своему развитию. Верим, что наши активности вдохновляют и помогают вам двигаться вперёд к своей цели — успешной карьере в IT!
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Национальные особенности подготовки к сдаче экзамена PMPЕвгений Пикулев
Презентация построена на основании трехлетнего опыта подготовки к эказмену PMP в Екатеринбурге в рамках "Школы PMP". Подробнее здесь http://gibtech.ru/pmp_school/
Презентация Алины Гусейновой, International Tax Manager в Deloitte Ukraine, на семинаре IT Legal Talk 2 от Kharkiv IT Cluster. Мероприятие состоялось 12 декабря 2015 года. Отчёт о событии найдёте здесь: http://goo.gl/L0kFLK
Презентация Иванны Погребняк, Director of Legal AltexSoft, на семинаре IT Legal Talk 2 от Kharkiv IT Cluster. Мероприятие состоялось 12 декабря 2015 года. Отчёт о событии найдёте здесь: http://goo.gl/L0kFLK
Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
Оценка эффективности от внедрения и использования методологии и инструменталь...Alexander Novichkov
http://cmcons.com
http://anovichkov.msk.ru
Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational.
Практика внедрения и взаимодействия с заказчиком.
15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Competency Model (HR API conference, Russian language) Irina Leshchuk
В докладе представлен опыт разработки, внедрения и использования модели компетенций для сотрудников компании. В нем говорится о том, как удалось подготовить решение, которое одновременно отвечает запросам со стороны бизнеса и используется для оценки и развития сотрудников в компании Grid Dynamics.
Кажется, что доклад будет интересен руководителям подразделений, менеджерам команд, HR специалистам и всем, кто интересуется вопросами оценки и развитием сотрудников внутри компании.
Целевой аудиторией, прежде всего, являются компании, в которых работает больше 100 инженеров и особенно актуально для тех, где есть распределенные команды в разных городах. Для компаний небольшого размера или стартапов содержание презентации будет интересно, скорее, с познавательной точки зрения, чем с практической.
Тренер-консультант учебного центра "СКАУТ-Академия" Валентина Крупадерова подробно разбирает ситуации с изменениями в проекте, инициатором которых выступает заказчик. Вы посмотрите на ситуацию глазами менеджера проекта и увидите, где его зоны влияния в ней.
Это первый вебинар блока "Разбор ситуаций". Весь блок направлен на то, чтобы увидеть конкретную ситуацию со стороны, в контексте всего проекта, чтобы лучше понимать возможные действия в ней.
На этом вебинаре мы разберем ситуацию с изменениями в проекте, инициатором которых выступает заказчик. Мы посмотрим на ситуацию глазами менеджера проекта и увидим, где его зоны влияния в ней.
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
It talk №23: "Если не Scrum, то что?", Екатерина ШалапановаMarina Peregud
Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург
О чем пойдет речь:
Что делать:
Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide?
Если в итерацию врываются сверхсрочные задачи?
Если бизнес-процессы не позволяют регулярные релизы?
Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями?
Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов.
Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.
Similar to Слайдкаст. Stratoplan Kharkov. Методологический паззл. (20)
This two days course provides classic approaches for Planning and Risk Management. It is based on both easily applicable practical approaches and PMBOK guidelines. Major ideas are how reasonable classic can help things done on schedule, on budget.
Corporate consulting for fast growing, transforming IT companies which are looking for better operations efficiency, better business processes, building Quality Management System (QMS)
Мастер класс был проведен на конференции PMCon #4, Харьков, 2017.
Мы начнем мастер-класс с разминки - обсудим кто какие метрики применял, чем они были полезны или бесполезны. Затем рассмотрим принципиальный вопрос - зачем нужны метрики и какова их роль в ИТ-бизнесе. Потом, на большом практическом занятии узнаем как правильно увязывать процессы и проблемы реального мира с метриками, и, соответственно, как разумный подбор метрик может помочь их решить. Завершим мастер-класс обсуждением условий, при которых применение метрик имеет смысл.
This Overview represents such important and complicated at the first glance discipline as Software Measurements which is comprehensively covered in the training.
The following topics are covered in simple and logical thought chanes:
- process and product quality
- team and personal performance
- HR and business metrics
- raw data to executive dashboard evolution and vice versa
- size model
- business circumstances
- answers to many whats, whys, hows
- provides theoretical background
- and practice, practice, practice...
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
1. К онференция S tratoplan World. Kharkov edition К руглый стол «Методологический паззл»
2.
3.
4.
5. Что это все значит? Что с этим делать? Стандарты Модели, фреймворки, своды знаний Типы контрактов Типы проектов Методологии Инженерные и Управленческие практики Фазы проекта
12. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Модели, фреймворки, своды знаний Что Как Инженерные и управленческие практики
13. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики
14. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики Адаптация под проект ( Tailoring )
22. Конструктор Окружающая среда проекта Типы проектов Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
23. Конструктор Окружающая среда проекта Типы проектов Жизненный цикл проекта Прототип Сбор треб. Реализация Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
Меня зовут Тимофей Еграшин и я занимаюсь управлением проектами уже около девяти лет. Я пробовал разные подходы и всегда стремился не повторять своих ошибок. Года четыре назад, я понял, что лучшие мои проекты имели все характеристики Agile проектов, а с тех пор как я узнал больше о Scrum , я использую его как основу для организации проектов с которыми я работаю.
Несколько слов о нас. Все команды являются внутренними командами разработки крупной скандинавской медиа корпорации. Будучи внутренними командами мы получили очень тесное сотрудничество с заказчиками. Зачастую разработчики и заказчик могут сидеть в соседних комнатах. В тоже время, будучи частью корпорации мы должны считаться с корпоративными правилами и зачастую для установки внутреннего сервиса типа вики, команда обращается к корпоративному IT департаменту как обычный заказчик, со всеми вытекающими взаимодействиями и возможными задержками такого, казалось бы простого дела. Когда команды только собирали, руководство отдела разработки оказало поддержку идеи использовать Scrum как основную методологию организации взаимодействия и управления командами. Мы уже сегодня могли слышать, что «поддержка сверху» всегда помогает на старте. В тоже время, команды выделены под конкретные бизнес-подразделения и это не освобождает нас от необходимости выстроить взаимоотношения заказчик-подрядчик и по дороге объяснить как мы будем работать, кто что делает и т.п.
Команда Б: +Занимается разработкой серии схожих он-лайн проектов. Это по сути интернет-газеты, думаю многие читают Корреспондент. net , который можно частично использовать как аналогию +Такие контент-ресурсы всегда связаны с разными источниками информации и кроме внутренней редакции есть еще много партнеров с которыми необходимо интегрироваться. Иногда незаметно, сопровождая это соответствующим брендингом разделов и так далее +Любой газетный бизнес, особенно Интернет-газета это быстрая смена приоритетов и требований. Иногда граничащий с хаосом. +Веб проекты в целом и такой бизнес в частности, очень требовательны к регулярной публикации результатов работы. Т.е. Тут действительно идет речь о выпуске в он-лайн результатов каждого спринта, а иногда и чаще. Сама Scrum команда изначально была распределена между двумя странами. Команда действительно кросс-функциональная и включает как разработчиков так и тестеров
Прежде чем идти дальше, я хочу вкратце рассказать как мы начинали: 1. Как я говорил, мы изначально решили строить все процессы на основе Scrum – это было объявлено бизнесу в целом и каждому кандидату в частности 2. Каждая команда со старта получила ScrumMaster’ а, который кроме того, что имел уже опыт лидера команды, так же прошел курс Certified ScrumMaster , что позволило говорить о хорошем начальном уровне СкрамМастеров 3. Более того, сразу как только команды были укомплектованы, они прошли совместный вводный тренинг, где члены команды и владельцы продукта узнали о том «зачем» мы работаем по Scrum и как именно мы собираемся его делать. 4. Ну и при поддержке руководства мы получили выделенных Владельцев Продукта, которые с самого начала знали об ожидаемых обязанностях и ответственности, которые подразумевает эта роль
Если первая команда была крайностью в отношении релизов, то у второй команды работа идет постоянно, вне зависимости от наличия хоть сколь-нибудь сфокусированных проектов Как я говорил, проекты у этой команды очень маленькие и максимум длятся пару спринтов Каждый спринт заканчивается не просто демонстрацией, а публикацией результатов в «лайв», где сайты посещают тысячи людей каждый день. Это ведет к тому, что все, что команда заявляет как «Сделано», должно быть готово к публикации без дополнительных работ. В таких условиях, необходимости планировать долгосрочные релизы просто нет. Для тех мини-«проектов», которые я упомянул достаточно наглядно можно отследить отношение Сделано/не Сделано, что дает ВП ясное представление о ситуации.
Жизнь второй команды сложно назвать размеренной Сам по себе газетный бизнес подвержен очень быстрым изменениям К тому же, реализация может отличатся от ожидаемой сложности, так как есть много маленьких факторов каждодневного риска. Например, внешний поставщик информации еще не готов к интеграции и команде приходится строить решения с разного рода заглушками. Или наоборот, казалось бы простая функция потребовала изменения других областей или обобщения существующих функций в единую библиотеку. Бывают и хорошие ситуации, когда команда делает сложную работу быстро О, а еще бывают «пожары», когда происходят сбои на он-лайн серверах. Система достаточно сложная и бывают ситуации, когда администраторы из поддержки обращаются за помощью к разработчикам и тогда команда откладывает свои планы и разбирается в ситуации. Лучший совет в такой ситуации, это расслабиться и получать удовольствие. Самый главный шаг был сделан ВП – он поинмает ситуацию и всегда готов к диалогу, если команда в силу объективных причин не успевает сделать первоначальный план
У команды Б, ретроспективы проходят между разработчиками, так как только они отвечают за совершенствование своих методов и подходов Несмотря на все описанное мной тесное взаимодействие между ВП и командой, не стоит забывать, что он все-таки человек бизнеса и не всегда хорошо понимает «технический язык» Ретроспективы проходят как анализ последних значимых событий или как тематические обсуждения долгосрочных планов развития и улучшения. Обычно выбирают договариваются об 1-2 изменениях на следующий спринт, формируют план действий И результаты сообщают ВП, особенно если требуются инвестиции времени во внутренние технические работы Кроме регулярных встреч, раз в год команда старается проводить глобальную ретроспективу, чтобы проанализировать чего успели добиться за год и какие основные цели должны быть достигнуты