6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
6-7 июня на мероприятии Startup Village в Сколково прошла серия митапов, организованных совместно Сбербанком и СберТехом. Вашему вниманию - серия презентационных материалов с мероприятия.
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной ...RIF-Technology
В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами.
Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
Иван Дубровин, Возможные подходы к контрактованию в AgileScrumTrek
Сравнительный анализ моделей заключения контрактов на Agile-разработку ПО: -"Традиционный" fixed-price и fixed-scope -Time materail -Agile fixed-price плюсы и минусы каждого варианта, рекомендуемый подход к составлению Agile fixed-price контракта.
Олег Швайковский, Европейский опыт государственного AgileScrumTrek
Мы разберем на нескольких примерах применения Agile в госпроектах основные преимущества, недостатки и вызовы при применении Agile подхода к управлению проектами в госсекторе. Как со стороны исполнителя, так и заказчика.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Тестирование в Эджайле - это особый процесс, который требует гибкости, скорости и тщательности в выборе инструментов и методик. Больше общения в команде и только самая необходимая документация.
В этом докладе я расскажу о том, как организован процесс тестирования в компании «908». Какие практики мы используем или пробовали, к каким выводам пришли, что оставили, а от чего пришлось отказаться.
Денис Тучин - Почему всегда не успеваем QA? Как могут помочь гибкие методы в ...Denis Tuchin
Какие основные проблемы есть при тестировании больших проектов и как их помогают решить гибкие (agile) практики.
Какие инструменты помогают снизить накладные расходы на тестирование при постоянно меняющихся требованиях
Мертвая зона - Как визуализировать поток требований в распределенном проектеMagneta AI
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
Иван Дубровин, Возможные подходы к контрактованию в AgileScrumTrek
Сравнительный анализ моделей заключения контрактов на Agile-разработку ПО: -"Традиционный" fixed-price и fixed-scope -Time materail -Agile fixed-price плюсы и минусы каждого варианта, рекомендуемый подход к составлению Agile fixed-price контракта.
Олег Швайковский, Европейский опыт государственного AgileScrumTrek
Мы разберем на нескольких примерах применения Agile в госпроектах основные преимущества, недостатки и вызовы при применении Agile подхода к управлению проектами в госсекторе. Как со стороны исполнителя, так и заказчика.
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Тестирование в Эджайле - это особый процесс, который требует гибкости, скорости и тщательности в выборе инструментов и методик. Больше общения в команде и только самая необходимая документация.
В этом докладе я расскажу о том, как организован процесс тестирования в компании «908». Какие практики мы используем или пробовали, к каким выводам пришли, что оставили, а от чего пришлось отказаться.
Денис Тучин - Почему всегда не успеваем QA? Как могут помочь гибкие методы в ...Denis Tuchin
Какие основные проблемы есть при тестировании больших проектов и как их помогают решить гибкие (agile) практики.
Какие инструменты помогают снизить накладные расходы на тестирование при постоянно меняющихся требованиях
Мертвая зона - Как визуализировать поток требований в распределенном проектеMagneta AI
Сергей Прохоренко, Luxoft (Киев)
Последние несколько лет я работаю в Agile-командах в различных ролях - аналитика, proxy PO, процессного коуча. За это время я наблюдал самые различные проекты, сталкивающиеся с похожими препятствиями при масштабировании и помогал им в решении проблем.
Общепринятые практики Scrum предлагают большое количество инструментов для визуализации командной работы: product/sprint backlog, доска, ежедневные стэндапы, burndown chart. Но если ваш проект распределен по трем-четырем локациям, а количество людей в проекте перевалило за сотню - как понять, правильно ли расставлены приоритеты, понимают ли команды, чем они и их коллеги по проекту будут заниматься в следующем спринте и дальше?
Многие из этих вопросов часто попадают в "мертвую зону", что приводит к проблемам при масштабировании процесса.
Рассмотрев несколько практических примеров из практики, мы обсудим, как построить эффективную коммуникацию между командами в проекте, как визуализировать поток требований и как определять критерии для продвижения новых требований из product backlog в sprint backlog.
Мастер-класс. Интерактивная презентация + деловая игра «Управление командами разрабатывающими ПО по Agile (Scrum) и выводу нового программного продукта (ПО) на рынок» c использованием симулятора проектной деятельности (СПД) BesTeamKpi®
Как сделать командные встречи более эффективными? У меня нет одного волшебного рецепта для решения этого комплексного вопроса, но я буду рада поделится с вами набором техник с примерами, которые помогут вам:
Быть лучше подготовленным к встречам;
Фокусировать участников на теме обсуждения;
Уменьшать количество разговоров не относящихся к основной теме дискуссии;
Научить участников быстро принимать решения;
Митигировать конфликтные ситуации;
Описывать механизм реализации договоренностей, принятых на встрече.
Из моего доклады вы узнаете, что такое фасилитации и кто такой фасилитатор, а так же изучите ряд фасилитационных техник, которые применяются для работы с определенными проблемными ситуациями.
2. 2
Agile в Luxoft
23 May 2014
Проекты с 2005 года
15+ заказчиков
90+ текущих проектов
~100 Certified Scrum Masters
~700 Agile практиков
17 внутренних Agile/Lean коучей
Практический опыт в Agile Выделенный центр экспертизы
Старт новых
Agile/Lean проектов
Трансформация
существующих
проектов
Аудит и улучшение
процессов в Agile
проектах
3. 3
В поисках «серебряной пули»
23 May 2014
Agile
предлагает
Приоритизация на
основе ценности
для бизнеса
Оплата только
сделанной и
принятой работы
Бесплатное
управление
изменениями
Полная
прозрачность, демо
в конце коротких
итераций
Проблема
клиента
Запаздывание
необходимой
функциональности
«Изобретение
велосипеда» и
фичи, «готовые на
90%»
Слишком высокая
стоимость даже
небольших
изменений
Неизвестно
реальное
состояние продукта
vs
vs
vs
vs
Never
45%
Rarely
19%
Sometimes
16%
Often
13%
Always
7%
Actual use of requested
features
Источник: The CHAOS Manifesto, The Standish Group, 2011
4. 4
Простые правила
PO
Product Owner
Product
Backlog
(Features)
Sprint
Planning
Part 1
(What?)
2-4 h
Sprint
Planning
Part 2
(How?)
2-4 h
Sprint
Backlog
(Tasks)
Team
SM
Daily Scrum
15 min
Product Backlog
Refinement
5-10% of Sprint
1 Day
2-4 weeks
Sprint
Potentially Shippable
Product Increment
Sprint
Review
2-4 h
Sprint
Retrospective
1,5-3 h
Scrum Master
289 страниц vs 16 страниц
6. 6
Product Owner в идеальном мире
Responsible for maximizing the value of
the product and the work of the
Development Team
Sole person responsible for managing the
Product Backlog
– Power
– Expertise
– Dedication
Does Sprint Planning and PBR with the
Development Team
Tracks total work remaining at least every
Sprint Review
10. 10
Процесс важнее сотрудничества
PO
Product Owner
Product
Backlog
(Features)
Sprint
Planning
Part 1
(What?)
2-4 h
Sprint
Planning
Part 2
(How?)
2-4 h
Sprint
Backlog
(Tasks)
Team
SM
Daily Scrum
15 min
Product Backlog
Refinement
5-10% of Sprint
1 Day
2-4 weeks
Sprint
Potentially Shippable
Product Increment
Sprint
Review
2-4 h
Sprint
Retrospective
1,5-3 h
Scrum Master
PO
Product Owner
Product
Backlog
(Features)
Sprint
Planning
Part 1
(What?)
2-4 h
Sprint
Planning
Part 2
(How?)
2-4 h
Sprint
Backlog
(Tasks)
Team
SM
Daily Scrum
15 min
Product Backlog
Refinement
5-10% of Sprint
1 Day
2-4 weeks
Sprint
Potentially Shippable
Product Increment
Sprint
Review
2-4 h
Sprint
Retrospective
1,5-3 h
Scrum Master
New stories
(no time to
PBR!)
No sprint
commitment! L
13. 13
«Мертвая зона» требований
Разработчики
Какова цель текущего релиза?
Сможем ли мы закончить все,
чего ждут пользователи в
релизе?
Чем заняты другие команды?
Есть ли взаимозависимости на
уровне проекта?
Достаточно ли у аналитиков
требований для следующего
спринта?
Менеджмент
Выпустим ли мы релиз
вовремя?
Какие эпики будут готовы к
релизу и каков их текущий
статус?
Чем занят PO, аналитики?
Блокирует ли что-то их
работу?
Сколько пользовательских
историй готово к следующему
спринту?
Готовы ли мы спланировать
следующий релиз?
15. 15
«Разделяй и властвуй»
Если вы не живете в «идеальном мире» – это нормально!
В сложных проектах PO – организатор, а не эксперт
16. 16
Proxy PO
Proxy PO: полезен или вреден?
Со стороны команды
Часть команды разработки,
разделяет цель спринта
Глубокий анализ бизнес-
требований
Организует анализ бэклога
Отвечает на вопросы
Общается с экспертами в
предметной области
Product Owner
Со стороны бизнеса
Может сам принимать
решения по приоритетам
Приоритизирует бэклог
продукта
Принимает бэклог спринта
Управляет ожиданиями
заказчиков и спонсоров
Дает доступ к экспертам
The Product Owner may do the […], or have the Development Team
do it. However, the Product Owner remains accountable.
(Scrum Guide, July 2013)
17. 17
Не просто “БА на стероидах”
Командный
игрок
Отслеживает
поток
требований
Организует
анализ
бэклога
Фокус на
бизнес-
ценности, не
документах
18. 18
Пример масштабирования
Компания
Топ-10 международный инвестбанк
Бизнес-область
Мидл-офис & бэк-офис & бухгалтерия
Задача
Перевод системы обработки сделок по
торговле акциями с мэйнфрейма на новую
«облачную» платформу для решения ряда
бизнес-проблем
География
EMEA, APAC & North America regions
Команда
13 распределенных команд работают над
одним продуктом
4 команды в Luxoft (30+ человек)
Scrum Mentor
A Team
Sr. Java
Developer/
SCRUM Master
Sr. Java
Developer
BA / pPO
B Team
Sr. Java
Developer
Sr. Java
Developer/
SCRUM Master
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
Sr. Java
Developer
Sr. Java
Developer
Product Owner
Luxoft Onsite
Coordinator
Onshore Team
Onshore Team
Onshore
Sr. Java
Developer/
SCRUM Master
Sr. Java
Developer
Sr. Java
Developer
C Team
QA
Sr. Java
Developer
QA
Sr. Java
Developer
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
QASr. Java
Developer/
SCRUM Master
Sr. Java
Developer
D Team
BA / pPO
Sr. Java
Developer
Sr. Java
Developer
QA
Luxoft Customer
Streams A/B owner
Stream D owner
Stream C owner
Sr. Java
Developer
Single Product
24. 24
Используйте Value Stream Mapping
Request from
business
sponsors
Program
initiation
Project
chartering
Epics
breakdown
User story
drafting
User story
grooming
Ready for
sprint
In
development
Ready for
demo
Ready for
UAT
In UAT
Ready for
release
25. 25
Definition of Done для фаз анализа
23 May 2014
Program
initiation
• PID is shared with
BAs
• Project charter is
drafted and
shared with
business sponsors
and BAs
Project
chartering
• Charter is
approved by
business sponsors
• Final charter is
reviewed with BAs
in a meeting
Epics
breakdown
• Charter
breakdown into
epics is approved
by PO
• All epics are
described in
Confluence with:
• Business context
• Problem
statement
• High-level
acceptance
criteria
• All epics are
presented to the
team(s)
• Epics are included
into backlog and
prioritized
• Business contacts
identified
User story
drafting
• User story is well-
analyzed by BA
and conform to
INVEST criteria
• Detailed BDD
scenarios are
created
• Mockups are
created (where
applicable)
• Data requirements
specified (if any)
• Business logic is
specified (if any)
• US reviewed with
business SME
• Acceptance
criteria are
reviewed by
business SME
• US is prioritized in
backlog and
priority approved
by PO
User story
grooming
• Team reviewed
and agreed that
US conforms to
INVEST criteria
• BDD acceptance
scenarios are well
understood by
team and
approved by
business
• All research
spikes identified
and completed
• US breakdown is
approved by team
(and re-approved
by business if any
changes)
• Business contacts
are shared with
the team
• Design is
approved
DoD for last analysis phase = DoR for sprint
27. 27
Четкие правила PBR
23 May 2014
• Минимум раз в неделю, есть в календаре у PO
• Начинается заранее (минимум за неделю до спринта)
Регулярный
• 15-20 минут на user story
• Если не хватило времени –вопросы/ответы оффлайн и обсуждаем
на следующем PBR
Ограничен по времени
• Все члены команды вопросы до разработки
• Члены команды (не только PO/pPO) объясняют историю, сценарии
и дизайн
Участвует вся команда
• Если артефакт не соответствует DoD, он не идет дальше
Следование DoD
28. 28
Эффективное взаимодействие
Feature Team US 1
Feature Team UA 2Feature Team US 2
Feature Team UA 1
Scrum of Scrums
Scrum of Scrums
Кросс-функциональные
команды
Единый бэклог с едиными
оценками
Один Product Owner
Proxy Product Owners для
каждой локации
Совместное релизное
планирование
32. 32
Story Mapping
Высокоуровневые фичи
Отсортированы с позиции
пользователя
Включают маркировку скиллов
Выполняемые действия
Формируем поток
Приоритизируем по ценности для
бизнеса
36. 36
Результаты
Числа:
– Разные клиенты: от стартапа до топ-10 инвестбанка
– Разные размеры проектов: до 3 команд на одном воркшопе
– Средний цикл: повтор каждые 3-6 месяцев
– Продолжительность: до 2 недель в первый раз, 3-5 дней потом
Достижения:
– Гораздо более открытое общение между PO и разработчиками
– Лучшее понимание бизнес-области, целей и задач проекта
– Более надежное средне- и долгосрочное планирование
– Разработчики вовлечены в создание продукта