prezentacje z agile update listopad 2014
DESCRIPTION
Prezentacje z konferencji Agile Update z listopada 2014.TRANSCRIPT
SKALOWANIE
ANDY BRANDT
PL 4
AU
CO TO JEST
SKALOWANIE AGILE?
• ZWINNOŚĆ (ANG. AGILITY) – ZDOLNOŚĆ DO SZYBKIEJ LECZ
PRZEMYŚLANEJ ZMIANY
• POLEGA NA DOSTOSOWANIU PRODUKTU [INFORMATYCZNEGO] DO
ZMIENIAJĄCYCH SIĘ WYMAGAŃ BEZ OBNIŻANIA JEGO JAKOŚCI
• DOŚWIADCZENIE POKAZAŁO JUŻ, ŻE ZESPOŁY SCRUM SĄ BARDZO
WYDAJNE PRZY BUDOWANIU PRODUKTÓW, SCRUM JEST JEDNAK
MODELEM DLA JEDNEGO MAŁEGO ZESPOŁU
• SKALOWANIE TO ROZWIĄZANIE PROBLEMU – JAK UTRZYMAĆ
ZWINNOŚĆ I INNE KORZYŚCI SCRUM (I INNYCH METOD AGILE) PRZY
WIELU ZESPOŁACH
WYMIARY SKALOWANIA
1
2
3
4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
MAŁE SKALOWANIE
• Do ~55 osób, 4-6
teamów max.
• Wiele problemów
można nadal
rozwiązać
spotykając się całą
grupą
• Wystarcza jeden
backlog i jeden PO
DUŻE SKALOWANIE
• Więcej osób, wiele
teamów
• Konieczne jakieś
dzielnie produktu na
moduły/obszary
• Nie wystarcza jeden
PO
Wymagania Komunikacja Produkt
ZESPÓŁ
1
ZESPÓŁ
2
ZESPÓŁ
3
ZESPÓŁ
4
Produkt
Efsdfsdfsdfs
Sdfsdfsdfsdfs
SfsdfsdfsFsdfsdfsadfsadfsa
Fsadfasfsadfasdfasd
Sadfsadfasdfasdfasdfsadfsad
Safdsadfsadfsadvadf savaf asd asdvc asdvc dsfv
Sdf vsdfv dsfv sdf vasf
Asv asdf sadf asdfdsafd
V adfv adfvfdv sdfv dfv f aadfv dfv dafv dfavadfv
asdfa sdfsaf asdf asdf asdf
adfasdfsadfsadf saf
Wymagania Komunikacja Produkt
1
2
3Moduł 1
EfsdfsdfsdfsSdfsdfsdfsdfsSfsdfsdfsFsdfsdfsadfsadfsaFsadfasfsadfasdfasdSadfsadfasdfasdfasdfsadfsadSafdsadfsadfsadvadf savaf asd asdvc asdvc dsfv
Sdf vsdfv dsfv sdf vasf Asv asdf sadf asdfdsafd V adfv adfvfdv sdfv dfv f aadfv dfv dafv dfavadfv asdfa sdfsaf asdf asdf asdf
saf
Moduł 2
EfsdfsdfsdfsSdfsdfsdfsdfsSfsdfsdfsFsdfsdfsadfsadfsaFsadfasfsadfasdfasdSadfsadfasdfasdfasdfsadfsadSafdsadfsadfsadvadf savaf asd asdvc asdvc dsfv
Sdf vsdfv dsfv sdf vasf Asv asdf sadf asdfdsafd V adfv adfvfdv sdfv dfv f aadfv dfv dafv dfavadfv asdfa sdfsaf asdf asdf asdf adfasdfsadfsadf saf
DIABEŁ TKWI W
WYMAGANIACH
PRODUKT4
1
2
3
4
DWA ROZWIĄZANIA DLA
„DUŻEGO SKALOWANIA”W zarządzaniu
wymaganiami
AUTONOMIA
HIERARCHIA
ZESTAWIENIE
HIERARCHIA
• MONOLITYCZNY PRODUKT
(DUŻO ZALEŻNOŚCI)
• DE FACTO OGRANICZONE
MOŻLIWOŚCI PO PRZY TEAMACH
• ZWYKLE TRUDNOŚĆ W
CZĘSTYM WYDAWANIU PRODUKTU
(TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTÓW)
• DLA WIELU ORGANIZACJI TO
NIESTETY JEDYNA MOŻLIWOŚĆ
AUTONOMIA
• MODULARNA ARCHITEKTURA
PRODUKTU
• ZESPOŁY ODPOWIEDZIALNE ZA
OBSZARY FUNKCJONALNE, NIE
KOMPONENTY TECHNOLOGICZNE
• POS WYSTARCZĄ OGÓLNE
UZGODNIENIA CO DO KIERUNKU ROZWOJU
• MODUŁY WYDAWANE NIEZALEŻNIE
• WYMAGA NIE TYLKO ODPOWIEDNIEJ
ARCHITEKTURY PRODUKTU ALE I
ORGANIZACJI.
RECEPTY NA
SKALOWANIE?
• LARGE SCALE SCRUM (LESS) BY CRAIG LARMAN AND BAS VODDE –
HTTP://WWW.CROSSTALKONLINE.ORG/STORAGE/ISSUE-
ARCHIVES/2013/201305/201305-LARMAN.PDF
• SCALED AGILE FRAMEWORK (SAFE) BY DEAN LEFFINGWELL -
HTTP://SCALEDAGILEFRAMEWORK.COM
• SCRUM AT SCALE – MODUŁOWA METODA SKALOWANIA JEFFA
SUTHERLANDA - HTTP://WWW.SCRUMINC.COM/SCRUM-AT-SCALE-
PART-I/
LESS
SCRUM AT SCALE
RECEPTY IDĄ
W DWIE STRONY
Empiryzm
NIM ZAPYTASZ
„CO WYBRAĆ”?
• PO CO CHCECIE WPROWADZAĆ METODY AGILE NA DUŻĄ SKALĘ W
FIRMIE/PROJEKCIE/DZIALE/ETC.?
• JAKI JEST STAN WYJŚCIOWY?
• KSZTAŁT PRODUKTU – ARCHITEKTURA, STAN KODU
• MOŻLIWOŚCI ZESPOŁÓW
• OBECNE STRUKTURY I KULTURA ORGANIZACJI
• CZY JUŻ WYKORZYSTANO ISTNIEJĄCE REZERWY USPRAWNIEŃ W
JEDNYM ZESPOLE?
• POZIOM ODWAGI – LUB KONIECZNOŚCI
O CZYM NALEŻY
PAMIĘTAĆ
• WSZYSTKIE METODY I PRAKTYKI ZWINNE SĄ ZASTOSOWANIEM
EMPIRYZMU DO TWORZENIA OPROGRAMOWANIA
• EMPIRYZM NIE MOŻE BYĆ Z GÓRY ZAPLANOWANY – TO
PRZECIWIEŃSTWO PODEJŚCIA PREDYKCYJNEGO
• ZMIANY PROCESU I KULTURY NIE DA SIĘ DO KOŃCA NARZUCIĆ ODGÓRNIE
• PROCES EMPIRYCZNY NIE MA STANU KOŃCOWEGO
• KAŻDA METODA JEST KROKIEM KU DALSZEMU ROZWOJOWI
• SAM PROCES NA POZIOMIE STRUKTURY I ZARZĄDZANIA NIE WYSTARCZY, NIEZBĘDNE SĄ ODPOWIEDNIE PRAKTYKI TECHNICZNE
CZY WARTO SIĘGAĆ
PO POMOC?
• KONSULTANCI I COACHE PRZYNOSZĄ:
• ZEWNĘTRZNE SPOJRZENIE NA WASZE PROBLEMY
• WIEDZĘ O ISTNIEJĄCYCH METODACH I PRAKTYKACH
• DOŚWIADCZENIE
• OPARTE NA NIM PRZEKONANIE, ŻE MOŻNA („DA SIĘ”)
• CHYBA WARTO
DZĘKUJĘ
SKALOWANIE
PROCESÓW
DOSTĘPNE ROZWIĄZANIA
Agile Update 2014
20
AGENDA
• ORGANIZACJA ZESPOŁÓW
• ZARZĄDZANIE WYMAGANIAMI I ARCHITEKTURĄ
• KTÓRĄ DROGĘ WYBIERZESZ?
Agile Update 2014
21
NIE MA NIC LEPSZEGO
NIŻ ZESPÓŁ AGILE
• MAŁY
• SAMO-OGRANIZUJĄCY SIĘ
• WSKROŚ-FUNKCJONALNY
• ZESPÓŁ PROFESJONALISTÓW
• DOSTARCZA WARTOŚĆ POPRZEZ REALIZOWANIE USER STORY
• ZORIENTOWANY NA OSIĄGANIE CELÓW I REALIZOWANIE WIZJI
PRODUKTU
Agile Update 2014
22
SZYBSZY ZYSK I
KRÓTSZY TIME TO
MARKET
CZAS
DO
ST
AR
CZ
AN
IE W
AR
TO
ŚC
I
Agile Update 2014
23
ALE JAK TO ZROBIĆ W
DUŻEJ ORGANIZACJI?
Agile Update 2014
24
?
ORGANIZACJA
ZESPOŁÓW
25
Agile Update 2014
ZSYNCHRONIZUJ
ZESPOŁY
Agile Update 2014
26
Release on Demand
Major
ReleaseCustomer
Upgrade
Customer
Preview
Major
Release New
Feature
Develop on Cadence
PI PI PI PI PI
SKORZYSTAJ ZE SCRUM
+ XP
Agile Update 2014
27
Agile
Architecture
Continuous
Integration
Test-First
Refactoring
Pair Work
Collective
Ownership
ZOPTYMALIZUJ CAŁOŚĆ
Agile Update 2014
28
“System musi być zarządzany.
Nie będzie się sam zarządzał.
Komponenty pozostawione same
sobie, staną się samolubnymi,
konkurencyjnymi, niezależnymi
centrami zysku, i w dlatego zniszczą
system. […]
Sekretem jest współpraca pomiędzy
komponentami skupiona na celu
organizacji.”
—W. Edwards Deming
OPTYMALIZUJ NA
PROGRAM
• SAMO-ORGANIZUJĄCY SIĘ ZESPÓŁ ZESPOŁÓW
• SPRINTY 2 TYGODNIOWE
• WSPÓLNE PLANOWANIE WYDANIA I SZACOWANIE
• ŚLEDZI ZALEŻNOŚCI NA PROGRAM BOARD
• SCRUM OF SCRUMS
• RTE + PRODUCT MANAGEMENT + SYSTEM TEAM + SYSTEM ARCHITECT + DEVOPS + UX
• DOSTARCZA FUNKCJONALNOŚCI ZE WSPÓLNEGO BACKLOGU
Agile Update 2014
29
ZARZĄDZANIE
WYMAGANIAMI I
ARCHITEKTURĄ
30
Agile Update 2014
AGILE PORTFOLIO
• SCENTRALIZOWANA STRATEGIA
• OBIEKTYWNE METRYKI WSPIERAJĄ ZARZĄDZANIE I KAIZEN
• BUDŻETOWANIE AGILE-LEAN
• ARCHITEKTURA ENTERPRISE JEST WBUDOWANA
• KANBAN OBRAZUJE PRACĘ NAD POTFOLIO
• SKUPIENIE NA EPIKACH BIZNESOWYCH I ARCHITEKRURY WYNIKAJĄCYCH Z
CELÓW STRATEGICZNYCH ORGANIZACJI
Agile Update 2014
31
SKALOWANE
WYMAGANIA
Agile Update 2014
32
WYBÓR
DROGI
33
Agile Update 2014
CO WYBIERASZ?
NAUKA NA BŁĘDACH I
EKSPERYMENTOWANIE
(2-5 LAT)
Agile Update 2014
34
• Stwórz Backlog
• Zbuduj Zespoły
• Przeszkol organizację
• Wystartuj pierwszy pociąg
SPRAWDZONE
ROZWIĄZANIE
(MIESIĄC?)
Agile Update 2014
35
Skalowanie metodyk Agile(Techniki inżynieryjne)
Remigiusz Dudek
Fundament
Zintegrowane środowisko
programistyczne (IDE)
Repozytorium kodu (zależności)
Serwer ciągłej integracji
Filary jakości w Agile
Szybsze dostarczanie wartości biznesowej – Testy regresji (100% logiki biznesowej)
Szybka identyfikacja defektu (jeszcze na etapie programowania)
Precyzyjna identyfikacja defektu (z dokładnością do biznesowej odpowiedzialności
klasy)
Bezpieczniejszy refactoring kodu
mając opisane odpowiedzialności biznesowe możemy je świadomie zmienić
Bezpieczeństwo zmian
Zdobycie czasu na testy eksploracyjne
Cel
Test Driven Development
Testy pisane przed kodem
produkcyjnym
Testy pisane z perspektywy
biznesowej
Miara pokrycia kodu testami
Jak osiągnąć cel?
Testy jednostkowe
Szybsze dostarczanie wartości biznesowej
Posiadanie zawsze-aktualnej dokumentacji biznesowej
Większa elastyczność w zarządzaniu projektem
Stworzenie zespołów cross-feature
Skrócenie okresu “wejścia do projektu”
Macierz pokrycia wymagań
Testy regresji (główne ścieżki)
Cel
Zautomatyzowane testy akceptacyjne
“Specyfikacja poprzez
przykłady”
BDD Framework (JBehave,
SPOCK)
Jak osiągnąć cel?
Continuum testów (od testów
automatyzowalnych do eksploracyjnych)
“Nauka domeny, projektowanie i
wykonywanie testów oraz analiza ich
wyników jednocześnie”
Analogia
–Spacer po parku
–Przedzieranie się przez dżunglę
Testy eksploracyjne - Wprowadzenie
Zmniejszenie liczby defektów
produkcyjnych
Przetestowanie biznesowych
przypadków brzegowych
Walidacja modelu biznesowego wg.
którego działa aplikacja
Wsparcie dla innowacji w testowaniu
Cel
Uczyć się biznesu by identyfikować biznesowe przypadki
brzegowe
Uczyć się krytycznego myślenia
Debug
Jak osiągnąć cel?
Testy eksploracyjne
14-11-3
Testy nie-funkcjonalne
Uniknięcie „sprintów stabilizacyjnych”
Rozszerzenie horyzontów ludzi biznesu
o aspekty nie-funkcjonalne
Cel
Metoda perspektyw
CUPRIMDSO
FURPS
Cykliczna walidacja
Jak osiągnąć cel?
14-11-3
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Thank you
Remigiusz Dudek