aitech-pbr2022/.ipynb_checkpoints/05_metodyki_zwinne-checkpoint.ipynb

Przygotowanie do projektu badawczo-rozwojowego

5. Metodyki adaptacyjne w programowaniu[wykład]

Krzysztof Jassem (2022)

Metodyki adaptacyjne (zwinne) w programowaniu (Agile Software Development)

Agile (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.

Manifest Agile

• opublikowany w roku 2001

• autorzy: 17 teoretyków i praktyków programowania

• 4 wartości

• 12 zasad (pryncypiów)

  4 wartości manifestu Agile

1. Ludzie i interakcje ponad procesy i narzędzia.

2. Działające oprogramowanie ponad szczegółową dokumentację.

3. Współpraca z klientem ponad negocjację umów.

4. Reagowanie na zmiany ponad podążaniem za planem.

   12 pryncypiów manifestu Agile

   12 pryncypiów

10 pryncypiów wg Kelly Watersa (All About Agile: Agile Management Made Easy!, 2012)

1. Active User Involvement Is Imperative.

Nic dobrego nie wynika
Bez udziału użytkownika.

2. Agile Development Teams Must Be Empowered.

Nie warta praca mozołu,
Gdy władza nie w rękach zespołu.

3. Time waits for no man.

Czas płynie wartko jak rzeka,
I na nikogo nie czeka.

4. Agile Requirements Are Barely Sufficient.

Dosłownie w kilku dziś zdaniach
Streścimy swe wymagania.

5. How do you eat an elephant? One bite at a time.

Sekretów uchylam wieczko:
Jedz słonia małą łyżeczką.

6. Fast but not so furious.

Byli szybcy, lecz nie wściekli,
I na czas produkt dowlekli.

7. Done Means DONE!

Praca była "wykonana",
I działało... aż do rana.

8. Enough is enough.

Projekt ciągle się rozrasta,
Trzeba krzyknąć: "Stop i Basta!"

9. Agile Testing Is Not For Dummies.

Wiedz, by dobrze móc testować,
Twa głowa ma być pomysłowa.

10. No place for snipers.

Choć mocno znów cierpi Twe ego,
Nie strzelaj - do siebie samego.

Przykład manifestu zespołu ludzi (PWN AI)

1. Biznes stawia cele, IT daje rozwiązania.
2. Wszystko da się zrobić.
3. Biznes wyjaśnia potrzeby, IT wyjaśnia możliwości.
4. Komunikacja i zaangażowanie – albo wyrzucanie pieniędzy w błoto.
5. Wszyscy jesteśmy elastyczni.

Metodyka SCRUM

Scrum jest metodyką, w której kluczowym elementem jest Sprint - faza, która kończy się działającym prototypem. Po każdym Sprincie następuje planowanie działań w kolejnym Sprincie - biorące pod uwagę dotychczasowe doświadczenia.

Struktura metodyki Scrum opiera się na trzech filarach:

• Artefakty
• Role
• Cykl Pracy

Artefakty w metodyce Scrum

Rejestr Produktu (Product Backlog)

Rejestr Produktu to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.

1. Rejestr produktu utrzymywany jest przez Właściciela Produktu.
2. Zadania, których efekt widoczny jest dla użytkownika mają często postać User Story .
3. Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu.

User Story

User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu (Encyklopedia Zarządzania).

User Story ma zwykle postać:

Jako <Kto?> chcę wykonać<Co?> aby<Dlaczego?>

Przykład User Story

> Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić .

Rejestr Sprintu (Sprint Backlog)

Rejestr Sprintu to lista Zadań do wykonania podczas Sprintu:

1. utrzymywana przez Zespół Deweloperski,
2. tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu.

Zadanie (Task)

Zadanie w Rejestrze Sprintu zawiera następujące informacje:

1. opis zadania,
2. szacowany czas wykonania zadania,
3. członek zespołu odpowiedzialnego za wykonanie zadania,
4. status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane).

Role w metodyce Scrum

Udziałowcy (stakeholders)

Udziałowcy to ludzie, którzy finansują projekt:

1. właściciele firmy realizującej projekt,
2. klienci,
3. przyszli użytkownicy.

Właściciel Produktu (Product Owner)

Właściciel Produktu to rola, która reprezentuje interesy biznesu.

Zadania Właściciela Produktu:

1. nadzoruje pisanie User Stories,
2. analizuje na bieżąco potrzeby biznesu i na tej podstawie...
3. ustala priorytet User Stories w Rejestrze Produktu,
4. decyduje, co jest WYKONANE.

Zespół Deweloperski (Development Team)

Zespół Deweloperski to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.

Zadania Zespołu Deweloperskiego:

1. jest odpowiedzialny za implementację,
2. na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint,
3. wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu),
4. sam decyduje o sposobie realizacji zadań.

Scrum Master

Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.

Zadania Scrum Mastera:

1. prowadzi Daily (spotkanie zespołu),
2. prowadzi Retrospektywę,
3. buduje relacje w zespole,
4. pomaga rozwiązywać konflikty,
5. pośredniczy w rozmowach z Właścicielem produktu.

Cykl pracy w metodyce Scrum

Sprint

Sprint to okres, podczas którego tworzy się przyrost projektu, skutkujący prototypem gotowym do użycia. Sprint zazwyczaj trwa nie krócej niż tydzień i nie dłuzej niż miesiąc. W skład Sprintu wchodzą:

1. Planowanie Sprintu,
2. Implementacja,
3. Codzienne spotkania,
4. Przegląd Sprintu,
5. Retrospektywa.

Planowanie Sprintu (Sprint Planning)

Planowanie sprintu jest pierwszym spotkaniem podczas każdego sprintu.

• Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu.
• Planowanie Sprintu prowadzone jest przez Scrum Mastera.

Standardowy przebieg Planowania Sprintu:

1. Analizy Rejestru Produktu - wybór wymagań do realizacji,
2. Określenie celu sprintu - na podstawie wybranych wymagań,
3. Określenie pełnego zakresu prac: jak będzie działał system po Sprincie,
4. Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań,
5. Estymacja pracochłonności zadań.

Codzienne Spotkania (Daily Scrum)

Codzienne Spotkanie (stosowana nazwa w j. polskim - Daily ) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze.

• W Daily bierze udział Zespół Deweloperski.
• Daily prowadzone jest przez Scrum Mastera.

Standardowy plan Daily:

1. Przegląd prac w ciągu ostatniego dnia,
2. Omówienie pojawiających się problemów,
3. Omówienie planu na kolejny dzień.

Przegląd Sprintu

Przegląd Sprintu jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu.

• W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu.
• Przegląd Sprintu prowadzony jest przez Właściciela Produktu.

Standardowy plan Przeglądu Sprintu:

1. Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały "Wykonane”, a które nie.
2. Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano.
3. Zespół Deweloperski prezentuje "Wykonaną” pracę; dyskusja.
4. Właściciel Produktu omawia obecny Rejestr Produktu.
5. Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.
6. Właściciel produktu aktualizuje Rejestr Produktu.

Retrospektywa Sprintu

Retrospektywa Sprintu to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint.

• W Retrospektywie udział bierze Zespół Deweloperski.
• Retrospektywę prowadzi Scrum Master.

Standardowy plan Retrospektywy:

1. Sprawdzenie, co działo się w ostatnim Sprincie,
2. Zidentyfikowanie elementów, które sprawdziły się w działaniu,
3. Zidentyfikowanie elementów, które kwalifikują się do usprawnienia,
4. Stworzenie planu wprowadzania w życie usprawnień.

Wniosek

Nie zrobi informatyk
Złotego interesu,
Gdy nie będzie co tydzień
Słuchał potrzeb biznesu.

Zadania proponowane na laboratoria

Zadanie 1.

Podzielcie się rolami w projekcie według metodyki Scrum i opiszcie, jak widzicie swoje zadania w projekcie.

Zadanie 2.

Opracujcie 5-punktowy manifest pracy w Waszym zespole.

Zadanie 3.

Utwórzcie projekt w systemie JIRA. Opracujcie profile członków grupy (zdjęcia mile widziane). Wpiszcie do backloga "user stories" związane z projektem - założcie w tym momencie, że wykonacie cały produkt high-tech. Sprobujcie oszacować czas realizacji każdego "user story" za pomocą punktów, zakładając że 10 punktów odpowiada sumie pracy całego zespołu podczas jednego tygodniowego sprintu.