Zarządzanie projektami metodyki, narzędzia, zalety Developer w Młynie

1. Zarządzanie projektami metodyki, narzędzia, zaletyDeveloper w Młynie Marcin Kania

2. O mnie • na rynku od 10lat • programista, analityk, kierownik projektu • MCTS, Prince2, IPMA, ITIL, • od 5 lat zajmuje się projektami IT • ostatnio 4 lata w Barlinek, • aktualnie pm w firmie Noox Technologies

3. o tej prezentacji • Skąd pomysł? Źródła: • Zaawansowane zarzadzanie projektami J.Betta • AgileDeveloperB.Pampuch • Korzyść – co ja z tego będę miał ? • Narzędzia (zawsze proste) są tylko elementem do osiągnięcia celu

4. Metodyki • Tradycyjne: PMI(USA) Prince2(GB) IPMA(Germanie) • Zwinne: • Agile/Scrum, XP, RAD,…

5. Skoro jest tak dobrze to czemu jest tak …? • W USA prawie 70% projektów kończy się porażką, a co piąty jest kompletną katastrofą. • W polskich firmach – tylko 21 % projektów uznaje się za sukces. • Połowa projektów przekracza swój budżet (średnio o 1/3), a 61% przekracza termin (średnio o 2/3).

6. Plan prezentacji – Product Backlog

7. Zarządzanie po staremu • Pracownicy się op… leniwią i nie dbają o jakość, • Żaden pracownik nie chce usprawnić swojego procesu pracy, tym zajmują się eksperci/architekci/analitycy, • Pracownika trzeba cały czas kontrolować, bez tego nie ma wydajności,

8. Zarządzanie w Toyocie(TaiichiOhno) • Ciągłe doskonalenie pracowników – szanuj ich i wyzwól potencjał • Szczupłe procesy (KAIZEN) • Brak marnotrawstwa(MUDA) • Zarządzanie zmianą – zmiana idzie od dołu(pracownika)

9. Manifest Agile • Ludzie i interakcje ponad procesy i narzędzia. • Działające oprogramowanie ponad obszerną dokumentację. • Współpracę z klientem ponad formalne ustalenia. • Reagowanie na zmiany ponad podążanie za planem.

10. Co wynika z manifestu?(klient) • Potrzeby (funkcjonalności/procesy) klienta mogą się zmieniać • Klient na początku może nie wiedzieć wszystkiego • Klient przyjmuje do wiadomości że zakres/koszty mogą się zmienić • Klient zobaczy wartość dodaną w kolejnych krótkich iteracjach

11. Co wynika z manifestu?(zespół) • Zespół jest najważniejszy - to są ludzie zmotywowani do tego aby osiągnąć sukces, • Developerzy dążą do technicznej doskonałości(nauka) i dobrze wykonują swoją pracę-zaufanie pracodawcy, • Oceniamy zespół na podstawie kolejnej działającej iteracji, • Zespół co jakiś czas sprawdza co może usprawnić,

12. Co wynika z manifestu(relacje)? • Klient jest blisko zespołu, częste spotkania • Preferujemy face to face, • Zespół patrzy na zadowolenie klienta • Zespół się samoorganizuje, • Osoby w zespole pomagają sobie nawzajem, czy to oznacza że …

14. Projekt po staremu • Model kaskadowy

15. Przebieg procesu Scrum

16. Artefakty Scrum • Rejestr Produktu (Product Backlog) • Rejestr Iteracji (Sprint Backlog) • Wykres wypalania (Burn down chart) • Lista utrudnień • Tablica zadań

17. Product Backlog

18. Sprint Backlog

19. Burndown chart

20. Tablica zadań

21. Role w Scrumie • Właściciel produktu (Product Owner) • ScrumMaster • Developerzy

22. Product Owner • Zarządza Rejestrem Produktu • Ustala priorytety i kolejność elementów w Rejestrze Produktu • Może zlecać zarządzanie zespołowi deweloperskiemu

23. Scrum Master • Reprezentuje management w projekcie • Pomaga zespołowi w utrzymaniu „rytmu” scrumowego • Usuwa przeszkody ograniczające Zespół Deweloperski • Wspiera Product Managera Ownera

24. Developer self-manager • Działa w zespole - od 3 do 7 developerów, • Developer to osoba która potrafi samodzielnie organizować i zarządzać swoją pracą, układa procedury, • To developer proponuje rozwiązania problemów, szacuje czas i rozbijanie dużych zagadnień na mniejsze, • Może przyjąć rolę Scrum Mastera, • Zgłasza pomysły i usprawnienia, • Powinien być otwarty na zmiany i kontakt z klientem,

25. Stand-up • Trzy pytania: • Co zrobiłem wczoraj? • Co zrobię dzisiaj? • Czy mam z czymś problem? • 15 minut • Tylko zespół deweloperski • Co jeśli zabraknie Scrum Mastera?

26. Błędy Developerów • Stosowanie wzorców projektowych • Złożoność budowanych rozwiązań • Budowa rozwiązań na przyszłość • Czytelność kodu • Brak umiaru w Ctrl+C, Ctrl+V • Zamykanie się z problemem • Problemy komunikacyjne

27. Dobre praktyki Developerów • Modelowanie • TDD - Test-driven development • YAGNI RULE - You aren't gonna need it • SOLID – założenia oprogramowania ob. • Single Responsibility • Open-Closed • Liskov • … • KISS - Keepitsimple, stupid

28. Zasady współpracy w zespole • Developerzy są proaktywni (odwaga i pokora), • Każdy z członków zespołu może liczyć na innego, • Na standupach zobowiązuje się wobec innych że to dzisiaj zrobię (nikt mnie do tego nie zmusza), • Programiści są zachęcani do rozwoju i nauki • Ludzie z zespołu musza mieć dużą samoświadomość, • Każdy wie co robią koledzyi w jakim kierunku podążają

29. Zamknięcie sprintu • Cały zespół spotyka się z Product Ownerem i oglądają wyniki • Jeśli zespół nie dostarczył kompletnej iteracji > także powinno być spotkanie, nie szukamy winnego > wyciągamy wnioski, by to się nie powtórzyło (lessonlearned)

30. Podsumowanie • Ciągły feedback ze strony klienta • Przewaga konkurencyjna dla klienta – szybkość • Kontrola kosztów • Spójny zespół – wiem co robię ja i co robi reszta, widzimy postępy • Kandydaci: aplikacje mobilne i webowe, to co klient może zobaczyć • Dogadanie się dłuższe niż zaplanowane iteracje np.VDR • Zmotywowani ludzie którzy myślą w ten sam sposób • Programista jest self-managerem, developerem, architektem, testerem, analitykiem

31. Pytania? „Agile (Agile PM) nie jest niczym odkrywczym, jest jedynie kreatywną adaptacją zasad Lean Manufacturing.” Jim Highsmith