Zwinne metodyki tworzenia oprogramowania. Programowanie ... · Zwinne metodyki tworzenia oprogramowania. ... są bardzo potrzebne do budowy skomplikowanych systemów ze ... Manifesto

INśYNIERIA OPROGRAMOWANIAINśYNIERIA OPROGRAMOWANIA INśYNIERIAOPROGRAMOWANIA

Zwinne metodyki tworzenia oprogramowania.Programowanie ekstremalne

Wykorzystane materiały:• materiały szkoleniowe (nie istniejącego juŜ) Zespołu ds. Projektów IT Equilibrium• http://xprince.net (XPrince)• http://brasil.cel.agh.edu.pl/~09sbfraczek/programowanie-ekstremalne,1,58.html

Dilbert by Scott Adams

Kryzys oprogramowania INśYNIERIAOPROGRAMOWANIA

� Kryzys oprogramowania (ang. software crisis) — zjawisko polegające na powiększającej się rozbieŜności między mocą obliczeniową sprzętu komputerowego a efektywnością produkcji oprogramowania. Zostało zauwaŜone w latach 60Zostało zauwaŜone w latach 60--tych XX wieku.tych XX wieku.

� W odpowiedzi starano się zwiększyć dyscyplinę w wytwarzaniu oprogramowania. W ciągu następnych 20-tu lat zaproponowano wiele standardów (IEEE, ISO, itd.), tradycyjnych modeli oraz metodyk zorientowanych na dyscyplinę oraz pierwsze podejścia zarządzania projektami do wytwarzania oprogramowania (np. PRINCE2).

� Zbyt duŜa restrykcyjność ogranicza inicjatywę i elastyczność, które są bardzo potrzebne do budowy skomplikowanych systemów ze zmiennymi wymaganiami. Aby temu zaradzić, w latach 90-tych XX wieku powstały tak zwane zwinne metodyki (ang. agile methodologies).

Tradycyjne metodyki programowania INśYNIERIAOPROGRAMOWANIA

� Przedsięwzięcie informatyczne w centrum uwagi

�� Ludzie (programiści) jako odnawialny zasóbLudzie (programiści) jako odnawialny zasób

�� Długoterminowe, ale powolne planowanieDługoterminowe, ale powolne planowanie

�� Mała elastyczność projektuMała elastyczność projektu

�� Zapis formalnej dokumentacjiZapis formalnej dokumentacji

Najwięcej o systemie wiedzą jego projektanci, Najwięcej o systemie wiedzą jego projektanci,

podczas gdy rola programistów sprowadza się podczas gdy rola programistów sprowadza się

do rzemieślniczego implementowania do rzemieślniczego implementowania

cudzych pomysłówcudzych pomysłów

Konsekwencje i problemy podejścia tradycyjnego INśYNIERIAOPROGRAMOWANIA

� Zmiana w systemie jest czasochłonna, gdyŜ naleŜy go ponownie przeprojektować i zaimplementować

� Kontakt z uŜytkownikiem ograniczony jest do rzadkich spotkań mających na celu zebranie wymagań i przeprowadzenie testów akceptacyjnych

� Potencjał i kreatywność programisty ograniczone są przez projektanta

� W stosunku do programowania, debugowanie i wyszukiwanie błędów zajmuje duŜo czasu

� Zamawiane oprogramowanie jest zwykle oddawane po terminie

� BudŜet bywa często przekraczany

� Programiści często muszą pracować w dodatkowym czasie

� Jakość stworzonego oprogramowania jest zła

� Funkcjonalność systemu często odbiega od oczekiwań klienta

Manifest zwinnego (agile) podejścia do rozwoju oprogramowania

INśYNIERIAOPROGRAMOWANIA

2001: Manifesto for Agile Software Development – deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania, opartych na:

� Ludziach i interakcjach pomiędzy nimi – zamiast procesów i narzędzi

� Działającym oprogramowaniu – zamiast szczegółowej dokumentacji

� Współpracy z klientem – zamiast negocjowania kontraktów

� Reagowaniu na zmiany – zamiast realizowania planu

O ile elementy wymienione po prawej są istotne,

te występujące z lewej strony są duŜo waŜniejsze

Więcej informacji: http://agilemanifesto.org/

Rozwinięcie zasad podejścia zwinnego INśYNIERIAOPROGRAMOWANIA

� Szybko wytworzone oprogramowanie, skutkujące satysfakcją klienta

� Działające oprogramowanie jest dostarczane okresowo, np. w dwutygodniowych przyrostach (model przyrostowy)

� Podstawową miarą postępu jest działające oprogramowanie (przyrosty)

� Późne zmiany w specyfikacji nie mają destrukcyjnego charakteru na proces wytwarzania oprogramowania, szybka adaptacja

� Bliska, stała (codzienna) współpraca pomiędzy klientem a wytwórcą

� Bezpośredni kontakt jako najlepsza forma komunikacji w zespole ipoza nim

� Ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt

� Prostota projektu i oprogramowania

� Uznanie kodu za dokumentację projektu

� Samozarządzalność zespołów

Agile Alliance INśYNIERIAOPROGRAMOWANIA

� Organizacja, skupiająca prawie 5500 członków (firmy, instytucje, osoby prywatne; stan na dzień 22/03/2010), załoŜona w 2001 r.

� Promuje zastosowania metodyk zwinnego programowania poprzez wydawanie publikacji, organizowanie szkoleń, realizacją programów proponowanych przez członków

http://www.agilealliance.org/

Martin Fowler - twórca pomysłu refaktoryzacji, autor "UML Distilled" Jim Highsmith - autor metodyki Adaptive Software Development

Główni twórcy manifestu Agile oraz Agile Alliance

Kent Beck - twórca metod analizy obiektowej, autor narzędzi xUnit, autor metodyki eXtreme ProgrammingAlistair Cockburn - autor rodziny zwinnych metodyk Crystal, oraz ksiąŜek poświęconych inŜynierii wymagań

NajwaŜniejsze metodyki i praktyki zwinnego programowania


Metodyki:

� Dynamic Systems Development Method (DSDM)

� SCRUM

� eXtreme Programming (XP) – Programowanie ekstremalne

� Feature Driven Development (FDD)

� Agile Unified Process (AUP)

Praktyki:

� Planning poker, Planning game – Gra planistyczna

� Test Driven Development (TDD) – Programowanie sterowane testami

� Behavior Driven Development (BDD) – Programowanie sterowane zachowaniem

� Pair Programming – Programowanie w parach

� Continuous Integration, Refactoring – Ciągła integracja, refaktoring

Dlaczego omówimy eXtreme Programming? INśYNIERIAOPROGRAMOWANIA

Tom deMarco: „eXtreme Programming jest dzisiaj najwaŜniejszym ruchem w całej inŜynierii oprogramowania”

eXtreme Programming

zawiera w sobie najwaŜniejsze

praktyki podejścia zwinnego

Twórca metodyki: Kent Beck, 1999Twórca metodyki: Kent Beck, 1999

eXtreme Programming (XP) – terminologia INśYNIERIAOPROGRAMOWANIA

Zanim rozpocznie się jakiekolwiek działanie, naleŜy najpierw określić rezultat, jaki spodziewamy się uzyskać oraz określić ogólną koncepcję (wizję), do której dąŜymy. Aby móc wdraŜać ją w Ŝycie, określamy w jejobrębie konkretne cele, które z kolei dzielą się na zadania, zaplanowane do wykonania w ściśle określonym miejscu i czasie.

Nazewnictwo w XP: wizji odpowiada metafora systemu (metaphor), celom – opowieści uŜytkownika (user stories); zadania oraz terminy zachowują swe nazwy

XP – od wizji do produktu INśYNIERIAOPROGRAMOWANIA

Czteroetapowy model pracy:

� Określ cel

� Wykonaj działanie

� Odbierz informację zwrotną

� Skoryguj działanie tak, by kolejny efekt był bliŜszy sukcesowi

System powstaje od ogólnej wizji, aŜ do uzyskania końcowego produktu, dzięki kolejnym przybliŜeniom. KaŜda kolejna wersja zbliŜa się funkcjonalnością do końcowego produktu, do ideału określonego w metaforze.

XP – główne wartości (1) INśYNIERIAOPROGRAMOWANIA

�� KomunikacjaKomunikacjaOsoby tworzące oprogramowanie muszą identyfikować się z Osoby tworzące oprogramowanie muszą identyfikować się z tworzonym projektem. W tym celu niezbędne jest zapewnienie dobretworzonym projektem. W tym celu niezbędne jest zapewnienie dobrej j komunikacji w zespole. Dodatkowo, bardzo waŜne są umiejętności komunikacji w zespole. Dodatkowo, bardzo waŜne są umiejętności interpersonalne w trakcie współpracy z klientem czy podczas interpersonalne w trakcie współpracy z klientem czy podczas programowania w parach.programowania w parach.

�� ProstotaProstotaProjekt powinien być tak prosty, jak to moŜliwe. Nie oznacza to Projekt powinien być tak prosty, jak to moŜliwe. Nie oznacza to stosowania banalnych rozwiązań, lecz stałe utrzymywanie jego stosowania banalnych rozwiązań, lecz stałe utrzymywanie jego przejrzystości i spójności. przejrzystości i spójności.

�� SzacunekSzacunekSzacunek do pracy i czasu innych osób w zespoleSzacunek do pracy i czasu innych osób w zespole

XP – główne wartości (2) INśYNIERIAOPROGRAMOWANIA

�� Informacja zwrotnaInformacja zwrotna

Informacja zwrotna wraz z odpowiednią reakcją na nią są kluczowyInformacja zwrotna wraz z odpowiednią reakcją na nią są kluczowymi mi składowymi kaŜdego przedsięwzięcia. Informację tę programiści składowymi kaŜdego przedsięwzięcia. Informację tę programiści uzyskują zarówno na poziomie ogólnym uzyskują zarówno na poziomie ogólnym –– od klienta, jak i od klienta, jak i szczegółowym szczegółowym –– na podstawie wyników przypadków testowych TDD na podstawie wyników przypadków testowych TDD

�� OdwagaOdwaga

Programista powinien umieć, zachowując świadomość celu, Programista powinien umieć, zachowując świadomość celu, podejmować waŜne decyzje, podejmować waŜne decyzje, npnp. w kwestiach takich, jak refaktoring, . w kwestiach takich, jak refaktoring, kluczowa zmiana architektury systemu, reorganizacja modelu. W kluczowa zmiana architektury systemu, reorganizacja modelu. W związku z tym powinien charakteryzować się odwagą w podejmowaniuzwiązku z tym powinien charakteryzować się odwagą w podejmowaniui wdraŜaniu decyzji, jak równieŜ brać za nie pełną odpowiedzialni wdraŜaniu decyzji, jak równieŜ brać za nie pełną odpowiedzialność. ość. Zgodnie z załoŜeniem XP programista zawsze moŜe liczyć na opinięZgodnie z załoŜeniem XP programista zawsze moŜe liczyć na opinięklienta w kwestii istotnych decyzji.klienta w kwestii istotnych decyzji.

Praktyki / cechy XP INśYNIERIAOPROGRAMOWANIA

�� Określenie metafory tworzonego systemuOkreślenie metafory tworzonego systemu

�� Gra planistycznaGra planistyczna

�� Częste wydaniaCzęste wydania

�� Prosty projekt systemuProsty projekt systemu

�� Programowanie sterowane testami (TDD)Programowanie sterowane testami (TDD)

�� RefaktoringRefaktoring

�� Współwłasność koduWspółwłasność kodu

�� Ciągła integracjaCiągła integracja

�� Udział klienta w zespoleUdział klienta w zespole

�� Obowiązujący standard kodowaniaObowiązujący standard kodowania

�� Programowanie w parachProgramowanie w parach

Struktura zespołu w XP INśYNIERIAOPROGRAMOWANIA

Główne role:Główne role:

�� ProgramiściProgramiści

�� KlientKlient –– uwaŜany jest za członka uwaŜany jest za członka zespołu, więc musi przez cały czas zespołu, więc musi przez cały czas pracować razem z informatykami; pracować razem z informatykami; czasem nie występuje w tej roli czasem nie występuje w tej roli osobiście, lecz ma swojego osobiście, lecz ma swojego przedstawiciela.przedstawiciela.

Role pomocnicze:Role pomocnicze:

�� TesterTester –– pisze skrypty testowe na podstawie rozmów z klientempisze skrypty testowe na podstawie rozmów z klientem

�� CoachCoach –– pomaga rozwiązywać napotkane problemy (technologiczne, pomaga rozwiązywać napotkane problemy (technologiczne, organizacyjne itp.)organizacyjne itp.)

�� TrackerTracker –– zbiera statystyki dotyczące wykonanych zadań, czasu zbiera statystyki dotyczące wykonanych zadań, czasu pracy i tworzy podsumowania postępów projektupracy i tworzy podsumowania postępów projektu

Omówienie praktyk XP na przykładzie Portalu Rekrutacyjnego


A. Stworzenie metafory systemuA. Stworzenie metafory systemu

Jest to bardzo ogólna specyfikacja wymagań z punktu widzenia Jest to bardzo ogólna specyfikacja wymagań z punktu widzenia uŜytkownika i tworzona wraz z uŜytkownikiem.uŜytkownika i tworzona wraz z uŜytkownikiem.

Metafora projektu składa się zwykle z kilku zdań, które prezentuMetafora projektu składa się zwykle z kilku zdań, które prezentują ją ogólny szkic tworzonego systemu. Zdania te powinny być zrozumiałogólny szkic tworzonego systemu. Zdania te powinny być zrozumiałe e zarówno dla klienta jak i dla zespołu programistów. Dzięki temu zarówno dla klienta jak i dla zespołu programistów. Dzięki temu wszyscy biorący udział w projekcie będą znali jego główny cel.wszyscy biorący udział w projekcie będą znali jego główny cel.

Metafora projektu Portalu Rekrutacyjnego:Metafora projektu Portalu Rekrutacyjnego:

Portal Rekrutacyjny obsługuje osoby szukające pracy, umoŜliwiająPortal Rekrutacyjny obsługuje osoby szukające pracy, umoŜliwiając im c im

wprowadzanie danych ze swojego CV. Ponadto system pozwala pracodwprowadzanie danych ze swojego CV. Ponadto system pozwala pracodawcom awcom

wyszukiwać kandydatów odpowiadających ich oczekiwaniom.wyszukiwać kandydatów odpowiadających ich oczekiwaniom.



B. Gra planistycznaB. Gra planistyczna, której efektem są , której efektem są user storiesuser stories, czyli konkretne , czyli konkretne oczekiwania stawiane systemowi, spisywane na pojedynczych kartacoczekiwania stawiane systemowi, spisywane na pojedynczych kartach, h, w języku uŜytkownika.w języku uŜytkownika.

Etap ten pozwala określić konkretne wymagania klienta co do Etap ten pozwala określić konkretne wymagania klienta co do tworzonego systemu oraz zaplanować działania zespołu tak, aby w tworzonego systemu oraz zaplanować działania zespołu tak, aby w terminie osiągnąć zamierzone efekty.terminie osiągnąć zamierzone efekty.

Gra planistyczna pomaga:Gra planistyczna pomaga:

�� doprecyzować wizję projektu (doprecyzować wizję projektu (metaforęmetaforę))

�� zidentyfikować wymagania klienta (zidentyfikować wymagania klienta (user storiesuser stories))

�� określić czas potrzebny na spełnienie konkretnych wymagań określić czas potrzebny na spełnienie konkretnych wymagań

�� nadać priorytety poszczególnym wymaganiom nadać priorytety poszczególnym wymaganiom

�� zaplanować pracę zespołu zaplanować pracę zespołu



Gra planistycznaGra planistyczna „rozgrywa się” pomiędzy klientem a zespołem „rozgrywa się” pomiędzy klientem a zespołem programistycznym programistycznym –– jest to gra kooperatywna.jest to gra kooperatywna.

Sesja prowadzona jest przy stole, gdzie obok siebie siedzą klienSesja prowadzona jest przy stole, gdzie obok siebie siedzą klienci oraz ci oraz członkowie zespołu programistycznego. Stół powinien być na tyle członkowie zespołu programistycznego. Stół powinien być na tyle duŜy, aby łatwo moŜna było na nim układać kartki zawierające spiduŜy, aby łatwo moŜna było na nim układać kartki zawierające spisane sane wymagania.wymagania.

Wymagania klienta spisuje się na osobnych kartkach i numeruje. Wymagania klienta spisuje się na osobnych kartkach i numeruje. Istotne jest, aby Istotne jest, aby user storyuser story określało pewien wycinek funkcjonalności określało pewien wycinek funkcjonalności systemu, systemu, npnp.:.:

1. 1. Osoba szukająca pracy rejestruje się samodzielnie w systemie rekOsoba szukająca pracy rejestruje się samodzielnie w systemie rekrutacyjnym.rutacyjnym.

2. 2. Osoba szukająca pracy wprowadza dane niezbędne w procesie rekrutOsoba szukająca pracy wprowadza dane niezbędne w procesie rekrutacji (dane acji (dane

osobowe, informacje o wykształceniu i doświadczeniu zawodowym).osobowe, informacje o wykształceniu i doświadczeniu zawodowym).




User story =

wymaganie uŜytkownika



User storiesUser stories naleŜy pisać tak, aby były czytelne i zrozumiałe, unikając naleŜy pisać tak, aby były czytelne i zrozumiałe, unikając szczegółów i technicznego języka, którym na co dzień posługują sszczegółów i technicznego języka, którym na co dzień posługują się ię programiści. programiści.

Zamiast:Zamiast:

3. 3. Administrator odpowiedzialny za serwer rekrutacyjny generuje konAdministrator odpowiedzialny za serwer rekrutacyjny generuje konta dla firm, ta dla firm,

które mają być zarejestrowane w systemie.które mają być zarejestrowane w systemie.

jaśniej będzie:jaśniej będzie:

3. 3. Administrator systemu tworzy konta dla firm.Administrator systemu tworzy konta dla firm.

O ile jest to moŜliwe, naleŜy pisać O ile jest to moŜliwe, naleŜy pisać user storiesuser stories w taki sposób, aby były w taki sposób, aby były niezaleŜne od siebie (niezaleŜne od siebie (npnp. Ŝeby nie wynikały z siebie, nie pokrywały się). . Ŝeby nie wynikały z siebie, nie pokrywały się). Ułatwi to późniejsze przydzielenie zadań grupom programistycznymUłatwi to późniejsze przydzielenie zadań grupom programistycznym..



User storiesUser stories powinny być powinny być testowalnetestowalne (weryfikowalne).(weryfikowalne).

Dla przykładu:Dla przykładu:

4. 4. Pracodawca moŜe łatwo wyszukiwać poŜądane dane w systemie.Pracodawca moŜe łatwo wyszukiwać poŜądane dane w systemie.

nic nie mówi o tym, kiedy wyszukiwanie będzie łatwe. nic nie mówi o tym, kiedy wyszukiwanie będzie łatwe.

Lepiej napisać konkretne wymagania:Lepiej napisać konkretne wymagania:

4. 4. Pracodawca moŜe wyszukiwać kandydata wg zadanych kryteriów:Pracodawca moŜe wyszukiwać kandydata wg zadanych kryteriów:

wykształcenia, zawodu, miejsca zamieszkania, doświadczenia, umiewykształcenia, zawodu, miejsca zamieszkania, doświadczenia, umiejętności.jętności.

Czasami zdarza się, Ŝe Czasami zdarza się, Ŝe user storyuser story jest zbyt duŜe. NaleŜy je wtedy jest zbyt duŜe. NaleŜy je wtedy podzielić na mniejsze.podzielić na mniejsze.



Kolejnym etapem jest Kolejnym etapem jest oszacowanie, ile czasu zajmie implementacjaoszacowanie, ile czasu zajmie implementacjakaŜdej kaŜdej user storyuser story. Informacja ta jest niezbędna do zaplanowania . Informacja ta jest niezbędna do zaplanowania zadania dla grup programistów.zadania dla grup programistów.

Czas szacuje się na podstawie wcześniejszych doświadczeń. Czas szacuje się na podstawie wcześniejszych doświadczeń.

MoŜna MoŜna npnp. porównać daną . porównać daną user storyuser story z inną, która juŜ kiedyś została z inną, która juŜ kiedyś została zaimplementowana i na tej podstawie określić czas jej implementazaimplementowana i na tej podstawie określić czas jej implementacji. cji.

Szacować czas naleŜy w moŜliwie najprostszy sposób. Szacować czas naleŜy w moŜliwie najprostszy sposób.

Szacowanie zawsze będzie przybliŜeniem Szacowanie zawsze będzie przybliŜeniem –– nie ma sensu stosować nie ma sensu stosować wyrafinowanych sposobów szacowania.wyrafinowanych sposobów szacowania.



Ostatnim etapem jest Ostatnim etapem jest nadanie priorytetównadanie priorytetów –– naleŜy ustalić, które naleŜy ustalić, które user user storiesstories są najbardziej istotne dla klienta. Dzięki temu moŜna tak są najbardziej istotne dla klienta. Dzięki temu moŜna tak zaplanować kolejne kroki, aby najbardziej wartościowe (z punktu zaplanować kolejne kroki, aby najbardziej wartościowe (z punktu widzenia klienta) wymagania były spełnione jako pierwsze.widzenia klienta) wymagania były spełnione jako pierwsze.

Priorytety zapisuje się w postaci liczby. Często jest to skala Priorytety zapisuje się w postaci liczby. Często jest to skala pięciostopniowa, gdzie 1 odpowiada najwyŜszemu priorytetowi, a 5pięciostopniowa, gdzie 1 odpowiada najwyŜszemu priorytetowi, a 5najniŜszemu.najniŜszemu.

Reguła 80/20Reguła 80/20

Typowo, 80% wyników pochodzi z 20% wysiłkuTypowo, 80% wyników pochodzi z 20% wysiłku

Warto więc pokusić się o znalezienie tej części systemu, której Warto więc pokusić się o znalezienie tej części systemu, której wytworzenie (w 20% dostępnego czasu, przy wykorzystaniu 20% wytworzenie (w 20% dostępnego czasu, przy wykorzystaniu 20% budŜetu czy zasobów ludzkich itp.) doprowadzi do zbudowania budŜetu czy zasobów ludzkich itp.) doprowadzi do zbudowania większości (80%) systemu. większości (80%) systemu. Nie jest to oczywiście łatwe…Nie jest to oczywiście łatwe…



PrzykładowePrzykładowe user storiesuser stories dla Portalu Rekrutacyjnego:dla Portalu Rekrutacyjnego:

1. [1] 1. [1] Osoba Szukająca Pracy rejestruje się samodzielnie w systemieOsoba Szukająca Pracy rejestruje się samodzielnie w systemie [24 godz.][24 godz.]

2. [1] 2. [1] Osoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutOsoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutacji (dane acji (dane

osobowe, dane o wykształceniu i doświadczeniu zawodowym)osobowe, dane o wykształceniu i doświadczeniu zawodowym) [32 godz.][32 godz.]

3. [2] 3. [2] Administrator systemu tworzy konta dla firmAdministrator systemu tworzy konta dla firm [16 godz.][16 godz.]

4. [3] 4. [3] Firmy mają ograniczony czas dostępu do serwisuFirmy mają ograniczony czas dostępu do serwisu [16 godz.][16 godz.]

5. [2] 5. [2] Pracodawca moŜe wyszukiwać kandydatów wg zadanych kryteriów (wykPracodawca moŜe wyszukiwać kandydatów wg zadanych kryteriów (wykształcenie, ształcenie,

zawód, miejsce zamieszkania, doświadczenie, umiejętności)zawód, miejsce zamieszkania, doświadczenie, umiejętności) [32 godz.][32 godz.]

6. [3] 6. [3] Wyniki wyszukiwania mogą być wyeksportowane (format: CSV)Wyniki wyszukiwania mogą być wyeksportowane (format: CSV) [32 godz.][32 godz.]

7. [4] 7. [4] Rejestracja Osoby Szukającej Pracy musi być zatwierdzona przez ARejestracja Osoby Szukającej Pracy musi być zatwierdzona przez Administratoradministratora [8 [8 godz.]godz.]

8. [5] 8. [5] Osoba Szukająca Pracy dostaje informację, Ŝe konkretna firma jesOsoba Szukająca Pracy dostaje informację, Ŝe konkretna firma jest zainteresowana jej t zainteresowana jej

ofertąofertą [12 godz.][12 godz.]

9. [4] 9. [4] Pracodawca po wybraniu najbardziej odpowiadających mu Osób SzukaPracodawca po wybraniu najbardziej odpowiadających mu Osób Szukających Pracy i jących Pracy i

uiszczeniu opłaty, uzyskuje dostęp do ich danych osobowychuiszczeniu opłaty, uzyskuje dostęp do ich danych osobowych [20 godz.][20 godz.]



C. Wybór z user stories zestawu do pierwszej iteracjiC. Wybór z user stories zestawu do pierwszej iteracji, której , której efektem będzie pierwsze przybliŜenie końcowego produktu.efektem będzie pierwsze przybliŜenie końcowego produktu.

Zasady:Zasady:

�� Jeśli klient widzi, Ŝe coś działa, to znaczy, Ŝe działa, a jeśliJeśli klient widzi, Ŝe coś działa, to znaczy, Ŝe działa, a jeśli nie widzi, to nie widzi, to znaczy, Ŝe nie działaznaczy, Ŝe nie działa

�� Klient nigdy nie będzie w stanie docenić kunsztu twórców programKlient nigdy nie będzie w stanie docenić kunsztu twórców programuu

�� Klient musi „doświadczyć” systemu i tylko wtedy będzie przekonanKlient musi „doświadczyć” systemu i tylko wtedy będzie przekonany o y o celowości kontynuowania przedsięwzięciacelowości kontynuowania przedsięwzięcia

Z tych powodów proces tworzenia projektu dzieli się na części, zZ tych powodów proces tworzenia projektu dzieli się na części, zwane wane iteracjamiiteracjami. W czasie danej iteracji powstaje działający system wzbogacony . W czasie danej iteracji powstaje działający system wzbogacony o o kolejne cechy. Nie budujemy od razu gotowej aplikacji, lecz dostkolejne cechy. Nie budujemy od razu gotowej aplikacji, lecz dostarczamy ją arczamy ją iteracyjnie tak, aby klient naocznie mógł stwierdzić postępy w piteracyjnie tak, aby klient naocznie mógł stwierdzić postępy w pracy (proces racy (proces przyrostowy). Klient cały czas moŜe obserwować postępy w pracachprzyrostowy). Klient cały czas moŜe obserwować postępy w pracach..



Planując iterację z klientem ustala się, które elementy systemu Planując iterację z klientem ustala się, które elementy systemu są dla są dla niego najistotniejsze. niego najistotniejsze.

Wybiera się zatem Wybiera się zatem user stories user stories o najwyŜszym priorytecie, których o najwyŜszym priorytecie, których sumaryczny czas wykonania nie przekroczy długości iteracji (długsumaryczny czas wykonania nie przekroczy długości iteracji (długość ość iteracji powinna wynosić od 2 do 3 tygodni i być moŜliwie stała)iteracji powinna wynosić od 2 do 3 tygodni i być moŜliwie stała) ––moŜliwie szybko naleŜy dostarczyć system z pewną gotową moŜliwie szybko naleŜy dostarczyć system z pewną gotową funkcjonalnością. funkcjonalnością.

NaleŜy teŜ uzgodnić z klientem NaleŜy teŜ uzgodnić z klientem warunkiwarunki, które pozwolą stwierdzić, Ŝe , które pozwolą stwierdzić, Ŝe dana funkcjonalność została zrealizowana. MoŜna to zrobić w sposdana funkcjonalność została zrealizowana. MoŜna to zrobić w sposób ób formalny formalny –– uŜywając języka pseudoalgorytmicznego, notacji uŜywając języka pseudoalgorytmicznego, notacji matematycznej, tabeli warunków matematycznej, tabeli warunków –– lub w sposób mniej formalny lub w sposób mniej formalny ––uŜywając języka klienta. Skonkretyzowany zbiór warunków akceptacuŜywając języka klienta. Skonkretyzowany zbiór warunków akceptacji ji danego wymagania nazywany jest danego wymagania nazywany jest testem akceptacyjnymtestem akceptacyjnym..



W przykładzie, do pierwszej iteracji wybieramy następujące W przykładzie, do pierwszej iteracji wybieramy następujące user storiesuser stories, , sugerując się ich priorytetem i czasem wykonania:sugerując się ich priorytetem i czasem wykonania:

1. [1] 1. [1] Osoba Szukająca Pracy rejestruje się samodzielnie w systemieOsoba Szukająca Pracy rejestruje się samodzielnie w systemie [24 godz.][24 godz.]

2. [1] 2. [1] Osoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutOsoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutacji (dane acji (dane

osobowe, dane o wykształceniu i doświadczeniu zawodowym)osobowe, dane o wykształceniu i doświadczeniu zawodowym) [32 godz.][32 godz.]

3. [2] 3. [2] Administrator systemu tworzy konta dla firmAdministrator systemu tworzy konta dla firm [16 godz.][16 godz.]

5. [2] 5. [2] Pracodawca moŜe wyszukiwać kandydatów wg zadanych kryteriów (wykPracodawca moŜe wyszukiwać kandydatów wg zadanych kryteriów (wykształcenie, ształcenie,

zawód, miejsce zamieszkania, doświadczenie, umiejętności)zawód, miejsce zamieszkania, doświadczenie, umiejętności) [32 godz.][32 godz.]

Razem:Razem: 104 godziny = 13 dni104 godziny = 13 dni

Dilbert by Scott Adams, tłum. własne



Planuje się tylko następną Planuje się tylko następną iteracjęiterację. Efektem kaŜdej iteracji powinna być . Efektem kaŜdej iteracji powinna być wersja programu spełniającą załoŜenia dla danej iteracji. wersja programu spełniającą załoŜenia dla danej iteracji.

Podejście iteracyjne daje potencjalnym uŜytkownikom Podejście iteracyjne daje potencjalnym uŜytkownikom czas na czas na zapoznanie sięzapoznanie się i „oswojenie” z systemem, którego w przyszłości będą i „oswojenie” z systemem, którego w przyszłości będą uŜywać, a takŜe pozwala uŜywać, a takŜe pozwala na bieŜąco uwzględniać ich sugestie oraz na bieŜąco uwzględniać ich sugestie oraz potrzebypotrzeby. Implikuje to duŜą elastyczność tworzonego projektu.. Implikuje to duŜą elastyczność tworzonego projektu.

Do kolejnych iteracji brane są nie zrealizowane w pełni Do kolejnych iteracji brane są nie zrealizowane w pełni user storiesuser storiesoraz nowe oraz nowe user storiesuser stories. .

MoŜe zdarzyć się sytuacja, Ŝe z niektórych istniejących MoŜe zdarzyć się sytuacja, Ŝe z niektórych istniejących user storiesuser storiestrzeba zrezygnować (po konsultacjach z klientem).trzeba zrezygnować (po konsultacjach z klientem).

release early, release often release early, release often ––

wczesne i częste wydaniawczesne i częste wydania



D. Rozdział zadańD. Rozdział zadań

Kiedy zakres iteracji został juŜ określony, cały zespół zbiera sKiedy zakres iteracji został juŜ określony, cały zespół zbiera się w celu ię w celu wyznaczenia osób odpowiedzialnych za poszczególne prace. wyznaczenia osób odpowiedzialnych za poszczególne prace.

Dla kaŜdej Dla kaŜdej user storyuser story wybierana jest para programistów, która będzie je wybierana jest para programistów, która będzie je realizować. W przypadku bardziej złoŜonych systemów wybieranych realizować. W przypadku bardziej złoŜonych systemów wybieranych jest kilka par.jest kilka par.

W ramach W ramach user storyuser story naleŜy wyodrębnić konkretne zadania. O ilenaleŜy wyodrębnić konkretne zadania. O ile user user storystory jest zapisem wymagań z punktu widzenia klienta, o tyle zadanie jest zapisem wymagań z punktu widzenia klienta, o tyle zadanie wyraŜa konkretne operacje, które wykonują uczestnicy projektu.wyraŜa konkretne operacje, które wykonują uczestnicy projektu.



Przykład dla Przykład dla user storyuser story::

2. [1] 2. [1] Osoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutOsoba Szukająca Pracy wprowadza dane niezbędne w procesie rekrutacji acji

(dane osobowe, dane o wykształceniu i doświadczeniu zawodowym)(dane osobowe, dane o wykształceniu i doświadczeniu zawodowym) [32 godz.][32 godz.]

Aby ją zrealizować, moŜna wyróŜnić następujące zadania:Aby ją zrealizować, moŜna wyróŜnić następujące zadania:�� stworzenie modelu danych w postaci diagramu(stworzenie modelu danych w postaci diagramu(--ów) UML;ów) UML;

�� zaprototypowanie interfejsu uŜytkownika w postaci ołówkowych szkzaprototypowanie interfejsu uŜytkownika w postaci ołówkowych szkiców;iców;

�� implementacja operacji bazodanowych;implementacja operacji bazodanowych;

�� implementacja logiki aplikacji;implementacja logiki aplikacji;

�� integracja pozostałych elementów user story.integracja pozostałych elementów user story.

Zadania dobiera się tak, aby były od siebie jak najmniej zaleŜneZadania dobiera się tak, aby były od siebie jak najmniej zaleŜne, a jeśli , a jeśli są zaleŜne, ustala się kolejność, w jakiej muszą zostać zrealizosą zaleŜne, ustala się kolejność, w jakiej muszą zostać zrealizowane. wane. NaleŜy teŜ ustalić terminy zakończenia zadań, w zaleŜności od NaleŜy teŜ ustalić terminy zakończenia zadań, w zaleŜności od oszacowanego uprzednio czasu implementacji danego user story.oszacowanego uprzednio czasu implementacji danego user story.



E. Implementacja.E. Implementacja.

Programiści tworzą kod parami.Programiści tworzą kod parami. Gdy jeden z nich pisze kod, drugi Gdy jeden z nich pisze kod, drugi spełnia rolę kontrolera (zgłasza poprawki, zadaje pytania wyjaśnspełnia rolę kontrolera (zgłasza poprawki, zadaje pytania wyjaśniające). iające). Co kilkadziesiąt minut się zmieniają. Co kilkadziesiąt minut się zmieniają.

Skład par nie jest ustalany raz Skład par nie jest ustalany raz na zawsze. na zawsze.

Czasem celowo miesza się Czasem celowo miesza się dobrego programistę ze dobrego programistę ze słabym, czy teŜ jedna osoba słabym, czy teŜ jedna osoba pisze test a druga kod, który pisze test a druga kod, który ten test powinien spełniać itp..ten test powinien spełniać itp..

Na rysunku propozycja układu Na rysunku propozycja układu biurek ;)biurek ;)



KaŜdy programista moŜe pracować nad dowolnym fragmentem kodu, KaŜdy programista moŜe pracować nad dowolnym fragmentem kodu, nad dowolnym zadaniem nad dowolnym zadaniem –– współwłasność kodu.współwłasność kodu.

Współwłasność zapobiega przywiązywaniu się do „swoich” zadań, Współwłasność zapobiega przywiązywaniu się do „swoich” zadań, wiedza o projekcie zostaje rozpropagowana pośród członków zespołwiedza o projekcie zostaje rozpropagowana pośród członków zespołu, u, a sam projekt staje się niejako własnością wszystkich. a sam projekt staje się niejako własnością wszystkich.

Wszyscy, poprzez odwołanie się do metafory, podzielają wspólną wWszyscy, poprzez odwołanie się do metafory, podzielają wspólną wizję izję projektu, będącą podstawą do tworzenia nazewnictwa i projektu, będącą podstawą do tworzenia nazewnictwa i porozumiewania się. porozumiewania się.

Taki system pracy wymaga stosowania Taki system pracy wymaga stosowania

jednolitego standardu kodowania w zespole.jednolitego standardu kodowania w zespole.

Dodatkowym elementem podtrzymującym integrację w zespole są Dodatkowym elementem podtrzymującym integrację w zespole są spotkania (spotkania (stand up meetingsstand up meetings), podczas których zespoły prezentują ), podczas których zespoły prezentują swoje dokonania oraz najbliŜsze plany.swoje dokonania oraz najbliŜsze plany.



F. Programowanie sterowane testami (Test Driven Development, F. Programowanie sterowane testami (Test Driven Development, TDD)TDD)

Geneza: zanim zapytamy "jak zrobić?", najpierw naleŜy odpowiedziGeneza: zanim zapytamy "jak zrobić?", najpierw naleŜy odpowiedzieć eć na pytanie "co naleŜy zrobić?"na pytanie "co naleŜy zrobić?"

Zanim klasa (lub inna podstawowa jednostka oprogramowania) Zanim klasa (lub inna podstawowa jednostka oprogramowania) zostanie zaimplementowana, najpierw naleŜy napisać do niej zestazostanie zaimplementowana, najpierw naleŜy napisać do niej zestaw w przypadków testowych (przypadków testowych (test casestest cases), które precyzują, jakiego zachowania ), które precyzują, jakiego zachowania oczekuje się po danej klasie. oczekuje się po danej klasie.

śaden kod nie moŜe powstać, dopóki nie istnieje test śaden kod nie moŜe powstać, dopóki nie istnieje test ––

najpierw pisany jest test, a potem kod, który ten test spełnianajpierw pisany jest test, a potem kod, który ten test spełnia

TDD będzie szczegółowo omówione na osobnym wykładzieTDD będzie szczegółowo omówione na osobnym wykładzie



Zalety TDD:Zalety TDD:

�� wysokie pokrycie kodu przez testywysokie pokrycie kodu przez testy

�� mniejszy stopień skomplikowania modułów (pisany jest tylko kod mniejszy stopień skomplikowania modułów (pisany jest tylko kod niezbędny do osiągnięcia wymaganej funkcjonalności)niezbędny do osiągnięcia wymaganej funkcjonalności)

�� łatwe odnajdywanie błędów łatwe odnajdywanie błędów

�� pełna automatyzacja testów pełna automatyzacja testów

�� wymuszanie na programistach dobrego projektu oraz odpowiedniej wymuszanie na programistach dobrego projektu oraz odpowiedniej dekompozycji problemudekompozycji problemu

Etapy (kroki) w TDD:Etapy (kroki) w TDD:

1. 1. Pisany jest testPisany jest test do nie istniejącego jeszcze kodudo nie istniejącego jeszcze kodu

2. 2. Pisany jest najprostszy kodPisany jest najprostszy kod, który sprawi, Ŝe test zadziała, który sprawi, Ŝe test zadziała

3. 3. Refaktoring koduRefaktoring kodu (zmiana implementacji bez zmiany (zmiana implementacji bez zmiany funkcjonalności) funkcjonalności) –– upewniamy się regularnie, czy test nadal działaupewniamy się regularnie, czy test nadal działa



G. RefaktoringG. Refaktoring

Stosuje się go, jeśli klasy nie moŜna w prosty sposób przetestowStosuje się go, jeśli klasy nie moŜna w prosty sposób przetestować oraz ać oraz wówczas, gdy staje się zbyt skomplikowana i nieczytelna. wówczas, gdy staje się zbyt skomplikowana i nieczytelna. Funkcjonalność się jednak nie zmienia!Funkcjonalność się jednak nie zmienia!

H. DokumentacjaH. Dokumentacja

Kod, przypadki testowe, komentarze są częścią dokumentacji projeKod, przypadki testowe, komentarze są częścią dokumentacji projektu. ktu. Zwykle nie wymaga się formalnej, skodyfikowanej dokumentacji, a Zwykle nie wymaga się formalnej, skodyfikowanej dokumentacji, a diagramy nie są wytycznymi projektu i pełnią funkcję pomocniczą.diagramy nie są wytycznymi projektu i pełnią funkcję pomocniczą.

I. Ciągła integracjaI. Ciągła integracja

KaŜda zaimplementowana funkcjonalność jest natychmiast KaŜda zaimplementowana funkcjonalność jest natychmiast integrowana z istniejącym juŜ kodem. W ten przyrostowy sposób integrowana z istniejącym juŜ kodem. W ten przyrostowy sposób kończona jest iteracja i bieŜąca wersja przekazywana jest klientkończona jest iteracja i bieŜąca wersja przekazywana jest klientowi. Jeśli owi. Jeśli niektóre z niektóre z user storiesuser stories nie zostały zaimplementowane, przechodzą do nie zostały zaimplementowane, przechodzą do kolejnej lub następnej iteracji.kolejnej lub następnej iteracji.

XP a inne zwinne metodyki INśYNIERIAOPROGRAMOWANIA

Najczęściej stosowane zwinne metodyki róŜnią się jedynie szczegóNajczęściej stosowane zwinne metodyki róŜnią się jedynie szczegółamiłami

Np. Np. stand up meeting (XP) oraz scrum meetingstand up meeting (XP) oraz scrum meeting (SCRUM) to róŜne (SCRUM) to róŜne nazwy codziennych spotkań grupy; nazwy codziennych spotkań grupy; user storyuser story (XP) to (XP) to product backlogproduct backlog(SCRUM) itp.(SCRUM) itp.

Drobne, przykładowe róŜniceDrobne, przykładowe róŜnice

�� Metafora (XP) Metafora (XP) –– Model (FDD)Model (FDD)

�� Współwłasność kodu (XP) Współwłasność kodu (XP) –– Współwłasność klasy (FDD)Współwłasność klasy (FDD)

�� Programowanie w parach (XP) Programowanie w parach (XP) –– Inspekcje kodu (FDD)Inspekcje kodu (FDD)

�� Brak formalnego zarządzania (XP) Brak formalnego zarządzania (XP) –– Oszczędne zarządzanie, raporty Oszczędne zarządzanie, raporty itp., Główny Programista (FDD) itp., Główny Programista (FDD) –– „ScrumMaster” (SCRUM)„ScrumMaster” (SCRUM)

�� Programowanie sterowane testami (XP) Programowanie sterowane testami (XP) –– testowanie do uznania testowanie do uznania Głównego Programisty (FDD)Głównego Programisty (FDD)

�� Krótkie iteracje (FDD, XP) Krótkie iteracje (FDD, XP) –– nieco dłuŜsze „sprinty” (SCRUM)nieco dłuŜsze „sprinty” (SCRUM)

Problemy i kontrowersje INśYNIERIAOPROGRAMOWANIA

�� Brak dokładnej specyfikacji…Brak dokładnej specyfikacji…

�� Brak szczegółowego projektu…Brak szczegółowego projektu…

… a w związku z tym trudności ze zrozumieniem projektu,… a w związku z tym trudności ze zrozumieniem projektu,

npnp. przy rotacjach kadrowych. przy rotacjach kadrowych

�� Krótka perspektywa planowaniaKrótka perspektywa planowania

�� Słaba przewidywalność kosztów wytworzenia systemuSłaba przewidywalność kosztów wytworzenia systemu

�� Konieczna stała dostępność przedstawiciela klientaKonieczna stała dostępność przedstawiciela klienta

�� Trudności z wyraŜeniem wymagań niefunkcjonalnychTrudności z wyraŜeniem wymagań niefunkcjonalnych

�� Nie przynosi korzyści przy średnich lub słabych programistach; dNie przynosi korzyści przy średnich lub słabych programistach; dobrzy programiści z obrzy programiści z kolei poradzą sobie w dowolnych warunkachkolei poradzą sobie w dowolnych warunkach

�� Trudności z ponownym uŜyciem koduTrudności z ponownym uŜyciem kodu

�� Trudności z konserwacją przez inny zespółTrudności z konserwacją przez inny zespół

�� Współwłasność kodu (XP) Współwłasność kodu (XP) –– kaŜdy moŜe zmieniać dowolny fragment systemukaŜdy moŜe zmieniać dowolny fragment systemu

�� Nie ma dokładnych i ogólnych wyliczeń, jak łączna wydajność pracNie ma dokładnych i ogólnych wyliczeń, jak łączna wydajność pracy zmienia się przy y zmienia się przy przejściu od tradycyjnego programowania indywidualnego do prograprzejściu od tradycyjnego programowania indywidualnego do programowaniu parami mowaniu parami (XP)(XP)


XPrince – równowaga między zwinnością a dyscypliną w projektach informatycznych


XPrinceXPrince –– eXtreme PRogramming IN Controlled EnvironmentseXtreme PRogramming IN Controlled Environments

(2004 r., Politechnika Poznańska), (2004 r., Politechnika Poznańska), http://xprince.net/http://xprince.net/

Jest połączeniem metodyk tradycyjnych (PRINCE2, RUP) z metodyką Jest połączeniem metodyk tradycyjnych (PRINCE2, RUP) z metodyką zwinną (XP)zwinną (XP)

W skrócie:W skrócie:

PRINCE2PRINCE2 ((Projects IN Controlled Environments) –– restrykcyjne, procesowe podejście restrykcyjne, procesowe podejście do zarządzania projektami; podział na etapy zarządcze i realizacdo zarządzania projektami; podział na etapy zarządcze i realizacyjne; Kierownik yjne; Kierownik Projektu i Komitet Sterujący; raporty itp.Projektu i Komitet Sterujący; raporty itp.

RUP RUP ((Rational Unified Process) – iteracyjny, ale klasyczny proces tworzenia oprogramowania (z pełną dokumentacją, analizą zagroŜeń itp.)

XPrince – organizacja zespołu INśYNIERIAOPROGRAMOWANIA

Komitet Sterujący (Project Board):Komitet Sterujący (Project Board):

�� DyrektorDyrektor (Executive) (Executive) –– przedstawiciel inwestoraprzedstawiciel inwestora

�� Główny UŜytkownikGłówny UŜytkownik (Senior User) (Senior User) –– kieruje kieruje uŜytkownikami końcowymi, skupia się na uŜytkownikami końcowymi, skupia się na uŜytecznościuŜyteczności

�� Główny DostawcaGłówny Dostawca (Senior Supplier) (Senior Supplier) –– reprezentuje reprezentuje wytwórcęwytwórcę

�� MenadŜer ProjektuMenadŜer Projektu (Project Manager) (Project Manager) –– odpowiada odpowiada za taktyczny poziom zarządzaniaza taktyczny poziom zarządzania

�� Audytor ProjektuAudytor Projektu (Project Assurance) (Project Assurance) –– kontrola kontrola działań MenedŜera Projektudziałań MenedŜera Projektu

�� AnalitykAnalityk (Analyst) (Analyst) –– odpowiada za specyfikacjęodpowiada za specyfikację

�� ArchitektArchitekt (Architect) (Architect) –– odpowiada za techniczne odpowiada za techniczne aspekty projektuaspekty projektu

�� ProgramiściProgramiści (Developers)(Developers)

XPrince – cykl Ŝycia systemu INśYNIERIAOPROGRAMOWANIA

a)a) PRINCE2PRINCE2

b)b) RUPRUP

c)c) XPXP

d)d) XPrinceXPrince

XPrince – opis poszczególnych faz (1) INśYNIERIAOPROGRAMOWANIA

�� Rozpoczęcie projektuRozpoczęcie projektu� Ustanowienie zespołu zarządzania projektem

� Stworzenie wizji systemu, zawierającej wstępne argumenty biznesowe

�� Inicjacja projektuInicjacja projektu� Zrozumienie, co naleŜy zbudować. Budowa modelu biznesowego bazującego na

przypadkach uŜycia, zdefiniowanie problemów, które naleŜy rozwiązać oraz najwaŜniejszej funkcjonalności wymaganej do rozwiązania tych problemów. Opracowanie listy kryteriów jakości i produktów. Ocena ryzyka. (Analityk)

� Propozycja początkowej architektury (krótki, wysokopoziomowy opis, dostarczający informacji potrzebnej do zaplanowania projektu; lista potrzebnych narzędzi). (Architekt)

� Planowanie całego projektu i dopracowanie uzasadnienia biznesowego. Plan projektu pokazuje projekt ze strategicznego punktu widzenia. W celu wspierania „zwinności”, plan powinien uwzględniać priorytety, precyzować liczbę wydań i przydzielać do nich funkcjonalność (przypadki uŜycia na wysokim poziomie). Im dłuŜszy projekt, tym plan projektu powinien być mniej konkretny. Faktyczne planowanie powinno się odbywać na poziomie wydań. (MenadŜer Projektu)


�� Inicjacja projektu (c.d.)Inicjacja projektu (c.d.)� Ustalenie kanałów komunikacyjnych i środowiska zarządzania projektem. Kanały

komunikacyjne obejmują raporty (np. wyniki cotygodniowych testów akceptacyjnych). Środowisko zarządzania projektem moŜe być klasyczne, bazujące na plikach i dokumentach, lub moŜe być wspomagane zaawansowanymi narzędziami. (MenadŜer Projektu).

� Elaboracja� Faza Elaboracji dotyczy głównie architektury. Architekt powinien zaproponować

mechanizmy architektoniczne, rozpoznać ryzyko z tym związane (np. za pomocą eksperymentów) oraz stworzyć szkielet, który będzie wykorzystywany przez Programistów. Analityk i MenadŜer Projektu w tej fazie udoskonalają wymagania i plan projektu.


� Wydanie� Na tym etapie proces wytwarzania oprogramowania bardzo przypomina XP.

� Architekt i Programiści produkują kod i przypadki testowe.

� KaŜde wydanie składa się z kilku przyrostów, przyrost jest jedynie wewnętrznym punktem kontrolnym. KaŜdy przyrost powinien być tak samo długi – to pomaga Programistom czuć rytm iteracji oraz w rezultacie nauczyć się lepiej planować przyrosty.

� Analityk jest odpowiedzialny za wymagania i testy akceptacyjne, jak równieŜ gra rolę klienta będącego na miejscu.

� KaŜde Wydanie jest zakończone fazą tranzycji, w której nowa wersja systemu jest wdraŜana i przekazywana uŜytkownikom końcowym.

� Zamknięcie projektu � Projekt jest zamykany, identyfikowane są dalsze akcje i następuje ocena projektu.

XPrince – podsumowanie (1) INśYNIERIAOPROGRAMOWANIA

�� Jest zwinnaJest zwinna

XPrince przyjmuje podstawowe załoŜenie metodyki XP XPrince przyjmuje podstawowe załoŜenie metodyki XP –– jest nastawiona na jak jest nastawiona na jak najszybsze stworzenie działającego produktu, etapy są w niej krónajszybsze stworzenie działającego produktu, etapy są w niej krótkie, a zarządzanie tkie, a zarządzanie zmianami praktykowane przez cały czas trwania projektu. Dzięki tzmianami praktykowane przez cały czas trwania projektu. Dzięki temu klient emu klient otrzymuje szybko kolejne wersje produktu i ma stałą kontrolę jegotrzymuje szybko kolejne wersje produktu i ma stałą kontrolę jego zakresu.o zakresu.

�� Posiada mechanizmy kontroliPosiada mechanizmy kontroli

XPrince kontroluje projekt na róŜnych poziomach. Kontrolowane sąXPrince kontroluje projekt na róŜnych poziomach. Kontrolowane są zmiany, zmiany, kontrolowane jest ryzyko, kontrolowana jest jakość produktu a takontrolowane jest ryzyko, kontrolowana jest jakość produktu a takŜe jakość pracy kŜe jakość pracy kierownika projektu. Zarząd przedsięwzięcia jest odseparowany odkierownika projektu. Zarząd przedsięwzięcia jest odseparowany od codziennej pracy codziennej pracy w projekcie i kontroluje go na podstawie informacji od kierownikw projekcie i kontroluje go na podstawie informacji od kierownika projektu. a projektu. Rzetelność informacji przekazywanych przed kierownika projektu jRzetelność informacji przekazywanych przed kierownika projektu jest weryfikowana est weryfikowana przez kontrolę projektu.przez kontrolę projektu.

�� Zachowuje optymalny poziom dokumentacji technicznejZachowuje optymalny poziom dokumentacji technicznejXPrince zakłada dokumentowanie wymagań w postaci przypadków uŜycXPrince zakłada dokumentowanie wymagań w postaci przypadków uŜycia systemu ia systemu oraz innych diagramów UML. Są to metody sprawdzone i popularne, oraz innych diagramów UML. Są to metody sprawdzone i popularne, dzięki czemu dzięki czemu skraca się czas wdroŜenia metodyki.skraca się czas wdroŜenia metodyki.

XPrince – podsumowanie (2) INśYNIERIAOPROGRAMOWANIA

�� Ma prostą i efektywną strukturę organizacyjnąMa prostą i efektywną strukturę organizacyjnąXPrince wprowadza przejrzysty podział ról w procesie. HierarchiaXPrince wprowadza przejrzysty podział ról w procesie. Hierarchia w jest w jest zminimalizowana, a odpowiedzialność za elementy procesu praktyczzminimalizowana, a odpowiedzialność za elementy procesu praktycznie podzielona. nie podzielona. Wprowadzone są Wprowadzone są npnp. role głównego analityka, odpowiadającego za biznesowe . role głównego analityka, odpowiadającego za biznesowe czynniki ryzyka i architekta, odpowiadającego za ryzyko technoloczynniki ryzyka i architekta, odpowiadającego za ryzyko technologiczne (obie role giczne (obie role zaczerpnięto z metodyki RUP). Ich zwierzchnikiem jest kierownik zaczerpnięto z metodyki RUP). Ich zwierzchnikiem jest kierownik projektu, który projektu, który zarządza ryzykiem całego projektu, kierując się sygnałami od obuzarządza ryzykiem całego projektu, kierując się sygnałami od obu specjalistów.specjalistów.

�� Wykorzystuje zwinne praktyki programistyczneWykorzystuje zwinne praktyki programistyczneXPrince zaczerpnęło z XP zestaw dobrych praktyk programistycznycXPrince zaczerpnęło z XP zestaw dobrych praktyk programistycznych. Zarządzanie h. Zarządzanie wersjami, ciągła integracja, testy jednostkowe, testy akceptacyjwersjami, ciągła integracja, testy jednostkowe, testy akceptacyjne, implementacja ne, implementacja kierowana testami (ang. TDD kierowana testami (ang. TDD –– Test Driven Development) to praktyki zapewniające Test Driven Development) to praktyki zapewniające wysoką jakość produktu. Z XP przejęte zostało takŜe opracowanie wysoką jakość produktu. Z XP przejęte zostało takŜe opracowanie rozwiązań rozwiązań próbnych (ang. spike solution), które w XPrince stosuje się na ppróbnych (ang. spike solution), które w XPrince stosuje się na początku projektu, w oczątku projektu, w fazie opracowania architektury. Dopuszcza programowanie indywidufazie opracowania architektury. Dopuszcza programowanie indywidualne, w parach alne, w parach jak równieŜ „side by side”.jak równieŜ „side by side”.

Schemat zajęć laboratoryjnych z IO / OA (model kaskadowy)


Schemat zajęć laboratoryjnych z IO / OA (model przyrostowy)


Documents

Zwinne metodyki tworzenia oprogramowania. Programowanie ... · Zwinne metodyki tworzenia oprogramowania. ... są bardzo potrzebne do budowy skomplikowanych systemów ze ... Manifesto