Anna Kulig
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Agile Manifesto 2001 rok, Snowbird w stanie Utah w USA Najważniejsi twórcy Kent Beck Alistair Cockburn Martin Fowler Jim Highsmith
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Extreme Programming (XP): lekka metoda rozwoju oprogramowania Kent Beck uważany za tworce (1999).
WARTOŚCI Komunikacja Prostota Sprzężenie zwrotne Odwaga Szacunek
Komunikacja przede wszystkim werbalna. Prostota rozpoczynamy od najprostszego rozwiązania, spełniającego wymagania; refaktoryzacja pozwala na adaptacje oprogramowania do zmian.
Sprzężenie zwrotne Obejmuje klika aspektów (system, klient, zespól). Odwaga potrzebna, by od razu produkować kod; potrzebna, by refaktoryzować; potrzebna, by wyrzucić zbędny kod. Szacunek do pracy i czasu innych; miedzy członkami zespołu.
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Struktura zespołu Role podstawowe : programiści, klient Role pomocnicze: tester, coach, tracker Stawia na współpracę zespołu z klientem
User stories opisują funkcje systemu z punktu widzenia użytkownika ważne by miały wartość dla klienta, powinny być testowane
Projekt informatyczny jest szczelnym systemem 4 zmiennych: daty dostarczenia, kosztu, liczby defektów oraz niekompletności funkcji.
Model kaskadowy Model XP
Gra planistyczna: pisanie user story (klient); oszacowanie user story (informatycy); dzielenie user story/ wybór zakresu iteracji (klient).
Zarządzanie zmianą: XP zakłada, że klient w dowolnym momencie może zmienić zdanie i zaproponować zmianę wymagań.
Zapewnianie jakości prostota; unikanie optymalizacji; TDD (Test Driven Development); automatyczne testowanie; refaktoryzacja;.
Testy akceptacyjne pochodzą od klienta (w ten sposób dokładnie określa zachowanie systemu); najlepiej gdy mogą być wykonywane automatycznie (tester);
PROGRAMOWANIE PARAMI zaleca się, by całość kodu pisana była w parach; częste zmiany w parach; wspólny standard kodowania; kod jest własnością całego zespołu; niezbędny system kontroli wersji.
Wady XP brak fazy projektowania i dokumentacji; krótka perspektywa planowania; silne zalożenie, ze klient pracuje cały czas z zespołem;
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
SCRUM - metoda przy użyciu której ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości.
1986 r.- artykuł The New New Product Development Game ukazał się w Harvard Business Review ; autorami byli Takeuchi i Nonaka ; 1993 r. - pomysł Japończyków został podchwycony przez Jeffa Sutherland a; wprowadził on nowe zasady w projekcie w Easel ; 1995 r. - Ken Schwaber zaprezentował Scrum na konferencji OOPSLA (Object-Oriented Programming, Systems, Languages & Applications); 2001 r. - został napisany Manifest Agile i stworzona organizacja Agile Alliance. Również w tym roku odbył się pierwszy kurs Certified Scrum Master.
SCRUM jest: lekki; latwy do zrozumienia; bardzo trudny do opanowania. Teoria Scruma opiera się na trzech filarach: przejrzystości; inspekcji; adaptacji.
Przejrzystość - wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Adaptacja powinna być ciągła. Korekta musi być wykonana jak najszybciej, by ograniczyć dalsze następstwa problemów.
Inspekcja poddawane regularnej inspekcji są zarówno scrumowe artefakty jak i postępy prac. Scrum przewiduje cztery formalne punkty przeprowadzania inspekcji i okazje do dokonania korekty (adaptacji) - zdarzenia. Planowanie Sprintu Sprint PlanningMeeting) Codzienny Scrum (Daily Scrum) Przegląd Sprintu (Sprint Review Meeting) Retrospektywa Sprintu (Sprint Retrospective)
W obręb Scruma wchodzą Zespoły Scrumowe (Scrum Teams) oraz związane z nimi: role, zdarzenia, artefakty i reguły postępowania.
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Zespoły Scrumowe są samoorganizujące się i wielofunkcyjne (interdyscyplinarne). W skład Zespołu Scrumowego wchodzą: Właściciel Produktu (Product Owner); Zespół Deweloperski (Development Team); Scrum Master;
Właściciel Produktu (Product Owner) jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego. Sposób realizacji tej strategii może być różny pomiędzy poszczególnymi organizacjami, Zespołami Scrumowymi, czy osobami pełniącymi rolę PO.
Właściciel Produktu jest jedyną osobą zarządzającą Rejestrem Produktu (Product Backlog) co rozumiemy przez: jasne artykułowanie elementów Rejestru Produktu i określanie ich kolejności w sposób zapewniający osiąganie założonych celów i misji; zapewnianie, że Rejestr Produktu jest dostępny, przejrzysty oraz jasny dla wszystkich i, że dobrze opisuje to, czym Zespół Scrumowy będzie się zajmował.
Zespoł Deweloperski: jest złożony z profesjonalistów; ma za zadanie dostarczenie (na zakończenie każdego Sprintu), gotowego do wydania Przyrostu produktu; zalecana liczebność: 3-9 osób; są samoorganizujące się.
Zespół Deweloperski: jest wielofunkcyjny, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu; Scrum nie przewiduje tytułów innych niż Deweloper dla członków Zespołu Deweloperskiego; odpowiedzialność za wykonywaną pracę ponosi cały Zespół Deweloperski; nie składają się z podzespołów.
Scrum Master jest odpowiedzialny za to, by Scrum był rozumiany i stosowany. Scrum Masterzy dokonują tego poprzez upewnianie się, że Zespół Scrumowy stosuje się do założeń teorii Scruma, jego praktyk i reguł postępowania. Scrum Master wspiera zarówno Właściciela Produktu jak i zespól deweloperski.
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Zdarzenia w Scrumie używane do wprowadzenia regularności; są ograniczone czasowo; każde (oprócz Sprintu) jest okazją do inspekcji i adaptacji.\ Sprint, Planowanie Sprintu, Codzienny Scrum, Przegląd Sprintu, Retrospektywa Sprintu
SPRINT serce Scruma ograniczenie czasowe trwające jeden miesiąc lub krócej; Podczas Sprintu wytwarzany jest Przyrost Ukończonej, używalnej i potencjalnie gotowej do wydania funkcjonalności; ma stałą długość przez cały okres trwania prac; niedozwolone są zmiany, które wpłyną na cel Sprintu; skład Zespołu Deweloperskiego i jego cel jakościowy pozostają niezmienne.
Przerwanie Sprintu tylko Właściciel Produktu ma prawo to zrobić; Sprint może zostać przerwany, jeśli cel Sprintu się zdezaktualizuje; powinien zostać przerwany, jeśli kontynuowanie prac nie ma sensu w zaistniałych okolicznościach; przerwania Sprintów zużywają zasoby, ponieważ wszyscy muszą się przegrupować podczas kolejnego Planowania Sprintu, aby móc rozpocząć nowy Sprint.
Praca wykonywana w trakcie Sprintu jest planowana podczas Planowania Sprintu. Planowanie Sprintu: Jest ograniczone czasowo (8h dla miesięcznego sprintu i proporcjonalnie); Planowanie Sprintu składa się z dwóch części Co zostanie dostarczone Jaka praca zostanie wykonana
Część pierwsza: Co będzie zrobione w tym Sprincie? Wejście: Rejestr Produktu; ostatni przyrost; przewidywana pojemność ZD; ostatnie odczyty wydajności; Wyjście: elementu Rejestru Produktu wybrane do zaimplementowania; Cel Sprintu.
Część druga: Jak wybrana praca będzie wykonana? Zespół deweloperski zwykle rozpoczyna od stworzenia projektu systemu i planu prac niezbędnych do przetworzenia elementów Rejestru Produktu w działający Przyrost produktu. Zanim Planowanie Sprintu dobiegnie końca, Zespół Deweloperski powinien móc wytłumaczyć Właścicielowi Produktu i Scrum Masterowi, w jaki sposób ma zamiar pracować, organizując się samodzielnie, by osiągnąć Cel Sprintu i wytworzyć oczekiwany Przyrost.
Codzienny Scrum jest spotkaniem ograniczonym czasowo do 15 minut, w którym każdy z członków zespołu wyjaśnia: Co zostało wykonane od ostatniego potkania? Co zostanie wykonane przed kolejnym spotkaniem? Jakie przeszkody stoją na drodze?
Przegląd Sprintu organizowany jest na zakończenie Sprintu w celu przeprowadzenia inspekcji Przyrostu i dostosowaniu, jeśli zajdzie taka potrzeba, Rejestru Produktu. Podczas Przeglądu Sprintu Zespół Scrumowy i interesariusze wspólnie omawiają to, co zostało ukończone w Sprincie. Może trwać maksymalnie 4h dla miesięcznego Sprintu.
Przegląd Sprintu obejmuje następujące punkty: Właściciel Produktu stwierdza, które funkcjonalności zostały Ukończone, a które nie; Zespół Deweloperski omawia, co poszło dobrze w trakcie Sprintu; jakie były problemy i jak je rozwiązano; Zespół Deweloperski prezentuje Ukończoną pracę i odpowiada na pytania dotyczące Przyrostu, Właściciel Produktu omawia Rejestr Produktu w aktualnej jego postaci. Przewiduje termin zakończenia prac. Cala grupa omawia kolejne kroki.
Retrospektywa Sprintu jest okazją dla zespołu Scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień. Ma na celu: Sprawdzenie, co działo się w ostatnim Sprincie, biorąc pod uwagę ludzi, zależności, procesy i narzędzia; Zidentyfikowanie i uporządkowanie istotnych elementów, które sprawdziły się w działaniu oraz tych, które kwalifikują się do poprawy; Stworzenie planu wprowadzania w życie usprawnień sposobu wykonywania pracy przez Zespół Scrumowy.
Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty
Rejestr Produktu to uporządkowana lista wszystkiego, co może być potrzebne w produkcie oraz jedyne źródło wymaganych zmian, które mają wprowadzone. Odpowiedzialny za RP jest Właściciel Produktu. Elementy Rejestru Produktu posiadają następujące atrybuty: opis, kolejność i oszacowanie (estymację).
Rejestr Sprintu to podzbiór elementów Rejestru Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu. Rejestr Sprintu definiuje pracę, jaką Zespół Deweloperski wykona by przekształcić elementy Rejestru Produktu w Ukończony Przyrost. Rejestr Sprintu jest dobrze widocznym, tworzonym w czasie rzeczywistym obrazem pracy, jaką Zespół Deweloperski planuje wykonać w trakcie Sprintu. Rejestr Sprintu należy tylko i wyłącznie do Zespołu Deweloperskiego.
Monitorowanie postępów Sprintu możliwe w każdym momencie Sprintu (Codzienny Scrum) Przyrost - suma wszystkich elementów Rejestru Produktu zakończonych podczas Sprintu i wszystkich Sprintów poprzednich. : Na koniec Sprintu nowy Przyrost musi być Ukończony.
Aby zapewnić przejrzystość, wszyscy członkowie danego zespołu muszą mieć wspólne pojmowanie, co to znaczy, że praca jest skończona. Pomaga w tym Definicja Ukończenia dla Zespołu Scrumowego. W miarę jak Zespoły Scrumowe dojrzewają, oczekuje się, że ich Definicja Ukończenia będzie zawierała coraz bardziej rygorystyczne kryteria zapewniania jeszcze wyższej jakości.
Część materiałów zaczerpnięta z http://wazniak.mimuw.edu.pl/,