Źródło obrazu: pixabay.com

Ekstremalne programowanie

Wyobraź sobie: projekt radaru opracowany dla nowego produktu, oparty na przewadze rynkowej. Tradycyjne metody ekstremalnego programowania, w których klient wie „dokładnie”, czego chcą, są obecnie niedostępne. Twój zespół jest niewielki i składa się z młodych profesjonalistów, którzy prawdopodobnie dobrze zareagują na radykalny model zarządzania projektami. Jakie masz opcje?

Oczywiście możesz powiedzieć, Agile Project Management! Ale jakiej metodologii chciałbyś użyć? Istnieje kilka opcji: po pierwsze, istnieje niezwykle popularny Scrum: polega on na tworzeniu krótkich „sprintów” na podstawie zaległych zadań klienta. A potem jest Kanban, który pracuje nad optymalizacją przebiegu pracy. Istnieje również programowanie ekstremalne, często w skrócie XP, które koncentruje się na wzmacnianiu pozytywnych aspektów tradycyjnych modeli programowania, aby działały one z maksymalną mocą.

Programowanie ekstremalne to niezwykle popularna (choć nie tak popularna jak Scrum) metodologia skoncentrowana na spełnianiu zmieniających się wymagań klientów. Pierwszy projekt programowania ekstremalnego został zapoczątkowany w marcu 1996 roku przez Kent Beck w Chrysler. W swojej książce z 1999 r. „ Extreme Programming Explained: Embrace Change” szczegółowo opisał aspekty rozwoju oprogramowania.

Kent Beck był także pionierem rozwoju opartego na testach, który wprowadził testy radarowe przypadków użycia jako ulepszenie sposobu, w jaki wtedy to robiono: pisanie linii i linii kodu, a następnie testowanie. Był także jednym z pierwszych sygnatariuszy Agile Manifesto, pomagając kształtować manifest, aby zmienić sposób pisania ekstremalnego oprogramowania do programowania.

Pięć wartości programowania ekstremalnego opartego na objaśnionych są:

Komunikacja

Programowanie ekstremalne nie zależy od obszernej dokumentacji. W rzeczywistości ekstremalna dokumentacja programowa jest sugerowana tylko wtedy, gdy jest to konieczne. Tak więc metodologia w dużej mierze opiera się na komunikacji między członkami zespołu, a także z użytkownikami.

Prostota

Jest to sedno Extreme Programming. Metodologia faworyzuje proste projekty, nie myśląc zbyt daleko w przyszłość, ale skupiając się na dzisiejszych wymaganiach, jednocześnie czyniąc sam program wystarczająco solidnym, aby dodać wymagania, które przyniesie przyszłość.

Informacje zwrotne

Ta niezbędna pętla przechodzenia tam i z powrotem odróżnia systemy Agile w ogóle, aw szczególności programowanie ekstremalne, od innych metodologii zarządzania projektami oprogramowania. Ciągłe sprzężenie zwrotne może działać na różne sposoby, ale wszystkie mają na celu wzmocnienie systemu i zwiększenie jego niezawodności.

Informacje zwrotne mogą mieć różne smaki:

  • Z samego programu: Kod jest energicznie testowany przez cały cykl rozwoju projektu, aby deweloperzy mogli wprowadzić zmiany.
  • Od klienta: Jest to niezbędna część większości systemów Agile. Klienci piszą testy akceptacyjne, na których oparty jest rozwój, co stanowi podstawę procesu rozwoju. Wszystkie iteracje są również dostarczane do klienta w celu okresowej informacji zwrotnej.
  • Z zespołu: Po utworzeniu nowego przypadku użycia / historii, zespół natychmiast powraca z oszacowaniem kosztów i harmonogramu, ustalając wymagania w miarę ich pojawiania się. W Ekstremalnym Programowaniu nikt nie „posiada” żadnego kodu, dlatego w zespołach zajmujących się programowaniem ekstremalnym zachęca się do przekazywania informacji zwrotnych na temat kodu drugiej osoby.

Odwaga

Może to wydawać się dziwną wartością w ekstremalnym programowaniu do tworzenia oprogramowania, bardziej dostosowaną do czegoś takiego jak armia lub żołnierze piechoty morskiej! Pomyślcie jednak o tym: projekty oprogramowania od dawna są obarczone tradycyjnymi ekstremalnymi metodami programowania; bezpieczne w obszernej dokumentacji i hierarchii, która nie pozwala na innowacje. Ta wartość stanowi przykład ekstremalnego programowania: bądź gotowy do skoku, bez spadochronu, jeśli do tego dojdzie! Spójrz na ten inny styl zarządzania projektami i bądź gotów być odpowiedzialny, zrezygnować z hierarchii, być odpowiedzialny i pracować, nie wiedząc wszystkiego na samym początku.

Szacunek

Szacunek, piąta wartość, został dodany później i oznacza szacunek dla innych i dla samego siebie. Oznacza to również szacunek dla pisanego kodu oraz oczekiwań i potrzeb klienta. Ta wartość leży również u podstaw komunikacji między różnymi zainteresowanymi stronami.

Działania ekstremalnego projektu programistycznego

Programowanie ekstremalne wyróżnia cztery proste czynności projektu. Oni są:

  • Kodowanie : programowanie ekstremalne uważa to za najważniejsze działanie. „Bez kodu nie ma nic” - mówi Kent Beck, założyciel Extreme Programming.
  • Testowanie : Kod jest taki, chyba że jest testowany. Extreme Programming ma obsesję na punkcie testowania, używając testów jednostkowych w celu potwierdzenia działania kodu i testów akceptacyjnych generowanych przez klienta w celu potwierdzenia, że ​​kod testuje to, co należy przetestować.
  • Słuchanie: Słuchanie, którego przykładem jest podstawowa wartość komunikacji, jest działaniem, które wymaga od programistów nie tylko słuchania klientów, ale także słuchania tego, czego chcą. Rozwój i biznes to dwie różne rzeczy i często programiści nie rozumieją uzasadnienia biznesowego konkretnej decyzji. Potrzeby klienta, a także deweloperów, stanowią podstawę działania „słuchania”.
  • Projektowanie : może cię zaskoczyć fakt, że w projekcie tworzenia oprogramowania, często tak ważne i najważniejsze zadanie projektowe znajduje się na końcu. Wynika to z faktu, że Extreme Programming celowo chce oderwać ludzi od myślenia o „projektowaniu i rozwijaniu”, które przemysł pielęgnuje od wielu lat. Nie ma to na celu ograniczenia znaczenia projektowania. Dobry i minimalny projekt jest raczej jedną z cech charakterystycznych projektu.

Z wartości i działań wyłania się 12 zasad programowania ekstremalnego, opracowanych przez jego założyciela, w jego książce Extreme Programming Explained.

  • Gra planistyczna
  • Programowanie par
  • Rozwój oparty na testach
  • Cała drużyna
  • Ciągła integracja
  • Ulepszenie projektu
  • Małe wydania
  • Standardy kodowania
  • Własność kodu zbiorowego
  • Prosta konstrukcja
  • Metafora systemu
  • Zrównoważone tempo

Niektóre z tych ekstremalnych praktyk programowania, wszystkie odwzorowane na najlepsze praktyki inżynierii oprogramowania, różnią się od ogólnych metodologii Agile. Niektóre praktyki programowania ekstremalnego wyjaśniono poniżej:

  1. Gra planistyczna

Jest to część projektu dotycząca planowania, zwana „planowaniem gry”. Obejmuje planowanie następnej iteracji i wydania, w porozumieniu z użytkownikiem / klientem, a także wewnętrzne planowanie zespołów, dotyczące zadań, nad którymi będą pracować.

  1. Programowanie par

Obejmuje to dwie osoby pracujące nad fragmentem kodu. Jedna osoba, zwana klawiaturą, wpisuje kod, a druga, zwana monitorem, nadzoruje kod, komentując go i dopracowując, w zależności od potrzeb. Dwie osoby często wymieniają się rolami. Udowodniono, że znacznie poprawia to wydajność kodu. Może to nie być odpowiednie dla wszystkich scenariuszy programistycznych i należy o tym pomyśleć przed zarejestrowaniem się w Programowaniu ekstremalnym.

  1. Rozwój oparty na testach

Cały napisany kod jest weryfikowany jednostkowo, tzn. Każdy fragment kodu, który może coś zrobić, jest najpierw testowany. Extreme Programming kładzie duży nacisk na testowanie. Pomaga to potwierdzić, że kod działa, dzięki czemu można go rozważyć włączenie do samego projektu programowania ekstremalnego. Jest to analogiczne do testów jednostkowych w szkole: testowane są małe fragmenty informacji, dzięki czemu nauczyciel / uczeń może dokonywać korekt kursu i nie marnuje się podczas corocznych egzaminów!

  1. Ulepszenie projektu (refaktoryzacja)

Projekty XP oparte na swojej prostocie mają na celu ciągłe doskonalenie napisanego kodu. Oznacza to, że cały kod (a czasem także baza danych) jest zawsze ulepszany. Refaktoryzacja nie dodaje żadnej funkcjonalności; poprawia jedynie istniejący kod. Sprawia, że ​​jest ciaśniejszy i wyraźniejszy. Przypomina edycję fragmentu tekstu, dopracowanie go i ulepszenie.

  1. Prosta konstrukcja

W Extreme Programming funkcje nie są dodawane, dopóki nie są specjalnie wymagane. Nawet jeśli kod, nad którym obecnie pracujemy, jest bardzo podobny do tego, co może być wymagane w przyszłości, nie zostanie wykorzystany, chyba że zostanie uzgodniony jako historia użytkownika.

  1. Metafora systemu

Obejmuje to standaryzację wszystkich konwencji nazewnictwa, dzięki czemu można łatwo odczytać jego cel i funkcję. Na przykład operacje lub mogą pomóc każdemu programistowi zrozumieć ich funkcjonalność. Należy to zrobić w całym projekcie programowania ekstremalnego, aby każdy mógł łatwo spojrzeć na kod i go zmodyfikować lub ulepszyć, zależnie od przypadku.

Role w ramach ekstremalnego projektu programistycznego:

Podobnie jak Scrum, Extreme Programming ma kilka wyznaczonych ról w każdym projekcie. Teraz role nie zawsze muszą być wykonywane przez odrębne osoby, a dana osoba może przyjąć więcej niż jedną rolę.

Role programowania ekstremalnego to:

  • Klient : oczywiste. Powód projektu. Ona decyduje, co powinien zrobić projekt. Zapewnia historie użytkowników.
  • Programista : jest to osoba, która:
    • Opowiada historie, które wymyśla klient
    • Tworzy zadania programistyczne na podstawie historii
    • Implementuje historie użytkowników
    • Testuje kod według jednostki
  • Trener : Trener ogólnie zapewnia, że ​​projekt jest na dobrej drodze, a także wskakuje, aby pomóc, gdy jest to wymagane.
  • Moduł śledzący : moduł śledzący wysyła określone zapytania do programistów w ustalonych odstępach czasu. Zazwyczaj sprawdza on postępy programistów, oferując pomoc tam, gdzie jest to potrzebne, na kilka sposobów: zwijając rękawy i pomagając bezpośrednio w kodzie, informując trenera lub organizując spotkanie z klientem, w zależności od potrzeb.
  • Tester : uruchamia testy funkcjonalne. Tester nie uruchamia testów jednostkowych, które są przeprowadzane przez samych programistów.
  • Doomsayer: Jak sama nazwa wskazuje, jest to podobne do Czarnego Kapelusza w systemie grupowego myślenia Edwarda De Bono. Każdy może być Doomsayer, który zazwyczaj sygnalizuje potencjalne problemy i pomaga utrzymać problemy we właściwej perspektywie.
  • Menedżer : Menedżer w projekcie Ekstremalne programowanie przypomina bardziej harmonogram, zapewniając, że spotkania odbywają się zgodnie z planem, i upewniając się, że decyzje podejmowane podczas spotkań są przekazywane odpowiedniej osobie, najczęściej Trackerowi. Menedżer jednak nie mówi ludziom, co robić i kiedy to zrobić. Odbywa się to przez samego Klienta i / lub Historie użytkowników.
  • Złoty właściciel : Złoty właściciel to osoba finansująca projekt. Może to być klient, ale niekoniecznie tak.

Niektóre skrajne role programistyczne, jak opisano powyżej, można łączyć, ale niektóre najwyraźniej nie.

Na przykład klient nie może być również Programistą. Podobnie programista i moduł śledzący nie mogą być tą samą osobą.

Ekstremalne role programistyczne są wystarczająco jasno zdefiniowane, aby nie było zamieszania, i stworzone dla maksymalnej elastyczności i wydajności.

Wady programowania ekstremalnego:

Podczas gdy zwolennicy programowania ekstremalnego malują różowy obraz, faktem jest, że programowanie ekstremalne, jak sama nazwa wskazuje, jest niezwykle trudne do wdrożenia. Aspekty programowania ekstremalnego można z powodzeniem włączyć do projektów, niż całkowicie przyjmując XP.

Niektóre negatywy programowania ekstremalnego to:

  • Stwierdzono, że programowanie ekstremalne jest bardziej skuteczne w mniejszych grupach . Jego skuteczność w większych grupach jest kwestionowana, a lepszym rozwiązaniem jest podzielenie ekstremalnych zespołów programistycznych, aby grupy były mniejsze.
  • Jedna z kluczowych cech programowania ekstremalnego, programowanie parami w wielu przypadkach nie działa dobrze . Złożone kodowanie może wymagać dwóch głów, ale nie wszystkie zadania mogą wymagać dwóch osób, przy czym druga osoba to ciężar własny. W rzeczywistości programowanie w parach, jeśli jeden z elementów nie jest zsynchronizowany z drugim, jest jednym z głównych powodów niepowodzenia programowania ekstremalnego w wielu przypadkach.
  • Zależność od klienta do tego stopnia, że ​​sugeruje zasób na miejscu ze strony klienta, może być bardzo niepokojąca. Może również prowadzić do zakłóceń, zarówno rzeczywistych, jak i wyobrażonych, podczas opracowywania.
  • Koncentracja Extreme Programming na prostocie może bardzo utrudnić dodanie do bieżącego projektu, co oznacza wyższy budżet nawet na proste zmiany, które już nie są proste.
  • Płaska hierarchiczna struktura oznacza, że ​​zespół powinien być zawsze skoncentrowany, a pod nieobecność menedżera zajmującego się rozbieżnymi typami ludzi, zespół programowania ekstremalnego jest całkowicie zależny od dojrzałości emocjonalnej wszystkich członków zespołu, co nie zawsze jest niezawodne .

Nawet pomimo tych czynników Extreme Programming pozostaje potężnym narzędziem do zastosowania we właściwym projekcie, a firmy zgłaszają znaczny wzrost wydajności po przyjęciu ekstremalnego procesu programowania. System napędzany przez programistów, w przeciwieństwie do Scrum, który jest bardziej systemem opartym na procesach, Extreme Programming lub przynajmniej jego części, może doprowadzić do rewolucji w sposobie, w jaki opracowujemy oprogramowanie do programowania ekstremalnego.

Kategoria:

Rozwój przedsiębiorczości