Zybex: cleanup bibliografii i rotten links

2023-11-24T23:30:12Z

cleanup bibliografii i rotten links

Nowa strona

'''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>

==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ń. <ref name="Rosenberg D. 2003">Rosenberg D., ''Extreme Programming Refactored: The Case Against XP'', Apress, 2003, s. 39</ref>

==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<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==
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==
[[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ść]]. <ref name="Beck K. 2000"/><ref name="Chromatic 2003"/>

=====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 [[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 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]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Metodyka MSF]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Large-scale scrum]]}} — {{i5link|a=[[Retrospektywa]]}} — {{i5link|a=[[Test driven development]]}} — {{i5link|a=[[DevOps]]}} — {{i5link|a=[[Manifest Agile]]}} }}

==Przypisy==
<references />

==Bibliografia==
<noautolinks>
* 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, 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)
</noautolinks>
[[Kategoria:Metodyki zarządzania projektami]]
{{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.}}

Metodyka Extreme Programming - Historia wersji

Zybex: cleanup bibliografii i rotten links