Видео: https://www.youtube.com/watch?v=I5bI1QTGrRs
Провёл тренинг и kickoff, а команда всё равно не понимает, зачем она повесила доску, и каждый день двигает стикеры? Завёл бэклог и запустил все события Scrum, а Владелец Продукта продолжает себя вести как начальник отдела или руководитель проекта? Провёл воркшоп по 5 порокам команды, а её участники продолжают работать обособленно? Значит ты что-то упустил при внедрении изменений. На докладе рассмотрим, типичные ошибки внедрения изменений на реальных примерах из Agile-кочинга и как их избежать:
- Отсутствие активного участия руководства
- Недостаточное вовлечение сотрудников
- Недостаточное уделение внимания планированию трансформации
- Завышенные ожидания от Agile и отсутствие желания/возможности поменять окружение
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Михаил Подурец. Почему Agile не работает (на самом деле нет). Agiledays2017LuxoftAgilePractice
Каждый уважающий себя Agile-coach рано или поздно должен высказаться на эту тему:
— АААА! Оно у нас не работает
— Ваш Скрам у нас невозможен
— Как вы предлагаете делать нам интеграционное тестирование внутри спринта, если оно занимает месяц!? О_о
Спокойно! На докладе мы разберем, почему оно не работает, и как на самом деле оно должно работать.
Презентация с доклада на AgileDays 2017. Скоро будет видео
Видео: https://www.youtube.com/watch?v=I5bI1QTGrRs
Провёл тренинг и kickoff, а команда всё равно не понимает, зачем она повесила доску, и каждый день двигает стикеры? Завёл бэклог и запустил все события Scrum, а Владелец Продукта продолжает себя вести как начальник отдела или руководитель проекта? Провёл воркшоп по 5 порокам команды, а её участники продолжают работать обособленно? Значит ты что-то упустил при внедрении изменений. На докладе рассмотрим, типичные ошибки внедрения изменений на реальных примерах из Agile-кочинга и как их избежать:
- Отсутствие активного участия руководства
- Недостаточное вовлечение сотрудников
- Недостаточное уделение внимания планированию трансформации
- Завышенные ожидания от Agile и отсутствие желания/возможности поменять окружение
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Михаил Подурец. Почему Agile не работает (на самом деле нет). Agiledays2017LuxoftAgilePractice
Каждый уважающий себя Agile-coach рано или поздно должен высказаться на эту тему:
— АААА! Оно у нас не работает
— Ваш Скрам у нас невозможен
— Как вы предлагаете делать нам интеграционное тестирование внутри спринта, если оно занимает месяц!? О_о
Спокойно! На докладе мы разберем, почему оно не работает, и как на самом деле оно должно работать.
Презентация с доклада на AgileDays 2017. Скоро будет видео
Гибкие методологии разработки ПО в реальном миреTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=ooa5qE7oTQg
8 апреля 2016. Гибкие методологии разработки ПО в реальном мире (Антон Дёмин, Xored)
На этой лекции мы рассмотрим классические модели управления проектами, поговорим о реалиях разработки и о наиболее частых проектных проблемах, с которыми сталкиваются разработчики и менеджеры.
Среди прочего мы рассмотрим гибкие методологии; как в общем, так и на примере их конкретных представителей (Scrum, XP, Kanban). Также будет рассказано о процессе перехода на Scrum на примере крупного проекта для одного из клиентов компании.
Кроме того, поскольку гибкие методологии подразумевают гибкие правила, мы прямо на лекции попробуем модифицировать одну из хрестоматийных методологий под нужды конкретного проекта, а именно — немного доработаем Scrum путем добавления в него артефактов из других методологий.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Борис Вольфсон. Agile ценности и принципы для новичков.ScrumTrek
Это базовый доклад для новичков в Agile, которые только хотят использовать гибкие подходы, будет построен через ценности и принципы, на которых строятся отдельные практики и целые фреймворки. Понимание Agile через призму ценностей и принципов позволит не только лучше разбираться в гибком фреймворке Scrum и методе Kanban, но и после освоения основ изменять их под свою среду и нужды.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
Гибкие методологии разработки ПО в реальном миреTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=ooa5qE7oTQg
8 апреля 2016. Гибкие методологии разработки ПО в реальном мире (Антон Дёмин, Xored)
На этой лекции мы рассмотрим классические модели управления проектами, поговорим о реалиях разработки и о наиболее частых проектных проблемах, с которыми сталкиваются разработчики и менеджеры.
Среди прочего мы рассмотрим гибкие методологии; как в общем, так и на примере их конкретных представителей (Scrum, XP, Kanban). Также будет рассказано о процессе перехода на Scrum на примере крупного проекта для одного из клиентов компании.
Кроме того, поскольку гибкие методологии подразумевают гибкие правила, мы прямо на лекции попробуем модифицировать одну из хрестоматийных методологий под нужды конкретного проекта, а именно — немного доработаем Scrum путем добавления в него артефактов из других методологий.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
Алексей Пименов. Kanban — это не то, что вы привыкли о нем думатьScrumTrek
Что только не называют сегодня Канбаном. В каком только виде не пытаются это использовать. Но если мы хотим результат, и результат уровня организации, то нам надо точно знать, что такое - современный Канбан для нематериального производства, как он работает, за счет чего и как он помогает развивать организации. Мы познакомимся с основными принципами, практиками, повестками и метриками Канбана. Рассмотрим механику его работы в организации и то, каким образом он развивает культуру.
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Борис Вольфсон. Agile ценности и принципы для новичков.ScrumTrek
Это базовый доклад для новичков в Agile, которые только хотят использовать гибкие подходы, будет построен через ценности и принципы, на которых строятся отдельные практики и целые фреймворки. Понимание Agile через призму ценностей и принципов позволит не только лучше разбираться в гибком фреймворке Scrum и методе Kanban, но и после освоения основ изменять их под свою среду и нужды.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
- VUCA мир или как выжить бизнесу в современных реалиях.
- Что такое Agile. Ключевые принципы.
- Agile-методологии: Scrum и Kanban. Что это такое и как применять на практике.
- Реальные кейсы применения Agile в производственных компаниях.
- Практикуем Agile-подход.
Подготовлено "ЭКОПСИ Консалтинг
www.ecopsy.ru
It talk №23: "Если не Scrum, то что?", Екатерина ШалапановаMarina Peregud
Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург
О чем пойдет речь:
Что делать:
Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide?
Если в итерацию врываются сверхсрочные задачи?
Если бизнес-процессы не позволяют регулярные релизы?
Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями?
Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов.
Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.
Что такое agile?
Не бойтесь незнакомого слова и не думайте, что оно относится только к сфере ИТ и разработке программного обеспечения. Действительно, изначально agile - это идеология подхода к разработке программного обеспечения. Но в последнее время гибкий подход к проектам (Agile) нашел применение не только в сфере ИТ. Уже сейчас те, кто применяют формат Agile-управления проектами в разных сферах и отраслях, более успешны, чем их конкуренты. Еще более модным agile-подход сделал Герман Греф, сказав, что "Те, кто не освоит Agile сегодня в куче бизнес-процессов – будет лузерами завтра".
Сергей Рогачев; Лилия Алексеева. Дизайн и запуск Agile-команд.ScrumTrek
Запуск в Agile — это одно из ключевых событий в жизни команды: от него зависит, взлетит ли Agile? Но запуск дает только 30% гарантии успеха, около 60% зависит от правильного дизайна команды. Мы расскажем, как проводить дизайн команды. Причем покажем на цифрах реального статистического исследования, как ошибки при дизайне отражаются на эффективности команд. Мы поделимся опытом, как непосредственно при запуске команды можно исправить кривой дизайн. И что делать, если нужно запустить одновременно много команд.
Основы скрам. Версия 1.0
Презентация подготовлена в целях обучения и ознакомления сотрудников с фреймворком Скрам.
Оставляйте комментарии насколько эффективен этот материал для вас и насколько позновательной была информация для вас.
Постановка и улучшение Scrum процесса для группы проектов в компанииSoftengi
Доклад Виктора Беженара, Team Led компании Softengi, с международной конференции Lviv PM Day, 26 апреля 2014 года.
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Similar to SECON'2017, Цветцих Денис, Как добавить работе по Agile предсказуемости, не потеряв гибкость (20)
SECON'2017, LAZADA Effartlrss Shopping, Как мы тестируем?SECON
Тестирование заказов в ecommerce международного масштаба/ Order Lifecycle - Жизненный цикл заказа vs QA / Lazada. Азиатская кухня ecommerce тестирования.
SECON'2017, Кошак Павел, Покажи миру язык. Пять секретов грамотной локализации
SECON'2017, Цветцих Денис, Как добавить работе по Agile предсказуемости, не потеряв гибкость
1. #SECONRU
Как добавить работе по Agile
предсказуемости,
не потеряв гибкость
Цветцих Денис
Руководитель проектов в компании OneSystems
ПЕНЗА
2. Кто я
• Меня зовут Денис и я руковожу проектами уже 4 года
• Опыт как в аутсорсинге, так и в продуктовой разработке
• Опыт работы и по тяжелым методологиям, и по Agile
2
3. В нашей компании некоторое время назад
• 1 заказчик
• 3 команды
• Scrum по евангелию
• Один филиал в Новосибирском академе
• ПМ вообще не было
3
4. Со временем
• Нас стало много (более 15 команд)
• Стало много заказчиков
• Появились ПМ
• Филиалы Челябинске, Питере и Новосибирске в городе
• Специализированные команды с отдельными бэклогами
• Команды не кроссфункциональные (QA отдельно от Dev)
4
5. Особенности
Кровавый Enterprise (рынок страхования)
Мы разрабатываем продукт
Но продукт дорабатывается для каждого кастомера
Перед кастомерами есть обязательства по задачам и срокам
Ежемесячные релизы
5
7. Мы хотим
• Сократить время выхода задач, затрагивающих все проекты
• Водопад с четким ТЗ – однозначно сделать не то
• Писать ТЗ на 100 страниц – не попасть ни в какие сроки
• Укладываться в дедлайны для задач
7
9. О чем поговорим
Каким бывает масштабирование Agile
• Scrum of Scrums
• Nexus
• LeSS
• SAFe
С чего начать и какие будут трудности
9
10. Опрос
• Кто ничего не знает о масштабировании Agile?
• Кто слышал, но не применял?
• У кого есть опыт применения?
10
11. Scrum of Scrums
Митинг скрам-мастеров
Как часто проводить, не регламентируется (как правило каждый день)
Что обсуждать – тоже не регламентируется, но как правило:
• Что сделали с прошлого собрания
• Какие проблемы (в том числе во взаимодействии команд)
• Что сделаем к следующему собранию
11
12. Это круто, когда:
• Общий бэклог на все команды
• Команды взаимозаменяемы
12
13. Не описывается
Одновременный ли старт спринтов в разных командах?
Как часто проводить Scrum of Scrums?
Каким составом его проводить?
Какие вопросы обсуждать?
Кроссфункциональные команды или нет?
13
17. Nexus Integration Team
Nexus Integration Team (NIT) – команда, ответственная за
• Успешную интеграцию всех сделанных инкрементов
• Решение вопросов взаимодействия команд
В нее входят представители команд
17
18. Nexus Sprint Planning
• NIT разбивает бэклог на задачи до размера, когда одна команда может
закончить задачу за один спринт
• Выявляются и визуализируются зависимости между задачами
• Формируется roadmap: что и какой командой будет сделано в каком
спринте
• Команды более подробно анализируют свои задачи
18
19. Nexus Daily Scrum
Аналог Daily Scrum для NIT
• Что было успешно интегрировано до сегодняшнего Daily Scrum?
• Какие новые зависимости обнаружили?
• Какую информацию нужно распространить среди команд сегодня?
19
20. Nexus Retrospective
• NIT определяет проблемы, затронувшие более одной команды
• В командах проводится ретро с учетом общих проблем
• Формируется общее видение как отслеживать сформулированные пункты
20
21. Итого
Тоже классно, когда:
• Команды взаимозаменяемы
• Общий бэклог
Плохо работает, когда:
• Разные бэклоги
• Команды не заменяемые
• Минимизация зависимостей не работает
21
23. Large-Scale Scrum (LeSS)
Отличия от Nexus:
• Планируют инкремент не представители, а команды целиком
Достоинства:
• Есть ресурс с описанием практик
• Есть инфраструктура в виде тренеров и консультантов
23
27. Scaled Agile Framework (SAFe)
Преимущества:
• Сокращение Time To Market на 30-50%
• Багов меньше на 50%
• 20-50% рост продуктивности
• Более счастливые сотрудники
27
28. Особенности
• 5-12 Agile команд (50-150 человек)
• Команды могут работать по Scrum или Kanban
• Но нужно работать двухнедельными итерациями
• Итерации всех команд выравниваются
• Общий бэклог
28
29. Координация
Роль Release Train Engineer, отвечающий за общий результат
Команда из RTE, Product Manager, System Architect
Еженедельные встречи
29
30. Самое интересное
• Релизный цикл (Agile Release Train) – 5 итераций
• В течение цикла возможны промежуточные релизы
• Общий Product Increment (PI)
• PI Planning – планирование PI всеми командами в полном составе!
30
34. Техдолг
Обычно – неприятно, но терпимо
SAFe – препятствие к достижению целей
Enabler – специальная задача для техдолга
Enabler планируется совместно с новыми фичами
Последний спринт ART – прототипы, хакатоны и исследования
Надоело продавать техдолг своему ProductOwner – внедряйте SAFe
34
36. Воспитать своих аналитиков
Наш ART – месяц (2 итерации по 2 недели)
На момент старта ART - требования на 2 итерации вперед
При анализе фичи прописывается, она нужна:
• в каких продуктах
• для каких кастомеров
По возможности – уже указаны зависимости между задачами
36
37. Унифицировать оценки
• Оценка в одинаковых попугаях
• Заложены одинаковые вещи
• Code Review добавили
• Reverse Integration, Developer testing – убрали
• Одинаково трекаются часы
• Подобная декомпозиция типовых задач
• Добавление поля в программу
37
39. Синхронизовать спринты
Выгоды:
• Если на каком-то проекте понадобится помощь, мы точно знаем, когда к
нему может подключиться новая команда
• Есть команда поддержки которая меняется. Нет проблем сделать замену
39
41. Поддержка в Task tracker
У нас – Jira
• Task и Subtask – в течение спринта
• User Story – в течение ART
• Epic – в течение нескольких ART
• Enabler – отдельный Issue Type от Task
41
42. Выводы
• Внедрение SAFe, как и внедрение PMO – это сложно
• Изменение структуры компании
• Быть или не быть QA отделу
• Составление регламентов
42
44. Результат
До «перестройки»:
• Любые фичи – от 3 месяцев. Как правило – больше
После перестройки:
• Мелкие фичи – месяц во всех продуктах
• Большие фичи – 2 месяца во всех продуктах
44
45. Планы
Перейти на ART по 3 месяца через год
• Укладывать в 3 месяца доработку под кастомера
• Синхронизировать работу Dev и Sales
45
Январь Февраль Март Апрель Май Июнь
Команда 1 Штат А Штат В
Команда 2 Программа X Программа Y
46. Что почитать/посмотреть
Документация по SAFe
http://www.scaledagileframework.com/
Ролики
SAFe overview: краткий обзор https://www.youtube.com/watch?v=NOcYhwarLkM
SAFe Portfolio & Value stream https://www.youtube.com/watch?v=1Kv9-qiYFQM
SAFe Agile Release Train execution https://www.youtube.com/watch?v=utDIdiQdoqU
SAFe Практика внедрения на реальных проектах https://www.youtube.com/watch?v=G1ZPndN8dto&t
46
Водопад вообще не катит, предметная область сложная и написать ТЗ и потом пилить его несколько месяце в подводной лодке – однозначно сделать что-то не то.
Да и все требования сразу заказчик выдать не сможет, часто требования несколько раз прорабатываются и уточняются
Нужно ли одной команде подхватить задачи другой команды
Держит ли одна команда другую команду
Автор – Кен Швабер, работал над первыми версиями Scrum
https://habrahabr.ru/company/nixsolutions/blog/306070/
Выделенная команда называется русским словом Troika
Release Train Ingineer - отвечает за общий результат
Еженедельные совещания Scrum Master и RTE
Планирование так, чтобы задачи уплотнялись
Техдолг – что сделать в этом ART чтобы следующий прошел лучше
Из 5 итераций планируется 4. Последняя итерация – для хакатонов, экспериментов и обкатки идей
Как в Nexus не нужно проставлять какая команде делает какую задачу, бэклоги разные