Czy w dużym projekcie można być Agile? – business case SKOK Ubezpieczenia
•
0 likes•750 views
Łukasz Ostaniewicz - Goyello - Czy w dużym projekcie można być Agile? – business case SKOK Ubezpieczenia
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Czy w dużym projekcie można być Agile? – business case SKOK Ubezpieczenia
Similar to Czy w dużym projekcie można być Agile? – business case SKOK Ubezpieczenia (20)
More from 3camp
More from 3camp (20)
Czy w dużym projekcie można być Agile? – business case SKOK Ubezpieczenia
- 1. Czy w dużym projekcie można być Agile ? Łukasz Ostaniewicz business case SKOK Ubezpieczenia
- 2. Agenda 1 Wyzwanie co było do zrobienia Agile i Scrum - odrobina teorii Jak zorganizować „Scrum Team” 2 Jak 1 PO może „nakarmić” 9 developerów 3 Jak opisywać wymagania i jak je szacować 4 Jak developer może wpływać na proces 5 Jak zagwarantować wysoką jakość 6 Jak być efektywnym Scrum Masterem Praktyczne wskazówki:
- 3. Wyzwanie – co było do zrobienia Klient Call Center Placówka medyczna Sprzedaż ubezpieczeń Kontraktowanie Umawianie Wizyty Rozliczanie
- 4. Agile i Scrum – odrobina teorii • Agile • Scrum Planowanie Realizacja Ocena iteracje
- 5. Jak zorganizować „Scrum Team” Product Owner Proxy Product Owner Developerzy Scrum Master Otoczenie Eksperci Domenowi 1
- 6. Jak 1 Product Owner może „nakarmić” 9 developerów zaangażowanie Klienta w pracę nad wymaganiami zaangażowanie Developerów w pracę nad wymaganiami 2
- 7. Jak opisywać wymagania i jak je szacować User Stories Jako pracownik SKOK Ubezpieczenia mogę określić kolejność placówek medycznych podpowiadanych pacjentowi zamawiającemu wizytę (dzięki czemu pacjentowi będą podpowiadane w pierwszej kolejności placówki świadczące usługi najwyższej jakości). Szacowanie Godziny Rozmiary (S, M, L, XL) Story Points 3
- 8. Jak Developer może wpływać na proces Retrospektywa 3 rzeczy, które były zrealizowane dobrze. 3 rzeczy, które mogły być wykonane lepiej 4
- 9. Jak zagwarantować jakość kodu • CI • Team code review • Architecture review • Audyt bezpieczeństwa • Testy jednostkowe • Testy automatyczne (Sahi) • Szkolenia wewnętrzne (zewn./prod.) 5
- 10. Jak być efektywnym Scrum Masterem • „Servant leadership” • organizowanie spotkań • efektywne rozwiązywanie problemów zespołu 6
- 11. Podsumowanie 1 Product Owner Proxy 2 Zaangażowanie klienta 3 Story Point - lepsze od godzin 4 3 „rzeczy”, które mogły być wykonane lepiej 5 Dobre praktyki wpływające na jakość 6 Scrum Master - „servant leadership”
- 12. Pytania?
Editor's Notes
- Centralna baza oraz 8 modułów dla różnych grup użytkowników (pracownicy SKOK Ubezpieczenia, dostawcy usług medycznych, placówki medyczne, klienci).Warsztaty , 1 wszadecyzjana NIE
- Agile - grupa metodyk wytwarzania oprogramowania oparta na modelu iteracyjnymDlaczego Agile:Projekt nowatorski, wizja się będzie zmieniała.SKOKUbezpieczenia – chęć wypróbowania czegoś nowego.ManifestLudzie i interakcje ponad procesy i narzędziaDziałające oprogramowanie ponad obszerną dokumentacjęWspółpraca z Klientem ponad formalne ustaleniaReagowanie na zmiany ponad podążanie za planemScrum - metodologia iteracyjna zgodna z manifestem Agile
- Scrum Master – zapewnia, że Scrum jest zrozumiały i egzekwowany.Coaching in self organisation.Usuwanie przeszkód, problemów.Product Owner – zarządza product backlog . Maksymalizuje wartość dodaną klie końcowego klienta.Priorytetyzuje tematy. Zespół ma pewność , że zawsze pracuje nad tematami najważniejszymi.Dostarcza wiedzę do zespołu developerskiego.Product Owner Proxy - Gdy Product owner nie ma „czasu”, „możliwości” , często deleguje swoje uprawniania Product Owner Proxy.Tu wspólna praca nad backlogiem i przekazywanie wiedzy do zespołu developerskiego.Developerszy - Specjaliści od programowania, również od testów, od db.Otoczenie - design, bezpieczeństwo, architektura, system admin.
- Problem: Developerzy przed rozpoczęciem kodowania oczekują dokumentów projektowych, analitycznych. np.mockupy (projekt interfejsu użytkownika), szczegółowy flow, opis wymagalności pól.Sytuacja: brak spisanych ustaleń.nieefektywne spotkania w dużym gronie.Zaangażowanie developerów poprzez udział w spotkaniach, dokumentowanie ustaleń.Nie zadziałało: a) rozbity focus, uczestnictwo w spotkaniach = spadek wydajności. B) „wątpliwa” jakość tworzonych dokumentów. C) Mala motywacjaZaangażowanie klienta:Planowanie iteracji: Aktywne słuchanie i dodawanie komentarzy do US. Formułowanie testów.Identyfikowanie „epików”.Praca nad wymaganiami (zidentyfikowanymi „epikami”) po stronie SKOK Ubezpieczenia.Aktywna współpraca Product Owner, Product Owner Proxy
- Historyjki:Kto co i dlaczego-Stos krótkie.-Opisują wartość biznesową możliwą do zaimplementowania w ciągu tygodnia.-Zrozumiałe dla developerów i dla klienta i dla innych stron (bez dodatkowego komentarza).-Wymagają niewielkiego utrzymania.-Bardzo dobrze nadają się do projektów w których początkowo wiedza na temat szczegółów wymagań jest niewielka.Szacowaniew godzinach . magiczny mnożnikzłożoność + na podstawie danych historycznych ustalamy czas niezbędny na realizację.rózne sposoby złożoności: ilość interfejsów, komponentów, operacji na danych. Można też SP.S, M, L - jakie wadyhisoryjka na 9 SP o ile jest większa od historyjki oszacowanej na 8 SPbo błędy szacowania uśrednią się po całym zakresie prac. Innymi słowy mimo, że część Historyjek nie doszacujemy a część przeszacujemy, to nasze estymaty i tak będą wystarczająco dokładne. Dodatkowo Historyjki z największymi wartościami (20, 40 i 100) będziemy w trakcie trwania projektu rozbijać na mniejsze, uzyskując tym samym dokładniejsze szacunki.
- Przeważnie problemy/pomysły na ich rozwiązanie pojawiają się w trakcie daily meetings.Przykłady.Poprawiła się komunikacja.problem techniczny w aplikacji.Osoba niezastąpiona.Cel iteracji nie był znany.
- CI – frequent deliveryCzestosprawdzackompatypilnoscwsteczCzestewydania
- Służebne przywództwo advisory role rather than executiveProblem: nie mamy wiedzy. Nie mamy licencji. Nie mamy wiedzy.