Metodyka Extreme Programming: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 4 wersji utworzonych przez jednego użytkownika)
Linia 1: Linia 1:
{{infobox4
'''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, s. 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, s. XVII</ref>
|list1=
<ul>
<li>[[Lean Software Development]]</li>
<li>[[Backlog produktu]]</li>
<li>[[Metodyka MSF]]</li>
<li>[[Feature-Driven Development]]</li>
<li>[[Large-scale scrum]]</li>
<li>[[Retrospektywa]]</li>
<li>[[Test driven development]]</li>
<li>[[DevOps]]</li>
<li>[[Manifest Agile]]</li>
</ul>
}}
 
'''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>


==TL;DR==
==TL;DR==
Linia 20: Linia 5:


==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, s. 39</ref>
 
<google>t</google>


==Nazewnictwo==
==Nazewnictwo==
Linia 30: Linia 13:
* 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, s. 2</ref>
 
<google>n</google>


==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==
Linia 45: Linia 30:
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.
Linia 51: Linia 36:
* '''[[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.


===== Programowanie =====
=====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.
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.
Linia 65: Linia 50:
* '''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.


===== Testowanie =====
=====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.
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.
* '''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 ==
==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, s. 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, s. 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"/>.
 
{{infobox5|list1={{i5link|a=[[Lean Software Development]]}} &mdash; {{i5link|a=[[Backlog produktu]]}} &mdash; {{i5link|a=[[Metodyka MSF]]}} &mdash; {{i5link|a=[[Feature-Driven Development]]}} &mdash; {{i5link|a=[[Large-scale scrum]]}} &mdash; {{i5link|a=[[Retrospektywa]]}} &mdash; {{i5link|a=[[Test driven development]]}} &mdash; {{i5link|a=[[DevOps]]}} &mdash; {{i5link|a=[[Manifest Agile]]}} }}


==Przypisy==
==Przypisy==
Linia 80: Linia 67:
==Bibliografia==
==Bibliografia==
<noautolinks>
<noautolinks>
* Gratkowski, T. (2010), ''[https://www.knws.uz.zgora.pl/history/pdf/knws_2010_119.pdf Wspomaganie procesu definiowania zadań wykonywanych w ramach projektu informatycznego]'' ‘’Metody Informatyki Stosowanej’’ (3), 105-109
* Gratkowski T. (2010), ''[https://repo.pw.edu.pl/docstore/download/WUTe4aa898226bd4933a226494a94f5e2e7/MIS-2010-3.pdf#page=105 Wspomaganie procesu definiowania zadań wykonywanych w ramach projektu informatycznego]'', Metody Informatyki Stosowanej, nr 3
* Schümmer, T., Lukosch, S. (2009), ''Understanding Tools and Practices for Distributed Pair Programming'' ‘’Journal of Universal Computer Science’’ 15(16), 3101-3125
* Schümmer T., Lukosch S. (2009), ''Understanding Tools and Practices for Distributed Pair Programming'', Journal of Universal Computer Science, nr 15(16), 3101-3125
* Vijayasarathy L., Turk D., (2008), ''Agile software development: A survey of early adopters.'' ‘’Journal of Information Technology Management’’ 19(2), 1-8
* Vijayasarathy L., Turk D. (2008), ''Agile software development: A survey of early adopters'', Journal of Information Technology Management, nr 19(2)
</noautolinks>
</noautolinks>
[[Kategoria:Metodyki zarządzania projektami]]
[[Kategoria:Metodyki zarządzania projektami]]
{{a|Marcin Maślanka, Robert Madejowicz}}
{{a|Marcin Maślanka, Robert Madejowicz}}


{{#metamaster:description|Extreme Programming - lekka, elastyczna metodyka tworzenia oprogramowania, opierająca się na prostocie, odwadze i komunikacji. Przewidywalna i naukowa, promuje innowacyjne podejście.}}
{{#metamaster:description|Extreme Programming - lekka, elastyczna metodyka tworzenia oprogramowania, opierająca się na prostocie, odwadze i komunikacji. Przewidywalna i naukowa, promuje innowacyjne podejście.}}

Aktualna wersja na dzień 00:30, 25 lis 2023

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]

TL;DR

Extreme Programming (XP) to metodyka tworzenia oprogramowania, która stawia na prostotę, odwagę, informację zwrotną i komunikację. XP uznaje zmianę za nieuniknioną i stara się obniżyć koszty jej wprowadzania poprzez krótkie cykle iteracyjne. Metoda opiera się na wartościach takich jak komunikacja, prostota, informacja zwrotna i odwaga. W XP wyróżnia się 12 praktyk, które pomagają w osiągnięciu wysokiej jakości i produktywności. Metoda ma wiele zalet, takich jak dobra komunikacja, prostota projektowania, częste wydania i testowanie przed programowaniem. Jednakże, wadami metodyki są brak dokładnej specyfikacji, stała dostępność przedstawiciela klienta, brak struktur dokumentacyjnych i wymaga zmiany kulturowej.

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].


Metodyka Extreme Programming — artykuły polecane
Lean Software Development — Backlog produktu — Metodyka MSF — Feature-Driven Development — Large-scale scrum — Retrospektywa — Test driven development — DevOps — Manifest Agile

Przypisy

  1. ↑ 1,0 1,1 1,2 Chromatic, Extreme Programming Pocket Guide: Team-Based Software Development, O'Reilly Media 2003, s. XI
  2. ↑ 2,0 2,1 Beck K., Extreme Programming Explained: Embrace Change, Addison-Wesley Longman Publishing, Boston, 2000, s. XVII
  3. ↑ Rosenberg D., Extreme Programming Refactored: The Case Against XP, Apress, 2003, s. 39
  4. ↑ Coffin D., A Practical Guide to Seven Agile Methodologies. Part 1., Devx.com, 2006, s. 2
  5. ↑ 5,0 5,1 Koszlajda A., Zarządzanie Projektami IT. Przewodnik Po Metodykach., Helion, Gliwice 2010, s. 179-187.
  6. ↑ Wróblewski P., Zarządzanie projektami informatycznymi dla praktyków. Podstawowe techniki zarządzania projektami przedstawione bez zbędnej teorii, Helion, Gliwice 2005, s. 181-182.

Bibliografia

  • Gratkowski T. (2010), Wspomaganie procesu definiowania zadań wykonywanych w ramach projektu informatycznego, Metody Informatyki Stosowanej, nr 3
  • Schümmer T., Lukosch S. (2009), Understanding Tools and Practices for Distributed Pair Programming, Journal of Universal Computer Science, nr 15(16), 3101-3125
  • Vijayasarathy L., Turk D. (2008), Agile software development: A survey of early adopters, Journal of Information Technology Management, nr 19(2)

Autor: Marcin Maślanka, Robert Madejowicz


Źródło: „https://mfiles.pl/pl/index.php?title=Metodyka_Extreme_Programming&oldid=196209”