Proces „odciążania” metodologii realizacji oprogramowania w trakcie życia projektu.

1. 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. 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. 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. 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. Model kaskadowy

6. Scrum

7. 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. 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. Oś czasu

10. SCRUM w praktyce • 3 zespoły: • Programiści w Polsce • Fachowość w Niemczech • Programiści w Niemczech • 1 Scrum Master w Polsce • ProductOwner – Gdzieś w Niemczech… • Do każdego User Story przygotowuje się dokument do odbioru

11. SCRUM w praktyce • Długość Sprintu – 3 tygodnie • Realese na życzenie klienta(w przyszłości jeden na kwartał) • UserStories są odbierane przez specjalistów z danego zagadnienia • DailyMeeting są prowadzone przez telefon • PlanningMeeting w formie telekonferencji • Restrospektywa i Review w Niemczech, ale w okrojonym składzie.

12. Zalety • Bliskość klienta • Poczucie wspólnego celu • Dobre rozmieszczenie wiedzy projektowej • Większy potencjał realizacyjny • Transfer wiedzy fachowej

13. Problemy • „Naciągany” Scrum • Brak tablicy Scrumowej • Brak jednoznacznie wyznaczonego ProductOwnera • Restrospektywa i Review przeprowadzane w niepełnym składzie • Zbyt duży zespół • Konieczność podziałów na mniejsze zespoły

14. Problemy(2) • Źle zdefiniowane kryteria akceptacji • UserStories 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. 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. 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. 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. Prezentacja narzędzi • Bugzilla • JIRA

19. Koniec Dziękuję za uwagę! Q&A?