6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Вебинар: 12 принципов Agile, которые делают его довольно успешнымak-itconsulting.com
Мы приглашаем вас на бесплатный вебинар, посвященный основам философии Agile. Мы познакомим вас с основными принципами, которые делают Agile успешным и популярным.
В ходе вебинара вы:
- Узнаете о 12 принципах Agile
- Разберетесь, почему каждый из них является важным для достижения успеха
- Поймете принципы, на основе которых создаются инструменты Agile
Узнать больше о вебинаре: http://coach.ak-itconsulting.com/2014/08/12-principov-agile/
Вебинар: 12 принципов Agile, которые делают его довольно успешнымak-itconsulting.com
Мы приглашаем вас на бесплатный вебинар, посвященный основам философии Agile. Мы познакомим вас с основными принципами, которые делают Agile успешным и популярным.
В ходе вебинара вы:
- Узнаете о 12 принципах Agile
- Разберетесь, почему каждый из них является важным для достижения успеха
- Поймете принципы, на основе которых создаются инструменты Agile
Узнать больше о вебинаре: http://coach.ak-itconsulting.com/2014/08/12-principov-agile/
Основы скрам. Версия 1.0
Презентация подготовлена в целях обучения и ознакомления сотрудников с фреймворком Скрам.
Оставляйте комментарии насколько эффективен этот материал для вас и насколько позновательной была информация для вас.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Agile/Scrum методологии разработки программного обеспеченияjazzteam
Сотрудница компании JazzTeam провела ряд лекций в Гродненском государственном университете имени Янки Купалы.
После конференции Solit-2013 в рамках ознакомительного тура по Беларуси для одного из англозычных докладчиков, руководство компании посетило Гродненский государственный университет имени Янки Купалы, где состоялось знакомство с руководством кафедры программного обеспечения интеллектуальных и компьютерных систем. В рамках продолжения отношений между компанией и кафедрой представитель компании JazzTeam провела несколько лекции по тематике разработки программного обеспечения.
Лекции проходили в рамках заседания студенческого семинара “Информатика – Сегодня”, которые университет и кафедра проводят регулярно.
Первая лекция была проведена 22 марта 2013 года на тему: “Agile/Scrum методологии разработки программного обеспечения”.
Посетителей, участников, слушателей этой лекции заинтересовали такие вопросы: преимущества и недостатки agile и scrum, как разработчики решают спорные моменты, как новичок может повлиять на всю команду, как замотивировать разработчиков и т.д. После доклада была продолжительная и насыщенная дискуссия по возникшим у слушателей вопросам.
На лекциях присутствовало много людей, начиная от первокурсников до преподавателей.
Лекции охватывали большой спектр вопросов, и все моменты были разобраны на примерах. Публика вела себя очень оживленно и интересовалась больше примерами из жизни, практическими навыками.
Впечатления о проведенных лекциях остались самые положительные. Спасибо за интересные вопросы и обсуждения!
Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Основы скрам. Версия 1.0
Презентация подготовлена в целях обучения и ознакомления сотрудников с фреймворком Скрам.
Оставляйте комментарии насколько эффективен этот материал для вас и насколько позновательной была информация для вас.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Agile/Scrum методологии разработки программного обеспеченияjazzteam
Сотрудница компании JazzTeam провела ряд лекций в Гродненском государственном университете имени Янки Купалы.
После конференции Solit-2013 в рамках ознакомительного тура по Беларуси для одного из англозычных докладчиков, руководство компании посетило Гродненский государственный университет имени Янки Купалы, где состоялось знакомство с руководством кафедры программного обеспечения интеллектуальных и компьютерных систем. В рамках продолжения отношений между компанией и кафедрой представитель компании JazzTeam провела несколько лекции по тематике разработки программного обеспечения.
Лекции проходили в рамках заседания студенческого семинара “Информатика – Сегодня”, которые университет и кафедра проводят регулярно.
Первая лекция была проведена 22 марта 2013 года на тему: “Agile/Scrum методологии разработки программного обеспечения”.
Посетителей, участников, слушателей этой лекции заинтересовали такие вопросы: преимущества и недостатки agile и scrum, как разработчики решают спорные моменты, как новичок может повлиять на всю команду, как замотивировать разработчиков и т.д. После доклада была продолжительная и насыщенная дискуссия по возникшим у слушателей вопросам.
На лекциях присутствовало много людей, начиная от первокурсников до преподавателей.
Лекции охватывали большой спектр вопросов, и все моменты были разобраны на примерах. Публика вела себя очень оживленно и интересовалась больше примерами из жизни, практическими навыками.
Впечатления о проведенных лекциях остались самые положительные. Спасибо за интересные вопросы и обсуждения!
Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Extensive experience in delivering world-class business solutions enabled Luxoft to become a leader in providing educational service in Agile methodologies.
Luxoft is accredited as a Member Training Organization (MTO) of the International Consortium for Agile (ICAgile). ICAgile develops educational tracks and learning objectives for its member training classes and authorizes course materials for covering a particular set of topics.
Trainings are conducted by certified instructors and include exercises and games aimed at better understanding the topics covered and finding the best ways to adopt them into practice.
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
самое интересное в мире блокчейн, опыт и рецепты от сбербанкаСбертех | SberTech
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Подходы к построению хранилищ данных в крупных организацияхСбертех | SberTech
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
2. Что такое Agile-организация?
1
… которые обладают всеми инструментами, навыками
и полномочиями для удовлетворения определенной
потребности клиента …
… и используют гибкие методы разработки продукта (Scrum,
Kanban, Design Thinking, Lean Startup, …) при максимальной
автоматизации внедрения (DevOps, Continuous Delivery, …)
… и максимальной гибкости поддерживающие процессов
(HR, закупки, финансирование, …)
Agile
организация – это…
… Объединение максимально самодостаточных само-
организующихся кросс-функциональных команд,…
4. 3
Основополагающие принципы Agile-манифеста
3
Мы следуем таким принципам
3. Работающий продукт следует выпускать как
можно чаще, с периодичностью от пары недель до
пары месяцев
1. Наивысшим приоритетом для нас является
удовлетворение потребностей клиента, благодаря
регулярной и ранней поставке ценности
2. Изменение требований приветствуется, даже на
поздних стадиях разработки. Agile-процессы
позволяют использовать изменения для обеспечения
заказчику конкурентного преимущества
4. Разработчики и представители бизнеса должны
ежедневно работать вместе
5. Над продуктом должны работать мотивированные
профессионалы. Чтобы работа была сделана,
создайте условия, обеспечьте поддержку
и полностью доверьтесь им
6. Личное общение является наиболее практичным и
эффективным способом обмена информацией как с
самой командой, так и внутри команды
12. Команда должна систематически анализировать
возможные способы улучшения эффективности и
соответственно корректировать стиль
своей работы
11. Самые лучшие требования, архитектурные и
технические решения рождаются у
самоорганизующихся команд
7. Работающий продукт — основной показатель
прогресса
9. Постоянное внимание к техническому
совершенству и качеству проектирования
повышает гибкость
10. Простота — искусство минимизации лишней
работы — крайне необходима
8. Инвесторы, разработчики и пользователи должны
иметь возможность поддерживать постоянный ритм
бесконечно. Agile помогает наладить такой
устойчивый процесс разработки
5. КОМАНДА
1
КОМАНДА
2
КОМАНДА
N
ЧАПТЕР
1
ЧАПТЕР
2
ЧАПТЕР
N
ТРАЙБ
Основные единицы Agile-организации в Сбербанке –
«Трайб», «Команда» и «Чаптер»
КУРАТОР ТРАЙБА
ТРАЙБ –
группа взаимосвязанных
Команд сформирован-
ная вокруг определен-
ного продукта/бизнес-
цели и отвечающая
за бизнес-результат
КОМАНДА –
кросс-функциональная
совместно работающая
группа специалистов
обладающая всеми
навыками, инструментами
и полномочиями для
самостоятельной разработки
работающего продукта
КУРАТОР–
член Правления банка,
вовлеченный в Agile,
отвечает за бизнес-результат
нескольких Трайбов
ЧАПТЕР–
группа специалистов одной
области компетенций
4
6. Роли-команде
Команда
УК
ВП
УК
СМ
УК
Отвечает за выпуск продукта, соответствующего
потребности клиента
ВП
Владелец продукта
ВП
СМ
Скрам-мастер
Отвечает за эффективность рабочего процесса,
выстраивание эффективных взаимодействий с другими
командами и подразделениями, а также за развитие
самоорганизации и повышение зрелости Команды
СМ
Участник команды
Специалист, непосредственно участвующий
в создании продукта Команды в пределах своих
компетенций, является членом чаптера по линии своей
компетенции
УК
УК
5
8. Для реализации стримов трайба команды детализируют стримы
в бэклоге команды
7
▪ Бэклог команды – это перечень всех требований к стриму трайба/программы,
переданных в команду либо созданных внутри нее
▪ Бэклог команды формируется по принципу pull
▪ Решение о включении элемента в бэклог и его приоритете принимает
Владелец продукта
▪ В бэклоге должны быть только необходимые элементы
▪ Бэклог команды фиксируется на доске команды и отражается
в производственной системе (например, Jira)
▪ Источники элементов бэклога
– Владелец продукта
– Команда
– Другие команды
– Трайб
▪ Элементы бэклога
– Эпики, Фичи, Истории (могут быть пользовательскими либо техническими)
– Техдолг
– Дефекты
Бэклог команды – это приоритизированный
владельцем продукта список элементов
Стрим1
Стрим2
Стрим …
Фича2
Эпик4
История 2
История 1
Высокий
приоритет
Низкий
приоритет
Фича1
История n
История 5
История 6
История 3
История 4
Эпик1
Эпик2
Эпик3
9. Бэклог состоит из следующих типов задач
Совет! Используйте такую цветовую индикацию в вашем бэклоге, чтобы наглядно отображать объем задач каждого типа
Помните, что в каждом спринте не менее 30% доступной трудомощности должно использоваться для работ по Architectural
Runway и техническому долгу
8
Задачи, обеспечивающие реализацию
клиентских задач
▪ Архитектура
▪ Инфраструктура
▪ Общие элементы
▪ Библиотеки
▪ Платформы
▪ Создание переиспользуемых
компонентов
Нужно приоритезировать так же,
как и видимые фичи
Нарастает по мере построения продукта
– отложенные ключевые решения или
плохо сделанная работа
▪ Рефакторинг
▪ Reengineering
▪ Автоматизация тестов
▪ Документирование
▪ ...
Появляются когда желтые элементы
игнорируются
Представляют непосредственную
ценность для конечного
пользователя
Дефекты, которые выявлены
и должны быть исправлены
Добавляются по мере разработки
продукта
PositivevalueNegativevalue
Visible Invisible
Дефекты Технический долг
Ценность
для клиента
(эпики, фичи,
истории)
Architectural
Runway
(эпики, фичи,
истории)
10. Владелец продукта создает бэклог и постоянно обновляет его, собирая
сведения из множественных источников
Высокий приоритет – тщательная
проработка на 4 спринта
Низкий приоритет – приблизительно
прорабатываемые позиции
Приоритизация
элементов бэклога
Исследования
пользователей
Клиент
Вводные от других
команд
Идеи
Маркетинг
Поставщики
Стримы трайбов
Стримы программ
Мониторинг продукта
…
Декомпозиция
и оценка
элементов бэклога
и передача ВП на
реприоритизацию
Советы
▪ Используйте 15 минут после ежедневного стэндапа либо
в конце дня для оценки поступивших элементов бэклога
▪ Используйте сессию по подготовке к планированию
спринта для декомпозиции и уточнения оценки
по приоритетным эпикам и фичам на следующие
два спринта
Команда
▪ Стримы
▪ Эпики
▪ Фичи
▪ Истории
▪ Дефекты
9
Координация, оценка
осуществимости
и корректировка
приоритетов
11. Истории с большей определенностью тщательнее проработаны
10
Множество эпиков и
историй, описывающих еще
не созданный функционал
ФичиБэклог команды
Фичи и эпики
являются
"большими"
историями!
Бэклог команды ЭпикиМенее тщательная проработка
Бэклог спринта ИсторииБолее тщательная проработка
Подмножество бэклога
продукта, предназначенное
для выполнения в рамках
спринта
13. Краткое описание Agile-церемоний команды
Церемония Определение
12
▪ Встреча в первый день каждого спринта направленная на формирование цели и
бэклога начавшегося спринтаПланирование
Спринта
▪ Встреча участников команды, скрам мастера и владельца продукта
для планирования дня и выявления проблем
Стендап-митинг
▪ Встреча участников команды и любых других заинтересованных лиц для
демонстрации продукта команды, созданного за данный спринт
Демонстрация
▪ Ежедневный процесс поддержания бэклога в актуальном состоянии с регулярной
встречей владельца продукта и участников команды для подготовки к
планированию следующего Спринта
Актуализация
Бэклога Команды
▪ Встреча участников команды, владельца продукта и скрам мастера, а также Agile-
коуча для обсуждения совершенствования процессов работы команды и
выявления факторов, мешающих продуктивной работе
Ретроспектива
команды
К1
К2
К4
К3
К5
ПРОЦЕСС И ЦЕРЕМОНИИ AGILE4
1 раз в
спринт
Периодич-
ность
Ежедн.
1 раз в
спринт
1 раз в
спринт
1 раз в
спринт
3-4 ч.
Длитель-
ность
15-30
мин.
1 ч.
2-4 ч.
2 ч.
14. Планирование спринта
13
Цель: формирование бэклога спринта
Входная информация
Состав стримов и дорожная карта трайба
Бэклог команды
Пользовательские истории/требования, планируемые на спринт
Детальная архитектура сервиса
Доска зависимостей
Активности
Определение цели спринта
Выбор пользовательских историй для реализации цели спринта с
учетом их оценки
Калибровка бэклога за счет сравнения трудоемкости историй и
доступных ресурсов команды, например в случае отпусков или других
мероприятий
Проверка наличия критериев приемки по всем историям
Результаты
Цель спринта
Бэклог спринта
K1
К1. Планирование спринта
▪ Встреча в первый день каждого спринта направленная на
формирование цели и бэклога начавшегося спринта
Длительность: ̴ 2-4 ч.
Периодичность: 1 раз в спринт
Участники: Владелец Продукта, Скрам Мастер, команда
15. Ежедневный стендап
14
Цель: синхронизация работ, планирование на день и выявление
возникших проблем
Входная информация
Состав стримов и дорожная карта трайба
Бэклог спринта
Доска зависимостей
Активности
Анализ прогресса в достижении цели спринта
Обсуждение результатов предыдущего дня, планов на текущий день
Обсуждение возникших проблем и определение участников команды,
которые займутся их решением
Определение вопросов, которые нужно поднять на Scrum of Scrums
Каждый участник команды отражает на Доске Задач (аналоговой или
электронной) изменение статуса решаемых им задач
Результаты
Планы на день
Список проблем и планы их решения
K2
К2. Ежедневный стендап
▪ Встреча участников команды, скрам мастера и владельца продукта
для обсуждения результатов предыдущего дня, планов на день
и выявления проблем
Длительность: 15 мин.
Периодичность: Ежедневно
Участники: Скрам мастер, Команда, Владелец продукта
16. Актуализация бэклога команды
15
Цель: подготовка к планированию следующего cпринта
Входная информация
Состав стримов и дорожная карта трайба
Бэклог команды
Доска зависимостей
Детальные архитектуры сервисов
Активности
В рамках процесса по поддержанию бэклога в актуальном состоянии
команды на ежедневной основе выполняют следующие активности:
Обсуждение и описание новых элементов и добавление их в бэклог
команды
Оценка трудоемкости и ценности элементов бэклога
Принятие решений об удалении или разбиении элементов бэклога
Не позднее, чем за два дня до Планирования спринта команда
встречается для того, чтобы убедиться, что элементы потенциального
бэклога спринта проработаны, понятны команде и могут быть
запланированы в работу и, в случае, если это не так, сформировать план
по устранению препятствий.
Результаты
Актуализированный и дополненный бэклог команды
План следующего спринта
K3
К3. Актуализация бэклога команды
▪ Процесс поддержания бэклога в актуальном состоянии с регулярной
встречей владельца продукта и участников команды для
подготовки к планированию следующего Спринта
Длительность: -
Периодичность: Не реже, чем 1 раз в спринт
Участники: Владелец Продукта, Скрам Мастер, команда
17. Демонстрация
16
Цель: Демонстрация работающего продукта, подтверждение достижения
цели спринта и получение командой обратной связи
Входная информация
Бэклог спринта
Результат спринта
Активности
Демонстрация результата спринта (инкремента)
Обсуждение прошедшего спринта
Продолжительность составляет от двух до восьми часов
Выработка предложений по совершенствованию результата спринта
Результаты
Обратная связь для Команды
Пополнение и пересмотр бэклога команды
Релиз (не каждый спринт)
K4
К4. Демонстрация
▪ Встреча участников команды и других заинтересованных лиц для
демонстрации продукта команды, созданного за данный спринт
Длительность: 2-4 ч.
Периодичность: 1 раз в спринт
Участники: Команда, Владелец продукта, Скрам мастер, Лидеры
тем программ, все заинтересованные лица (по желанию)
18. Ретроспектива
17
Цель: Совершенствование процессов работы команды, выявление
факторов, мешающих продуктивной работе, выработка и планирование мер
по их устранению
Входная информация
Выявленные в ходе спринта проблемы и трудности в работе команды
Обратная связь по результатам Демонстрации
Активности
Анализ успешности спринта в отношении людей, отношений между
ними, процессов и инструментов
Выявление позитивных и негативных факторов работы Команды
Разработка плана по внедрению улучшений в процесс работы Команды
Результаты
План улучшения работы Команды
K5
К5. Ретроспектива
▪ Встреча участников команды, владельца продукта и скрам
мастера, а также Agile-коуча для обсуждения совершенствования
процессов работы команды и выявления факторов, мешающих
продуктивной работе
Длительность: 2 ч.
Периодичность: 1 раз в спринт
Участники: Владелец Продукта, Скрам Мастер, Agile-коуч (при
необходимости), команда
19. Фича2
Эпик4
История 2
История 1
Высокий
приоритет
Низкий
приоритет
Каждая новая история
проходит приоритизацию
и добавляется в бэклог
Любой элемент может
быть исключен
в любой момент
За каждый спринт
прорабатываются самые
приоритетные истории
Фича1
История n
История 5
История 6
История 3
История 4
Эпик1
Эпик2
Эпик3
Реализация и управление бэклогом; приоритизация
5
Владелец продукта приоритизирует бэклог, ориентируясь
на относительную ценность элементов
▪ Наиболее приоритетные элементы занимают верхние строчки
в бэклоге продукта
▪ Такие верхние элементы (в основном истории) являются
более детализированными и проработанными
▪ На нижних строчках бэклога продукта находятся
фичи и эпики
▪ Элементы включаются в спринт в порядке их приоритета
в бэклоге и реализуются в рамках производственного
процесса
Любой элемент может
быть реприоритизирован
в любой момент
4
20. Реализация и управление бэклогом: MVP
19
Минимально Жизнеспособный Продукт (MVP) – это продукт, который обладает исключительно минимальным набором свойств и
функций, которых достаточно для сбора обратной связи для последующих улучшений этого продукта.
Польза
Усилия
Risk
Разработка ведется не компонент
за компонентом…
... а целиком, от более простого
продукта к более сложному
Если пользователь хочет добраться от пункта
«А» в пункт «Б», какой способ разработки
принесет пользу быстрее?
Принципы разработки через MVP:
▪ Продукт создается итеративно не старайтесь построить все и сразу!
▪ Продукт создается инкрементально не пытайтесь создать идеальный и исчерпывающий продукт с самого начала!
▪ MVP позволяет снизить риски и учиться на ошибках за счет итеративной и инкрементальной разработки
▪ Agile – это «ранняя реализация пользы» – Allister Cockburn
ИСТОЧНИК: Allister Cockburn and Henrik Kniberg
Польза
Усилия
4
21. Мониторинг продукта
6
▪ Владелец продукта регулярно осуществляет мониторинг
– Метрик продукта
– Различных источников обратной связи (жалобы клиентов,
комментарии и предложения команды, результаты исследований)
▪ На основании мониторинга Владелец продукта корректирует бэклог
и может возвращаться на стадию исследования
5
22. Что собой представляет Хранилище Данных?
21
Хранилище данных – репозиторий данных, хранящий данные организации в
исторической перспективе с целью их использования для отчётности, принятия
стратегических и тактических решений, использования в оперативной
деятельности.
Хранилище данных – объединенная и совместная модель данных для сбора
всех данных организации.
24. Внедрение Agile: Kanban vs Scrum
23
23
• На платформе ЦХД развиваются несколько продуктов
• У каждого продукта отдельная команда. Команда
выбирает эффективную методологию: Kanban, Scrum, …
• Есть интеграционный спринт платформы, включающий:
• Интеграцию кода продуктов
• Регрессионное тестирование платформы
• Проведение ПСИ и подготовку к внедрению
• Есть команды интеграции, сопровождения, архитектуры
Резюме:
• Agile позволил гибкое внедрение изменений
платформы ЦХД по приоритетам заказчика,
которые могут оперативно меняться.
• ЦХД с окружением обеспечивает возможно
работы независимых команд по Agile.
Пример Kanban доски
25. Жизненные циклы производства в АХД
24
Ядро
Область витрин +
отчеты
Часть влияющая
на смежные витрины
Часть не влияющая
на смежные витрины
Четырехнедельные смещенные друг относительно друга циклы
Внедрения раз в две недели. Требуется регресс и ПСИ.
Демонстрация
Продуктив
Ежедневные
релизы
2нед
Цикл платформы
регресс + ПСИ
Kanban
Scrum
Kanban’
Scrum
спринты 2
нед.
Kanban’
Scrum спринты
кратные 2 нед.
патч
пакет
патчей
патч
пакет
патче
й
патч
ПСИ
Kanban’
список
задач
на
вход
новые
задачи
пакет
патчей
пакет
патчей
Раз в неделю:
новый функционал
Раз в 2 недели:
SLA функционал
задачи
Сервисный подход
по обработке
поступающих
задач
Есть доступ к данным продуктивной среды и
возможность внесения изменений ежедневно
Все изменения только через
интеграционный спринт платформы