Metodyka Extreme Programming: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
(LinkTitles.) |
||
| Linia 16: | Linia 16: | ||
'''Extreme Programming''' (skrót '''XP''', pol. '''Programowanie ekstremalne''') jedna ze zwinnych [[metodyka|metodyk]] tworzenia oprogramowania, która podkreśla prostotę, odwagę, informację zwrotną i komunikację. Częściowo jest reakcją na panujące przekonanie, że zmiana jest zła i powinno się jej unikać. <ref name="Chromatic 2003">Chromatic, ''Extreme Programming Pocket Guide: Team-Based Software Development'', O'Reilly Media 2003, str. XI</ref> Metodyka ta uważana jest również za lekki, wydajny, mało ryzykowny, elastyczny, przewidywalny, naukowy i przyjemny sposób tworzenia oprogramowania. <ref name="Beck K. 2000">Beck K., ''Extreme Programming Explained: Embrace Change'', Addison-Wesley Longman Publishing, Boston, 2000, str. XVII</ref> | '''Extreme Programming''' (skrót '''XP''', pol. '''[[Programowanie]] ekstremalne''') jedna ze zwinnych [[metodyka|metodyk]] tworzenia oprogramowania, która podkreśla prostotę, odwagę, informację zwrotną i komunikację. Częściowo jest reakcją na panujące przekonanie, że [[zmiana]] jest zła i powinno się jej unikać. <ref name="Chromatic 2003">Chromatic, ''Extreme Programming Pocket Guide: Team-Based Software Development'', O'Reilly Media 2003, str. XI</ref> [[Metodyka]] ta uważana jest również za lekki, wydajny, mało ryzykowny, elastyczny, przewidywalny, naukowy i przyjemny sposób tworzenia oprogramowania. <ref name="Beck K. 2000">Beck K., ''Extreme Programming Explained: Embrace Change'', Addison-Wesley Longman Publishing, Boston, 2000, str. XVII</ref> | ||
==Historia== | ==Historia== | ||
W połowie lat dziewięćdziesiątych inżynierowie zaczęli obserwować rosnący trend programowania w parach wśród zespołów projektowych, co przekładało się na szybsze i lepsze jakościowo pisanie kodu. W niedługim czasie, popularny stał się termin programowania ekstremalnego, który zyskał popularność dzięki dwóm amerykańskim inżynierom: Ron Jeffries i Kent Beck. Opracowali oni projekt płacowy dla firmy Chrysler Comprehensive System. Projekt okazał się dużym sukcesem, dlatego też Kent Beck postanowił spopularyzować wykorzystaną metodykę publikując w 1999 roku książkę zatytułowaną "eXtreme Programming eXplained”. Pozycja do dnia dzisiejszego doczekała się kilku wydań i może być traktowana jako swoisty manifest tego ruchu. Od lat dziewięćdziesiątych programowanie ekstremalne zaczęło ewoluować, a proces ten trwa po dziś dzień. <ref name="Rosenberg D. 2003">Rosenberg D., ''Extreme Programming Refactored: The Case Against XP'', Apress, 2003, str. 39</ref> | W połowie lat dziewięćdziesiątych inżynierowie zaczęli obserwować rosnący [[trend]] programowania w parach wśród zespołów projektowych, co przekładało się na szybsze i lepsze jakościowo pisanie kodu. W niedługim czasie, popularny stał się termin programowania ekstremalnego, który zyskał popularność dzięki dwóm amerykańskim inżynierom: Ron Jeffries i Kent Beck. Opracowali oni [[projekt]] płacowy dla firmy Chrysler Comprehensive [[System]]. Projekt okazał się dużym sukcesem, dlatego też Kent Beck postanowił spopularyzować wykorzystaną metodykę publikując w 1999 roku książkę zatytułowaną "eXtreme Programming eXplained”. [[Pozycja]] do dnia dzisiejszego doczekała się kilku wydań i może być traktowana jako swoisty [[manifest]] tego ruchu. Od lat dziewięćdziesiątych programowanie ekstremalne zaczęło ewoluować, a [[proces]] ten trwa po dziś dzień. <ref name="Rosenberg D. 2003">Rosenberg D., ''Extreme Programming Refactored: The Case Against XP'', Apress, 2003, str. 39</ref> | ||
<google>t</google> | <google>t</google> | ||
| Linia 25: | Linia 25: | ||
==Nazewnictwo== | ==Nazewnictwo== | ||
Nazwa metodyki programowania ekstremalnego wzięła się od pytania, które postawił sobie Kent Beck: ''Co by się stało, gdyby wziąć każdą technikę i realizować ją do granic rozsądku?'' W rezultacie zostały wysunięte następujące wnioski: | Nazwa metodyki programowania ekstremalnego wzięła się od pytania, które postawił sobie Kent Beck: ''Co by się stało, gdyby wziąć każdą technikę i realizować ją do granic rozsądku?'' W rezultacie zostały wysunięte następujące wnioski: | ||
* Przegląd kodu (ang. code review) jest skuteczny, ponieważ kod jest weryfikowany w sposób ciągły. | * [[Przegląd]] kodu (ang. code review) jest skuteczny, ponieważ kod jest weryfikowany w sposób ciągły. | ||
* Testowanie kodu jest skuteczne, ponieważ testy regresyjne i integracyjne są przeprowadzane kilka razy dziennie. | * Testowanie kodu jest skuteczne, ponieważ testy regresyjne i integracyjne są przeprowadzane kilka razy dziennie. | ||
* Design kodu jest skuteczny, ponieważ każdy musi codziennie refaktoryzować (ang. refactoring) swój kod. | * Design kodu jest skuteczny, ponieważ każdy musi codziennie refaktoryzować (ang. [[refactoring]]) swój kod. | ||
* Krótkie iteracje są skuteczne, ponieważ planowanie odbywa się na początku każdej iteracji. | * Krótkie iteracje są skuteczne, ponieważ [[planowanie]] odbywa się na początku każdej iteracji. | ||
Wyżej wyszczególnione dobre praktyki wspierają projektowanie prostych, efektywnych, maksymalizujących wartość biznesową aplikacji. Jednakże, odpowiednie i kompleksowe wdrożenie metodyki programowania ekstremalnego wymaga wysokiego poziomu umiejętności, dyscypliny oraz pracy zespołowej.<ref name="Coffin D. 2003">Coffin D., ''A Practical Guide to Seven Agile Methodologies. Part 1.'', Devx.com, 2006, str. 2</ref> | Wyżej wyszczególnione [[dobre praktyki]] wspierają [[projektowanie]] prostych, efektywnych, maksymalizujących [[wartość]] biznesową aplikacji. Jednakże, odpowiednie i kompleksowe [[wdrożenie]] metodyki programowania ekstremalnego wymaga wysokiego poziomu [[umiejętności]], dyscypliny oraz pracy zespołowej.<ref name="Coffin D. 2003">Coffin D., ''A Practical Guide to Seven Agile Methodologies. Part 1.'', Devx.com, 2006, str. 2</ref> | ||
==Istota Programowania Ekstremalnego== | ==Istota Programowania Ekstremalnego== | ||
Wiele metod tworzenia oprogramowania uznaje, że zmiana jest kosztowna. Błąd znaleziony w fazie utrzymania projektu zwykle kosztuje więcej, niż błąd znaleziony w fazie planowania, czy tworzenia oprogramowania. Programowanie ekstremalne wychodzi naprzeciw oczekiwaniom i próbuje obniżyć koszty zmiany wymagań poprzez zastosowanie krótkich cykli iteracyjnych. Metodyka ta uznaje zmianę jako rzecz nieuniknioną, wręcz naturalną w procesie tworzenia oprogramowania, dlatego powinna być dobrze zaplanowana. Określenie stabilnego zestawu wymagań w przypadku tej metodyki jest niemożliwe.<ref name="Chromatic 2003"/> | Wiele metod tworzenia oprogramowania uznaje, że zmiana jest kosztowna. [[Błąd]] znaleziony w fazie utrzymania projektu zwykle kosztuje więcej, niż błąd znaleziony w fazie planowania, czy tworzenia oprogramowania. Programowanie ekstremalne wychodzi naprzeciw oczekiwaniom i próbuje obniżyć [[koszty]] zmiany wymagań poprzez zastosowanie krótkich cykli iteracyjnych. Metodyka ta uznaje zmianę jako rzecz nieuniknioną, wręcz naturalną w procesie tworzenia oprogramowania, dlatego powinna być dobrze zaplanowana. Określenie stabilnego zestawu wymagań w przypadku tej metodyki jest niemożliwe.<ref name="Chromatic 2003"/> | ||
==Wartości metodyki== | ==Wartości metodyki== | ||
Metoda programowania ekstremalnego oparta jest na kilku podstawowych wartościach: | [[Metoda]] programowania ekstremalnego oparta jest na kilku podstawowych wartościach: | ||
* '''komunikacja''' - odgrywa ważną rolę w sukcesie projektu. W metodach tradycyjnych używa się na szeroką skalę dokumentacji, czego zazwyczaj brakuje w XP, ze względu m.in. na szybkie zmiany wymagań. Celem komunikacji w programowaniu ekstremalnym jest przedstawienie wszystkim programistom wspólnego, jednolitego i prostego poglądu na projekt. Dlatego też, w programowaniu ekstremalnym wykorzystuje się proste modele, współpracę użytkowników z inżynierami, częstą komunikację werbalną, czy odpowiedź zwrotną. | * '''komunikacja''' - odgrywa ważną rolę w sukcesie projektu. W metodach tradycyjnych używa się na szeroką skalę dokumentacji, czego zazwyczaj brakuje w XP, ze względu m.in. na szybkie zmiany wymagań. Celem komunikacji w programowaniu ekstremalnym jest przedstawienie wszystkim programistom wspólnego, jednolitego i prostego poglądu na projekt. Dlatego też, w programowaniu ekstremalnym wykorzystuje się proste [[modele]], współpracę użytkowników z inżynierami, częstą komunikację werbalną, czy odpowiedź zwrotną. | ||
* '''prostota''' - budowanie tylko takich systemów, które muszą być rzeczywiście zbudowane. Złożoność systemów dużo kosztuje a przewidywanie przyszłości jest trudne. Często spotykaną zasadą wykorzystywaną w tej metodzie jest KISS, czyli ‘Keep It Simple, Stupid!’ (ang. nie komplikuj, głupcze). | * '''prostota''' - budowanie tylko takich systemów, które muszą być rzeczywiście zbudowane. [[Złożoność]] systemów dużo kosztuje a przewidywanie przyszłości jest trudne. Często spotykaną zasadą wykorzystywaną w tej metodzie jest KISS, czyli ‘Keep It Simple, Stupid!’ (ang. nie komplikuj, głupcze). | ||
* '''informacja zwrotna''' - dzięki krótkim iterakcjom produkt jest dostarczany wcześnie do klienta, który wydaje opinię na temat postępów pracy oraz jest w stanie dostarczyć informację zwrotną np. aby wprowadzić potrzebną zmianę. Im szybciej informacja zwrotna będzie dostarczona, tym sprawniej będzie można zareagować na daną zmianę. Dlatego ważne jest, aby zadawać pytania i uczyć się z udzielonych na nie odpowiedzi. | * '''[[informacja]] zwrotna''' - dzięki krótkim iterakcjom [[produkt]] jest dostarczany wcześnie do klienta, który wydaje opinię na temat postępów pracy oraz jest w stanie dostarczyć informację zwrotną np. aby wprowadzić potrzebną zmianę. Im szybciej [[informacja zwrotna]] będzie dostarczona, tym sprawniej będzie można zareagować na daną zmianę. Dlatego ważne jest, aby zadawać pytania i uczyć się z udzielonych na nie odpowiedzi. | ||
* '''odwaga''' - podejmowanie ciężkich decyzji, gdy jest to konieczne. Jeśli dana funkcjonalność nie działa, należy ją naprawić. Jeśli zbliża się termin dostarczenia, a praca nie idzie zgodnie z harmonogramem, należy powiedzieć o tym klientowi. Nikt nie lubi łamać obietnic, jednakże w takim przypadku należy przyznać się do winy i naprawić to jak najszybciej. | * '''odwaga''' - podejmowanie ciężkich decyzji, gdy jest to konieczne. Jeśli dana funkcjonalność nie działa, należy ją naprawić. Jeśli zbliża się termin dostarczenia, a [[praca]] nie idzie zgodnie z harmonogramem, należy powiedzieć o tym klientowi. Nikt nie lubi łamać obietnic, jednakże w takim przypadku należy przyznać się do winy i naprawić to jak najszybciej. | ||
==Najlepsze praktyki metodyki== | ==Najlepsze praktyki metodyki== | ||
W metodzie programowania ekstremalnego wyróżniono 12 praktyk, które można podzielić na 4 obszary. Praktyki te pomagają podejmować decyzję oraz osiągać wysoką jakość i produktywność. <ref name="Beck K. 2000"/><ref name="Chromatic 2003"/> | W metodzie programowania ekstremalnego wyróżniono 12 praktyk, które można podzielić na 4 obszary. Praktyki te pomagają podejmować decyzję oraz osiągać wysoką [[jakość]] i [[produktywność]]. <ref name="Beck K. 2000"/><ref name="Chromatic 2003"/> | ||
===== Planowanie ===== | ===== Planowanie ===== | ||
W odróżnieniu od tradycyjnych metod, gdzie proces planowania jest długotrwały i skomplikowany, w metodzie programowania ekstremalnego planowany jest krótki odcinek czasu w najbliższej przyszłości. | W odróżnieniu od tradycyjnych metod, gdzie [[proces planowania]] jest długotrwały i skomplikowany, w metodzie programowania ekstremalnego planowany jest krótki odcinek czasu w najbliższej przyszłości. | ||
* '''gra planistyczna''' - ma miejsca na początku każdej iteracji. Celem gry jest określenie zakresu pracy na najbliższy okres poprzez umiejętne połączenie decyzji biznesowych i technicznej estymacji. | * '''gra planistyczna''' - ma miejsca na początku każdej iteracji. Celem gry jest określenie zakresu pracy na najbliższy okres poprzez umiejętne połączenie decyzji biznesowych i technicznej estymacji. | ||
* '''metafora''' - przedstawienie projektu w prosty sposób, aby zarówno zespół programistyczny był świadom, jak ich funkcjonalność oddziałuje na całość systemu, ale również, aby klient, który często nie jest osobą techniczną, mógł w pełni zrozumieć zachowania systemu | * '''metafora''' - przedstawienie projektu w prosty sposób, aby zarówno [[zespół]] programistyczny był świadom, jak ich funkcjonalność oddziałuje na całość systemu, ale również, aby [[klient]], który często nie jest osobą techniczną, mógł w pełni zrozumieć zachowania systemu | ||
* '''udział klienta w zespole''' - klient jest integralnym członkiem zespołu, z którym pozostaje w ciągłym kontakcie. Ma dostęp do najbardziej aktualnej wersji produktu, dzięki czemu jest w stanie dostarczyć szybką informację zwrotną i podjąć decyzję projektową. | * '''[[udział]] klienta w zespole''' - klient jest integralnym członkiem zespołu, z którym pozostaje w ciągłym kontakcie. Ma dostęp do najbardziej aktualnej wersji produktu, dzięki czemu jest w stanie dostarczyć szybką informację zwrotną i podjąć decyzję projektową. | ||
===== Projektowanie ===== | ===== Projektowanie ===== | ||
Proces projektowania jest ściśle powiązany z programowaniem, dlatego też projekt powstaje tuż przed etapem kodowania. Projektowane rozwiązania powinny być przejrzyste, aby programista w prosty sposób mógł zaimplementować daną funkcjonalność. Przejrzystość jest tym bardziej ważna, gdyż kod programu w przypadku programowania ekstremalnego jest równocześnie jego dokumentacją. | [[Proces projektowania]] jest ściśle powiązany z programowaniem, dlatego też projekt powstaje tuż przed etapem kodowania. Projektowane rozwiązania powinny być przejrzyste, aby programista w prosty sposób mógł zaimplementować daną funkcjonalność. Przejrzystość jest tym bardziej ważna, gdyż kod programu w przypadku programowania ekstremalnego jest równocześnie jego dokumentacją. | ||
* '''prostota projektu''' - system powinien być zaprojektowany najprościej, jak to tylko możliwe w danym momencie. Dodatkowa złożoność jest usuwana w momencie jej identyfikacji. | * '''prostota projektu''' - system powinien być zaprojektowany najprościej, jak to tylko możliwe w danym momencie. Dodatkowa złożoność jest usuwana w momencie jej identyfikacji. | ||
| Linia 57: | Linia 57: | ||
W programowaniu ekstremalnym kodowanie jest uważane za najważniejszy etap. Programowanie zabiera najwięcej czasu i kod stworzony w tym procesie nadaje kształt finalnemu produktowi projektu. | W programowaniu ekstremalnym kodowanie jest uważane za najważniejszy etap. Programowanie zabiera najwięcej czasu i kod stworzony w tym procesie nadaje kształt finalnemu produktowi projektu. | ||
* '''częste wydania''' - klient musi otrzymywać najnowszą wersję programu w krótkich odstępach czasowych (średnio 2 tyg.). Dzięki temu jest w stanie stwierdzić, czy funkcjonalności zostały poprawnie zaimplementowane. | * '''częste wydania''' - klient musi otrzymywać najnowszą wersję programu w krótkich odstępach czasowych (średnio 2 tyg.). Dzięki temu jest w stanie stwierdzić, czy funkcjonalności zostały poprawnie zaimplementowane. | ||
* '''refaktoryzacja''' - restrukturyzacja kodu przez programistów poprzez usuwanie duplikacji, poprawianie komunikacji, czy dodawanie elastyczności. | * '''refaktoryzacja''' - [[restrukturyzacja]] kodu przez programistów poprzez usuwanie duplikacji, poprawianie komunikacji, czy dodawanie elastyczności. | ||
* ''' | * '''współ[[własność]] kodu''' - każdy programista może zmieniać kod w dowolnym miejscu i w dowolnym momencie. Może to nieść za sobą negatywne skutki, ponieważ rozmywa się [[odpowiedzialność]], ale w zamian za to, znacząco upraszcza procedurę wprowadzania zmian. | ||
* '''ciągła integracja''' - każda nowa funkcjonalność musi szybko być zintegrowana zresztą systemu, a nowa wersja produktu powinna być zbudowana przynajmniej raz dziennie. | * '''ciągła integracja''' - każda nowa funkcjonalność musi szybko być zintegrowana zresztą systemu, a nowa wersja produktu powinna być zbudowana przynajmniej raz dziennie. | ||
* '''brak nadgodzin''' - praktyka mówi, aby programista nie pracował więcej, niż 40 godzin tygodniowo. Nadgodziny negatywnie wpływają na koncentrację programisty, a co za tym idzie, jakość pisanego kodu. | * '''brak nadgodzin''' - praktyka mówi, aby programista nie pracował więcej, niż 40 godzin tygodniowo. [[Nadgodziny]] negatywnie wpływają na koncentrację programisty, a co za tym idzie, jakość pisanego kodu. | ||
* '''standard kodowania''' - zapobiega tworzeniu niespójnego kodu, ponieważ każdy programista ma swoje przyzwyczajenia i praktyki. | * '''standard kodowania''' - zapobiega tworzeniu niespójnego kodu, ponieważ każdy programista ma swoje przyzwyczajenia i praktyki. | ||
* '''programowanie w parach''' - programiści piszą kod w parach na jednym komputerze. W momencie gdy jeden z nich programuje, drugi sprawdza powstający kod, sugeruje rozwiązania lub zadaje pytania. | * '''programowanie w parach''' - programiści piszą kod w parach na jednym komputerze. W momencie gdy jeden z nich programuje, drugi sprawdza powstający kod, sugeruje rozwiązania lub zadaje pytania. | ||
| Linia 69: | Linia 69: | ||
== Zalety i funkcje metodyki == | == Zalety i funkcje metodyki == | ||
Wyżej opisane wartości opisują [[cel]], który przyświeca Ekstremalnemu programowaniu: tworzenie oprogramowania o wysokiej jakości za pomocą prostych środków, przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na [[potrzeby]] klienta oraz odważnym podejmowaniu trudnych decyzji. Praktyki XP stanowią swoistą implementację tych wartości. Mimo pozornej dowolności w doborze, są one ściśle związane ze sobą i wspólnie realizują założone [[cele]] metodyki. Pierwszą zaletą w XP jest [[komunikacja]] ustna (brak tworzenia dokumentacji). Zbudowanie [[Informatyczny system zarządzania|systemu informatycznego]] wymaga przekazania wymagań od klienta do programistów. W tradycyjnych metodykach (np. [[Metodyka PRINCE II|PRINCE]]) wykorzystuje się w tym celu dokumenty. Programowanie ekstremalne odróżnia się tym od innych metodologii (zwinnych czy tradycyjnych) że kładzie nacisk na testowanie czyli przed napisaniem właściwego kodu należy zaimplementować dla niego wszystkie testy, przetestować każdy jego fragment. XP posługuje się komunikacją werbalną co zapewnia lepsze i bardzo szybkie rozprzestrzenianie się wiedzy o systemie w zespole. Poprzez dobrą komunikacje wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego [[System operacyjny|systemu]] i wiedzą w jakim kierunku projekt dąży. Kolejną zaletą jest prostota. Programowanie ekstremalne zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu (minimalnym, spełniającym pewne początkowe wymagania). Kiedy uda się upewnić że się idzie w dobrym kierunku rozwiązania, na tej podstawie dobudowuje się resztę. Metodyka wprowadza brak inspekcji bowiem zastępuje je programowanie parami (jedna osoba pisze kod, a druga na bieżąco kontroluje pracę partnera). Programiści piszą w dwójkach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w dwójkach zamieniają się miejscami co pewien czas np. co kilkadziesiąt minut. Taka [[technika]] umożliwia wyłapanie wielu błędów oraz wzajemną naukę <ref name="ReferenceA">Koszlajda A., ''Zarządzanie Projektami IT. Przewodnik Po Metodykach.'', Helion, Gliwice 2010, str. 179 - 187.</ref><ref>Wróblewski P., ''[[Zarządzanie projektami]] informatycznymi dla praktyków. Podstawowe techniki zarządzania projektami przedstawione bez zbędnej teorii'', Helion, Gliwice 2005, str. 181 - 182.</ref>. | Wyżej opisane wartości opisują [[cel]], który przyświeca Ekstremalnemu programowaniu: tworzenie oprogramowania o wysokiej jakości za pomocą prostych środków, przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na [[potrzeby]] klienta oraz odważnym podejmowaniu trudnych decyzji. Praktyki XP stanowią swoistą implementację tych wartości. Mimo pozornej dowolności w doborze, są one ściśle związane ze sobą i wspólnie realizują założone [[cele]] metodyki. Pierwszą zaletą w XP jest [[komunikacja]] ustna (brak tworzenia dokumentacji). Zbudowanie [[Informatyczny system zarządzania|systemu informatycznego]] wymaga przekazania wymagań od klienta do programistów. W tradycyjnych metodykach (np. [[Metodyka PRINCE II|PRINCE]]) wykorzystuje się w tym celu dokumenty. Programowanie ekstremalne odróżnia się tym od innych metodologii (zwinnych czy tradycyjnych) że kładzie nacisk na testowanie czyli przed napisaniem właściwego kodu należy zaimplementować dla niego wszystkie testy, przetestować każdy jego fragment. XP posługuje się komunikacją werbalną co zapewnia lepsze i bardzo szybkie rozprzestrzenianie się wiedzy o systemie w zespole. Poprzez dobrą komunikacje wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego [[System operacyjny|systemu]] i wiedzą w jakim kierunku projekt dąży. Kolejną zaletą jest prostota. Programowanie ekstremalne zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu (minimalnym, spełniającym pewne początkowe wymagania). Kiedy uda się upewnić że się idzie w dobrym kierunku rozwiązania, na tej podstawie dobudowuje się resztę. Metodyka wprowadza brak inspekcji bowiem zastępuje je [[programowanie parami]] (jedna osoba pisze kod, a druga na bieżąco kontroluje pracę partnera). Programiści piszą w dwójkach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w dwójkach zamieniają się miejscami co pewien czas np. co kilkadziesiąt minut. Taka [[technika]] umożliwia wyłapanie wielu błędów oraz wzajemną naukę <ref name="ReferenceA">Koszlajda A., ''[[Zarządzanie]] Projektami IT. Przewodnik Po Metodykach.'', Helion, Gliwice 2010, str. 179 - 187.</ref><ref>Wróblewski P., ''[[Zarządzanie projektami]] informatycznymi dla praktyków. Podstawowe techniki zarządzania projektami przedstawione bez zbędnej teorii'', Helion, Gliwice 2005, str. 181 - 182.</ref>. | ||
== Wady == | == Wady == | ||
Wady jakie można zważyć w tej metodyce to brak dokładnej specyfikacji, stała dostępność przedstawiciela klienta – co jest dość trudne do wykonania, wspólna "własność" kodu - każdy może zmieniać dowolny fragment systemu, brak struktur i procedur dokumentacyjnych, wymaga zmiany kulturowej w organizacji w celu wdrożenia. Komunikacja ustna pomimo że jest traktowana jako zaleta też ma wadę. Programiści stosujący metodyka XP po pewnym czasie mogą nie pamiętać, którą opcję rozwiązania wybrali i dlaczego właśnie tą (ponownie – przydałoby się posiadać udokumentowane wymagania) <ref name="ReferenceA"/>. | Wady jakie można zważyć w tej metodyce to brak dokładnej specyfikacji, stała [[dostępność]] przedstawiciela klienta – co jest dość trudne do wykonania, wspólna "własność" kodu - każdy może zmieniać dowolny fragment systemu, brak struktur i procedur dokumentacyjnych, wymaga zmiany kulturowej w organizacji w celu wdrożenia. Komunikacja ustna pomimo że jest traktowana jako zaleta też ma wadę. Programiści stosujący metodyka XP po pewnym czasie mogą nie pamiętać, którą opcję rozwiązania wybrali i dlaczego właśnie tą (ponownie – przydałoby się posiadać udokumentowane wymagania) <ref name="ReferenceA"/>. | ||
== Bibliografia == | == Bibliografia == | ||
Wersja z 06:40, 20 maj 2020
| Metodyka Extreme Programming |
|---|
| Polecane artykuły |
Extreme Programming (skrót XP, pol. Programowanie ekstremalne) jedna ze zwinnych metodyk tworzenia oprogramowania, która podkreśla prostotę, odwagę, informację zwrotną i komunikację. Częściowo jest reakcją na panujące przekonanie, że zmiana jest zła i powinno się jej unikać. [1] Metodyka ta uważana jest również za lekki, wydajny, mało ryzykowny, elastyczny, przewidywalny, naukowy i przyjemny sposób tworzenia oprogramowania. [2]
Historia
W połowie lat dziewięćdziesiątych inżynierowie zaczęli obserwować rosnący trend programowania w parach wśród zespołów projektowych, co przekładało się na szybsze i lepsze jakościowo pisanie kodu. W niedługim czasie, popularny stał się termin programowania ekstremalnego, który zyskał popularność dzięki dwóm amerykańskim inżynierom: Ron Jeffries i Kent Beck. Opracowali oni projekt płacowy dla firmy Chrysler Comprehensive System. Projekt okazał się dużym sukcesem, dlatego też Kent Beck postanowił spopularyzować wykorzystaną metodykę publikując w 1999 roku książkę zatytułowaną "eXtreme Programming eXplained”. Pozycja do dnia dzisiejszego doczekała się kilku wydań i może być traktowana jako swoisty manifest tego ruchu. Od lat dziewięćdziesiątych programowanie ekstremalne zaczęło ewoluować, a proces ten trwa po dziś dzień. [3]
Nazewnictwo
Nazwa metodyki programowania ekstremalnego wzięła się od pytania, które postawił sobie Kent Beck: Co by się stało, gdyby wziąć każdą technikę i realizować ją do granic rozsądku? W rezultacie zostały wysunięte następujące wnioski:
- Przegląd kodu (ang. code review) jest skuteczny, ponieważ kod jest weryfikowany w sposób ciągły.
- Testowanie kodu jest skuteczne, ponieważ testy regresyjne i integracyjne są przeprowadzane kilka razy dziennie.
- Design kodu jest skuteczny, ponieważ każdy musi codziennie refaktoryzować (ang. refactoring) swój kod.
- Krótkie iteracje są skuteczne, ponieważ planowanie odbywa się na początku każdej iteracji.
Wyżej wyszczególnione dobre praktyki wspierają projektowanie prostych, efektywnych, maksymalizujących wartość biznesową aplikacji. Jednakże, odpowiednie i kompleksowe wdrożenie metodyki programowania ekstremalnego wymaga wysokiego poziomu umiejętności, dyscypliny oraz pracy zespołowej.[4]
Istota Programowania Ekstremalnego
Wiele metod tworzenia oprogramowania uznaje, że zmiana jest kosztowna. Błąd znaleziony w fazie utrzymania projektu zwykle kosztuje więcej, niż błąd znaleziony w fazie planowania, czy tworzenia oprogramowania. Programowanie ekstremalne wychodzi naprzeciw oczekiwaniom i próbuje obniżyć koszty zmiany wymagań poprzez zastosowanie krótkich cykli iteracyjnych. Metodyka ta uznaje zmianę jako rzecz nieuniknioną, wręcz naturalną w procesie tworzenia oprogramowania, dlatego powinna być dobrze zaplanowana. Określenie stabilnego zestawu wymagań w przypadku tej metodyki jest niemożliwe.[1]
Wartości metodyki
Metoda programowania ekstremalnego oparta jest na kilku podstawowych wartościach:
- komunikacja - odgrywa ważną rolę w sukcesie projektu. W metodach tradycyjnych używa się na szeroką skalę dokumentacji, czego zazwyczaj brakuje w XP, ze względu m.in. na szybkie zmiany wymagań. Celem komunikacji w programowaniu ekstremalnym jest przedstawienie wszystkim programistom wspólnego, jednolitego i prostego poglądu na projekt. Dlatego też, w programowaniu ekstremalnym wykorzystuje się proste modele, współpracę użytkowników z inżynierami, częstą komunikację werbalną, czy odpowiedź zwrotną.
- prostota - budowanie tylko takich systemów, które muszą być rzeczywiście zbudowane. Złożoność systemów dużo kosztuje a przewidywanie przyszłości jest trudne. Często spotykaną zasadą wykorzystywaną w tej metodzie jest KISS, czyli ‘Keep It Simple, Stupid!’ (ang. nie komplikuj, głupcze).
- informacja zwrotna - dzięki krótkim iterakcjom produkt jest dostarczany wcześnie do klienta, który wydaje opinię na temat postępów pracy oraz jest w stanie dostarczyć informację zwrotną np. aby wprowadzić potrzebną zmianę. Im szybciej informacja zwrotna będzie dostarczona, tym sprawniej będzie można zareagować na daną zmianę. Dlatego ważne jest, aby zadawać pytania i uczyć się z udzielonych na nie odpowiedzi.
- odwaga - podejmowanie ciężkich decyzji, gdy jest to konieczne. Jeśli dana funkcjonalność nie działa, należy ją naprawić. Jeśli zbliża się termin dostarczenia, a praca nie idzie zgodnie z harmonogramem, należy powiedzieć o tym klientowi. Nikt nie lubi łamać obietnic, jednakże w takim przypadku należy przyznać się do winy i naprawić to jak najszybciej.
Najlepsze praktyki metodyki
W metodzie programowania ekstremalnego wyróżniono 12 praktyk, które można podzielić na 4 obszary. Praktyki te pomagają podejmować decyzję oraz osiągać wysoką jakość i produktywność. [2][1]
Planowanie
W odróżnieniu od tradycyjnych metod, gdzie proces planowania jest długotrwały i skomplikowany, w metodzie programowania ekstremalnego planowany jest krótki odcinek czasu w najbliższej przyszłości.
- gra planistyczna - ma miejsca na początku każdej iteracji. Celem gry jest określenie zakresu pracy na najbliższy okres poprzez umiejętne połączenie decyzji biznesowych i technicznej estymacji.
- metafora - przedstawienie projektu w prosty sposób, aby zarówno zespół programistyczny był świadom, jak ich funkcjonalność oddziałuje na całość systemu, ale również, aby klient, który często nie jest osobą techniczną, mógł w pełni zrozumieć zachowania systemu
- udział klienta w zespole - klient jest integralnym członkiem zespołu, z którym pozostaje w ciągłym kontakcie. Ma dostęp do najbardziej aktualnej wersji produktu, dzięki czemu jest w stanie dostarczyć szybką informację zwrotną i podjąć decyzję projektową.
Projektowanie
Proces projektowania jest ściśle powiązany z programowaniem, dlatego też projekt powstaje tuż przed etapem kodowania. Projektowane rozwiązania powinny być przejrzyste, aby programista w prosty sposób mógł zaimplementować daną funkcjonalność. Przejrzystość jest tym bardziej ważna, gdyż kod programu w przypadku programowania ekstremalnego jest równocześnie jego dokumentacją.
- prostota projektu - system powinien być zaprojektowany najprościej, jak to tylko możliwe w danym momencie. Dodatkowa złożoność jest usuwana w momencie jej identyfikacji.
Programowanie
W programowaniu ekstremalnym kodowanie jest uważane za najważniejszy etap. Programowanie zabiera najwięcej czasu i kod stworzony w tym procesie nadaje kształt finalnemu produktowi projektu.
- częste wydania - klient musi otrzymywać najnowszą wersję programu w krótkich odstępach czasowych (średnio 2 tyg.). Dzięki temu jest w stanie stwierdzić, czy funkcjonalności zostały poprawnie zaimplementowane.
- refaktoryzacja - restrukturyzacja kodu przez programistów poprzez usuwanie duplikacji, poprawianie komunikacji, czy dodawanie elastyczności.
- współwłasność kodu - każdy programista może zmieniać kod w dowolnym miejscu i w dowolnym momencie. Może to nieść za sobą negatywne skutki, ponieważ rozmywa się odpowiedzialność, ale w zamian za to, znacząco upraszcza procedurę wprowadzania zmian.
- ciągła integracja - każda nowa funkcjonalność musi szybko być zintegrowana zresztą systemu, a nowa wersja produktu powinna być zbudowana przynajmniej raz dziennie.
- brak nadgodzin - praktyka mówi, aby programista nie pracował więcej, niż 40 godzin tygodniowo. Nadgodziny negatywnie wpływają na koncentrację programisty, a co za tym idzie, jakość pisanego kodu.
- standard kodowania - zapobiega tworzeniu niespójnego kodu, ponieważ każdy programista ma swoje przyzwyczajenia i praktyki.
- programowanie w parach - programiści piszą kod w parach na jednym komputerze. W momencie gdy jeden z nich programuje, drugi sprawdza powstający kod, sugeruje rozwiązania lub zadaje pytania.
Testowanie
Nieodzowna część projektu. W programowaniu ekstremalnym występują testy jednostkowe pisane przez programistów, mające na celu sprawdzenie poprawnego działania fragmentu kodu napisanego przez nich samych. Drugim rodzajem są testy funkcjonalne, które pomagają stwierdzić, czy funkcjonalność wymagana przez klienta działa poprawnie.
- testowanie przed programowaniem - pisanie testu przed napisaniem funkcjonalności. Oprogramowanie zawsze musi przejść testy, by mogło być dostarczone do klienta. Testy pomagają wyłapywać błędy powstające przy wprowadzaniu nowych funkcjonalności, czy refaktoryzacji kodu.
Zalety i funkcje metodyki
Wyżej opisane wartości opisują cel, który przyświeca Ekstremalnemu programowaniu: tworzenie oprogramowania o wysokiej jakości za pomocą prostych środków, przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na potrzeby klienta oraz odważnym podejmowaniu trudnych decyzji. Praktyki XP stanowią swoistą implementację tych wartości. Mimo pozornej dowolności w doborze, są one ściśle związane ze sobą i wspólnie realizują założone cele metodyki. Pierwszą zaletą w XP jest komunikacja ustna (brak tworzenia dokumentacji). Zbudowanie systemu informatycznego wymaga przekazania wymagań od klienta do programistów. W tradycyjnych metodykach (np. PRINCE) wykorzystuje się w tym celu dokumenty. Programowanie ekstremalne odróżnia się tym od innych metodologii (zwinnych czy tradycyjnych) że kładzie nacisk na testowanie czyli przed napisaniem właściwego kodu należy zaimplementować dla niego wszystkie testy, przetestować każdy jego fragment. XP posługuje się komunikacją werbalną co zapewnia lepsze i bardzo szybkie rozprzestrzenianie się wiedzy o systemie w zespole. Poprzez dobrą komunikacje wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego systemu i wiedzą w jakim kierunku projekt dąży. Kolejną zaletą jest prostota. Programowanie ekstremalne zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu (minimalnym, spełniającym pewne początkowe wymagania). Kiedy uda się upewnić że się idzie w dobrym kierunku rozwiązania, na tej podstawie dobudowuje się resztę. Metodyka wprowadza brak inspekcji bowiem zastępuje je programowanie parami (jedna osoba pisze kod, a druga na bieżąco kontroluje pracę partnera). Programiści piszą w dwójkach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w dwójkach zamieniają się miejscami co pewien czas np. co kilkadziesiąt minut. Taka technika umożliwia wyłapanie wielu błędów oraz wzajemną naukę [5][6].
Wady
Wady jakie można zważyć w tej metodyce to brak dokładnej specyfikacji, stała dostępność przedstawiciela klienta – co jest dość trudne do wykonania, wspólna "własność" kodu - każdy może zmieniać dowolny fragment systemu, brak struktur i procedur dokumentacyjnych, wymaga zmiany kulturowej w organizacji w celu wdrożenia. Komunikacja ustna pomimo że jest traktowana jako zaleta też ma wadę. Programiści stosujący metodyka XP po pewnym czasie mogą nie pamiętać, którą opcję rozwiązania wybrali i dlaczego właśnie tą (ponownie – przydałoby się posiadać udokumentowane wymagania) [5].
Bibliografia
- Gratkowski, T. (2010), Wspomaganie procesu definiowania zadań wykonywanych w ramach projektu informatycznego ‘’Metody Informatyki Stosowanej’’ (3), 105-109.
- Vijayasarathy L., Turk D., (2008), Agile software development: A survey of early adopters. ‘’Journal of Information Technology Management’’ 19(2), 1-8.
- Schümmer, T., Lukosch, S. (2009), Understanding Tools and Practices for Distributed Pair Programming ‘’Journal of Universal Computer Science’’ 15(16), 3101-3125.
Przypisy
- ↑ 1,0 1,1 1,2 Chromatic, Extreme Programming Pocket Guide: Team-Based Software Development, O'Reilly Media 2003, str. XI
- ↑ 2,0 2,1 Beck K., Extreme Programming Explained: Embrace Change, Addison-Wesley Longman Publishing, Boston, 2000, str. XVII
- ↑ Rosenberg D., Extreme Programming Refactored: The Case Against XP, Apress, 2003, str. 39
- ↑ Coffin D., A Practical Guide to Seven Agile Methodologies. Part 1., Devx.com, 2006, str. 2
- ↑ 5,0 5,1 Koszlajda A., Zarządzanie Projektami IT. Przewodnik Po Metodykach., Helion, Gliwice 2010, str. 179 - 187.
- ↑ Wróblewski P., Zarządzanie projektami informatycznymi dla praktyków. Podstawowe techniki zarządzania projektami przedstawione bez zbędnej teorii, Helion, Gliwice 2005, str. 181 - 182.
Autor: Marcin Maślanka, Robert Madejowicz
