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

ANDY@CODESPRINTERS.COM

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

DZIĘKUJĘ ZA

UWAGĘ

Agile Update 2014

36

@krystian_kaczor

krystian.kaczor@codesprinters.com

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