Transcript Scrum

Proces „odciążania”
metodologii realizacji
oprogramowania w trakcie
życia projektu.
Zmiana sposobu realizacji oprogramowania z metodologii
ciężkiej na zwinną(SCRUM)
Adrian Popiel – W8
Projekt
• Kontrolowanie
procesu
samochodów dla:
zamawiania
– Klientów biznesowych(Direktkunden):
• Zakup
• Wypożyczenie
– Pracowników(Mitarbeiter)
• Leasing
• Zakup
– Pozostałych klientów(samochody funkcyjne i
służbowe).
2/19
Projekt(2)
• U klienta funkcjonuje stary system
napisany w Cobolu.
• W założeniach nowa wersja miała:
– Realizować funkcjonalności starego systemu
– Oferować nowe możliwości
– W konsekwencji wyprzeć poprzednika
3/19
Osoby w projekcie
• PM – Project Manager – 1 os. w Niemczech
• PL – Project Leader – 1 os. w Niemczech
• TPL – Technical Project Leader – 1 os. w
Polsce
• TCD – Technischer Chief Designer – 2 os.
po jednej w Polsce i Niemczech
• FCD – Fächlicher Chief Designer – 1 os. w
Niemczech
• Programiści – 10-20 osób w Polsce
4/19
Model kaskadowy
5/19
Scrum
6/19
Dlaczego transformacja?
• Klient nie chciał rezygnować od razu ze
starego systemu.
• Ze względu na technologie zdecydowano,
że stary system dopasuje swój model
danych
• Operacja ta miała trwać trzy tygodnie
• Po trzech miesiącach okazało się to
niemożliwe/nieopłacalne
7/19
Dlaczego transformacja?(2)
• Zdecydowano na połączenie obu
• W związku z życzeniem klienta i
firmy wszystkie operacje z tym
a w konsekwencji cały projekt
realizowane w metodologii
(SCRUM)
modeli
nową linią
związane,
miały być
zwinnej
8/19
Oś czasu
9/19
SCRUM w praktyce
• 3 zespoły:
– Programiści w Polsce
– Fachowość w Niemczech
– Programiści w Niemczech
• 1 Scrum Master w Polsce
• Product Owner – Gdzieś w Niemczech…
• Do każdego User Story przygotowuje się
dokument do odbioru
10/19
SCRUM w praktyce
• Długość Sprintu – 3 tygodnie
• Realese na życzenie klienta(w przyszłości
jeden na kwartał)
• User Stories są odbierane przez
specjalistów z danego zagadnienia
• Daily Meeting są prowadzone przez telefon
• Planning Meeting w formie telekonferencji
• Restrospektywa i Review w Niemczech, ale
w okrojonym składzie.
11/19
Zalety
•
•
•
•
•
Bliskość klienta
Poczucie wspólnego celu
Dobre rozmieszczenie wiedzy projektowej
Większy potencjał realizacyjny
Transfer wiedzy fachowej
12/19
Problemy
• „Naciągany” Scrum
• Brak tablicy Scrumowej
• Brak jednoznacznie wyznaczonego Product
Ownera
• Restrospektywa i Review przeprowadzane
w niepełnym składzie
• Zbyt duży zespół
• Konieczność podziałów na mniejsze
zespoły
13/19
Problemy(2)
• Źle zdefiniowane kryteria akceptacji
• User Stories są odbierane za późno(czasem
nawet po instalacji na produkcji!)
• Klient
wszystkie
spotkania
chce
przeprowadzać u siebie
• Klient często nie ma czasu, nawet podczas
odwiedzin zespołu realizującego
• Brak macierzy odpowiedzialności
• Nieaktualna dokumentacja
14/19
Potencjalne rozwiązania problemów
• Specjalistyczne narzędzia dla SCRUM’a
• Opracowanie długofalowej perspektywy
rozwoju systemu
• Przygotowanie DoR dla User Story:
–
–
–
–
–
Scenariusz
Strona techniczna
Potencjalne CR
Fachowość
Opis funkcjonalności
15/19
Potencjalne rozwiązania
problemów(2)
•
•
•
•
Rezygnacja z dokumentacji
Wybranie jednego PO
Wcześniejsze odbiory User Story
Spotkania
ze
specjalistami
realizacji(np. po 40%)
• Rotacja pomiędzy zespołami
• Większa ilość pracowników
spotkań
• Klient przyjeżdża do Polski
podczas
podczas
16/19
Ciekawe problemy w praktyce
• Ważna osoba odchodzi z projektu
• Zmiana Scrum Mastera – samoorganizujący
się zespół
• Scrum Master mi pomoże! Prawda?
• Gdzie trzymać dokumentację?
• Jak prowadzić Product/Sprint Backlog?
• Jakich narzędzi używać?
17/19
Prezentacja narzędzi
• Bugzilla
• JIRA
18/19
Koniec
Dziękuję za uwagę!
Q&A?
19/19