Proces „odciążania” metodologii realizacji

oprogramowania w trakcie życia projektu.

Zmiana sposobu realizacji oprogramowania z metodologii ciężkiej na zwinną(SCRUM)

Adrian Popiel – W8

2/19

Projekt

• Kontrolowanie procesu zamawiania samochodów dla:– Klientów biznesowych(Direktkunden):

• Zakup• Wypożyczenie

– Pracowników(Mitarbeiter)• Leasing• Zakup

– Pozostałych klientów(samochody funkcyjne i służbowe).

3/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

4/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

5/19

Model kaskadowy

6/19

Scrum

7/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

8/19

Dlaczego transformacja?(2)

• Zdecydowano na połączenie obu modeli

• W związku z życzeniem klienta i nową linią firmy wszystkie operacje z tym związane, a w konsekwencji cały projekt miały być realizowane w metodologii zwinnej (SCRUM)

9/19

Oś czasu

10/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

11/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.

12/19

Zalety

• Bliskość klienta• Poczucie wspólnego celu• Dobre rozmieszczenie wiedzy

projektowej• Większy potencjał realizacyjny• Transfer wiedzy fachowej

13/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

14/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

15/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

16/19

Potencjalne rozwiązania problemów(2)• Rezygnacja z dokumentacji• Wybranie jednego PO• Wcześniejsze odbiory User Story• Spotkania ze specjalistami podczas

realizacji(np. po 40%)• Rotacja pomiędzy zespołami• Większa ilość pracowników podczas

spotkań• Klient przyjeżdża do Polski

17/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ć?

18/19

Prezentacja narzędzi

• Bugzilla• JIRA

19/19

Koniec

Dziękuję za uwagę! Q&A?