1 / 19

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

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 zamawiania samochodów dla: Klientów biznesowych( Direktkunden ): Zakup

lundy
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related