itkaizenclub: масштабування за допомогою safe: міф чи...
TRANSCRIPT
Масштабування за допомогою SAFe: міф чи реальність?
Before starting
• #ITKaiZenClub• @E5Trainings• WiFi Digital-Future
Guest
Декілька слів про нас
Prykhnych HelenCo-founder & trainer @ E5
IC Agile certified professional
Roman SakharovBusiness Analysis Team Leader &
Project manager @ EPAM Systems, CSM & Trainer
Ми консалтинго-тренінгова компанія Консультуємо компанії на тему
налаштування процесу розробки Допомагаємо підняти рівень ІТ спеціалістів Створюємо тренінги, воркшопи та вебінари Проводимо зустрічі ITKaizenClub Виступаємо на конференціях
SAFe: погляд з висоти
CASE #1
Чому маштабуватися?Складний продуктІТ команда 50 – 100 чоловікРозвиток функціоналу і потреба в
маштабуванні архітектуриНеобхідність регулярних релізів
Наші передумовиВиділений реліз менеджер (RTE)Команда архітекторів Сильний лідерський складSCRUM командиВиділена DevOps команда
TOP 5 причин для успішного маштабування AGILE по версії VersionOne
Рівень портфоліо
Architectural
features
Business features
Portfolio Backlog
Business Owners
Head of IT Development
Portfolio management
Strategic Themes
Рівень релізу
3 релізи в одиночас
Deliver Develop Plan
Deliver Develop Plan
Deliver Develop Plan
Test Pack UATS2Kanban + UAT S3
Pack & Deliver
Portfolio meeting EG1 EG2 Planning
Agile Release Train
Go
Live
Code
Fre
eze
S1
Com
mitm
ent
Release Train Engineer
Product Owner
Vision
ReleaseGoals Architectural Runway
Featureroadmap
А до чого тут потяг?
Release scope
Планування релізу
Матриця залежностей
Випуск релізу
Рівень команди
2 weeks sprint
Team
Product Owner Scrum
master
Sprint backlog
Sprint Planning
Daily Stand up
Sprint DemoRetrospective
Epic grooming
Storygrooming
Маштабування організаційної структури
RTE DevOps LeadHead of IT DevelopmentCPO
PO 1
PO 2
PO N
SM 1
SM 2
SM N
TL 1
TL 1
TL N
QA Lead
Sen QA 1
Sen QA 2
Sen QA N
DevOps 1
DevOps 2
DevOps N
Arch 1
Arch 2
Arch N
… … … … … …
TEAM 1
TEAM 2
TEAM N
Плюси та мінуси SAFe на нашому проекті
ПлюсиМаштабування 8+ Agile команд
Синхронізація Прорітезація нових фіч і архітектурних задач на рівні портфоліо
Синхронізація роботи між командами на рівні релізу
Релізи Інкрементальні релізи кожні 4 ітерації
Можливість швидко випускати маленькі патчі
Управління ризиками Управління ризиками і залежностями на ранніх стадіях
Якість Контроль якості на всіх рівнях Управління технічним боргом
Продуктивність Фокус для кожного релізу Повна загрузка девелопменту
МінусиРеліз процес ‒ Довгий Lead time
‒ Довгий процес випуску на Production
Якість ‒ Виривання QA з спрінта для регресії
Продуктивність ‒ Затягування грумінгів через сирі вимоги
‒ Застрявання незакінчених фіч при постійній зміні бізнес пріорітетів
Підтримка процесу ‒ Додаткові ролі і ритуали для підтримання процесу
Чи є альтернатива?
Статистика за 2014 рік від VersionOne
CASE #2
WHY SCALING AGILE?
38
Agile і Scrum виросли• Scrum довів скою користь• Великі компанії використовують
Agile і Scrum• Але великі продукти не можуть
обійтись Vanilla Scrum
40
НАС ЦЕ ТЕЖ НЕ ОМИНУЛО
Business Process Work Management
•BP Case Library•Productivity
Enterprise Case Management
•Escalation•PrioritisationWork Management
•Advanced Routing•Escalation and PrioritisationRules and Workflow
•SWIFT•E-mail/Web access
Automated Correspondence
•Log every user and system actionAudit trails
42
ЯК МИ ПОЧИНАЛИ?
Команда– 3 cross-functional, co-located команди у (Kyiv, Ukraine)– Тісна робота з PO (Zurich, Central European Time)
Scrum Pulse
• 2-тижневі спринти• Планування спринту• Щоденний Standup• Sprint Review
щотижня• Спринт
ретроспектива• Backlog Grooming• Зустрічі для
вирішення проблем
45
УСПІХ!
46
ПОПИТ
Нові виклики і вирішення
Багато замовлень
від замовників
Замовники змагаються за команду
Один проект і команди
Жахи пріоретиза
ції
Декілька «потоків» роботи
48
Кожен потік відповідає за свій бізнес процес
Кожен департамент має свій потік
Кожен потік має свій бюджет
Потоки стали проблемою
Не прозора кількість роботи по кожному напрямку
Немає пріоритизації між стейкхолдерами
Хаотичне вдосконалення процесу
Команди не розуміють хто чим займається
49
ЯК МИ ПОЧИНАЛИ?
Areas of Improvement Identified
Scaled events Scaled artifacts Flow of requirements
Role of BA/POOperations and
support acceptance procedures
Capacity allocation and planning
Scaled Events
Спільне планування для команд
General PBR meetings
Глобальні ретроспективи
Cross team competency meeting
Scaled Artifacts
General backlog for all streams Rally used for EPICs, Features and User Stories
Populated by Product Owner of each business processPriorities by Chef Product Owner before PBR
Knowledge base
Structure by competencies, which is up-to-dated by
– component guardians,
– managers,
– BAs and other knowledge holders
Process descriptions on Confluence
Global Retro-points list
Summarized list from all the teams to be discussed on Global retrospective meetings
PBR
Planning
Team SupportDemo
Acceptance
Backlog update
Requirements flow and work with teams
POBA
Planning in 3 parts
– 1st for POs only
– Standard Scrum Planning• 1st Part with PO
• 2nd with the team creating tasks decomposition
Each PO has a % budget for his direction
% of budget is % of development teams velocity
Capacity Allocation and Planning
Previous release
Virtual Team
Kanban Board Tracked in Rally
Production support
It appeared to be LeSS
2 фреймворки
• LeSS: Up to eight teams (of eight people each).• LeSS Huge: Up to a few thousand people on
one product.
Структура
Корисні посилання SAFe (Scaled Agile Framework)
http://www.scaledagileframework.com
DAD (Disciplined Agile Delivery)https://disciplinedagiledelivery.wordpress.com/introduction-to-dad/
LeSS (Large-Scale Scrum)http://less.works
_______________________________________________________ Version One Agile reporthttp://info.versionone.com/state-of-agile-development-survey-ninth.html
Coming soon
Workshop «Управління вимогами в Agile проектах: від ідеї до працюючого продукту» 20 червня
Odessa Innovation Week 2-10 липня Карпати.РМ – 2015 26-28 червня
Знижка 15% Workshop «Управління вимогами в Agile проектах: від ідеї до працюючого продукту»
20 червня за промо-кодом ITKaiZenClubПро-код діє до 14.06.2015
