czym jest programowanie Ekstremalne? Przegląd zasad i wartości XP

w latach 90. rozwój Internetu wymagał zmiany w rozwoju oprogramowania. Jeśli sukces firmy zależał od szybkości, z jaką firma mogłaby się rozwijać i wprowadzać produkty na rynek, firmy musiały znacznie skrócić cykl życia oprogramowania.,

To właśnie w tym środowisku Kent Beck stworzył extreme programming (XP), zwinną metodologię zarządzania projektami, która wspiera częste wydania w krótkich cyklach rozwoju w celu poprawy jakości oprogramowania i umożliwienia programistom reagowania na zmieniające się wymagania klientów.

chociaż możesz rozpoznać niektóre z tych praktyk i wartości z innych metod zarządzania projektami, XP przenosi te praktyki na „ekstremalne” poziomy, jak sugeruje nazwa metodologii., W wywiadzie dla Informit, Kent wyjaśnia:

„gdy po raz pierwszy zostałem poproszony o poprowadzenie zespołu, poprosiłem ich o zrobienie trochę rzeczy, które uznałem za rozsądne, takich jak testy i recenzje. Za drugim razem było o wiele więcej na linii. Poprosiłem zespół, żeby podkręcili wszystkie gałki do 10 rzeczy, które uważałem za niezbędne i pominęli Wszystko inne.”

Jeśli ty i twój zespół potrzebujecie szybkiego zwolnienia i odpowiedzi na prośby klientów, przyjrzyjcie się wartościom i zasadom programowania ekstremalnego—może to być idealne dopasowanie.,

wartości metodologii extreme programming

XP to więcej niż seria kroków do Zarządzaj projektami—kieruje się zestawem wartości, które pomogą Twojemu zespołowi pracować szybciej i efektywniej współpracować.

prostota

zespoły osiągają to, o co poproszono i nic więcej. PD dzieli każdy etap dużego procesu na mniejsze, osiągalne cele, które członkowie zespołu mogą osiągnąć.,

usprawniona komunikacja

zespoły współpracują ze sobą w każdej części projektu, od zebrania wymagań po wdrożenie kodu, i uczestniczą w codziennych spotkaniach standupowych, aby na bieżąco informować wszystkich członków zespołu. Wszelkie obawy lub problemy są natychmiast rozwiązywane.

konsekwentne, konstruktywne informacje zwrotne

W XP zespoły dostosowują swój proces do projektu i potrzeb klienta, a nie na odwrót. Zespół powinien wcześnie i często demonstrować swoje oprogramowanie, aby móc zebrać informacje zwrotne od klienta i wprowadzić niezbędne zmiany.,

szacunek

Programowanie Ekstremalne zachęca do mentalności „wszyscy za jednego i jeden za wszystkich”. Każda osoba w zespole, niezależnie od hierarchii, jest szanowana za swój wkład. Zespół szanuje opinie klientów i odwrotnie.

Odwaga

członkowie zespołu dostosowują się do pojawiających się zmian i biorą odpowiedzialność za swoją pracę. Mówią prawdę o swoich postępach—nie ma „białych kłamstw” lub wymówek, aby nie sprawić, że ludzie poczują się lepiej. Nie ma powodu do obaw, bo nikt nigdy nie pracuje sam.,

zasady metodologii extreme programming

Don Wells opublikował pierwsze zasady XP w 1999 roku, aby przeciwdziałać twierdzeniom, że extreme programming nie wspiera działań niezbędnych do rozwoju oprogramowania, takich jak planowanie, zarządzanie i projektowanie. Od planowania do testowania oprogramowania, wykonaj te podstawowe kroki dla każdej iteracji.

planowanie

ten etap to miejsce, w którym dzieje się magia UX., Zamiast długiego dokumentu wymagań, klient pisze historie użytkowników, które określają funkcjonalność, którą klient chciałby zobaczyć, wraz z wartością biznesową i priorytetem każdej z tych funkcji. Historie użytkowników nie muszą być wyczerpujące ani zbyt techniczne—muszą tylko dostarczyć wystarczająco dużo szczegółów, aby pomóc zespołowi określić, ile czasu zajmie wdrożenie tych funkcji.

dzięki Lucidchart klienci mogą utworzyć podstawowy schemat blokowy i łatwo rejestrować i udostępniać pożądane funkcje.,

następnie zespół tworzy harmonogram wydań i dzieli projekt na iteracje (trwające od jednego do trzech tygodni). Kierownicy projektów mogą chcieć utworzyć oś czasu lub uproszczony wykres Gantta, aby udostępnić harmonogram zespołowi.

Zarządzanie

na tym etapie kierownik projektu ustawi zespół, aby odniósł sukces w tej metodologii. Każdy musi współpracować i skutecznie komunikować się, aby uniknąć potknięć. Ten etap obejmuje:

• stworzenie otwartej przestrzeni roboczej dla Twojego zespołu
• ustawienie zrównoważonego tempa (tj., określanie odpowiedniej długości iteracji)
• zaplanowanie codziennego spotkania standupowego
• pomiar prędkości projektu (ilości pracy wykonywanej w projekcie)
• ponowne przypisanie pracy, aby uniknąć wąskich gardeł lub utraty wiedzy
• zmiana zasad, jeśli XP nie działa idealnie dla zespołu

projektowanie

ta zasada wraca do wartości prostoty: zacznij od najprostszego projektu, ponieważ ukończenie projektu zajmie mniej czasu niż ukończenie projektu.kompleksowe rozwiązanie. Nie dodawaj funkcjonalności wcześniej. Refaktor często, aby zachować swój kod czysty i zwięzły., Twórz rozwiązania spike, aby znaleźć rozwiązania potencjalnych problemów, zanim twój zespół zostanie w tyle.

Kent Beck i Ward Cunningham stworzyli również karty CRC (class-responsibility-collaboration) do wykorzystania w ramach metodologii XP. Karty te pozwalają całemu zespołowi projektowemu zaprojektować system i zobaczyć, jak obiekty wchodzą w interakcje. Jeśli chcesz wypróbować to narzędzie burzy mózgów dla siebie, zacznij od naszego szablonu Lucidchart.,

kodowanie

w końcu przychodzi czas na implementację kodu. XP praktykuje zbiorową własność kodu: każdy przegląda kod i każdy programista może dodać funkcjonalność, naprawić błędy lub refaktor. Aby wspólna własność kodu zadziałała, zespół powinien:

• wybrać metaforę systemową (standaryzowany schemat nazewnictwa).
• Ćwicz programowanie par., Członkowie zespołu pracują w parach, na jednym komputerze, aby utworzyć kod i wysłać go do produkcji. Tylko jedna para integruje kod na raz.
• integruj i zatwierdzaj kod do repozytorium co kilka godzin.

klient powinien być dostępny, najlepiej na miejscu, podczas całego procesu, aby mógł odpowiedzieć na pytania i ustalić wymagania.

Testing

zespół wykonuje testy jednostkowe i naprawia błędy przed wydaniem kodu. Często przeprowadzają również testy akceptacyjne.,

kiedy korzystać z extreme programming

nadal nie jesteś pewien, czy XP będzie pasował do potrzeb Twojego zespołu, nawet po zapoznaniu się z jego zasadami i wartościami? Programowanie ekstremalne może działać dobrze dla zespołów, które:

• oczekują, że funkcjonalność ich systemu zmieni się co kilka miesięcy.
• doświadczaj stale zmieniających się wymagań lub współpracuj z klientami, którzy nie są pewni, co chcą, aby system działał.
• chcą ograniczyć ryzyko związane z projektem, zwłaszcza w przypadku napiętych terminów.
• obejmują niewielką liczbę programistów (preferowane jest od 2 do 12).
• są w stanie ściśle współpracować z klientami.,
• są w stanie tworzyć zautomatyzowane testy jednostkowe i funkcjonalne.

Jeśli współpraca i ciągły rozwój są priorytetami dla Twojego zespołu, warto spróbować programowania ekstremalnego. Ponieważ ten wysoce elastyczny model wymaga ciągłych informacji zwrotnych od klientów, przewiduje błędy po drodze i wymaga współpracy programistów, XP nie tylko zapewnia wydanie produktu zdrowotnego, ale także mimowolnie poprawia produktywność zespołów programistycznych na całym świecie.,

Jeśli zdecydujesz się korzystać z XP, spróbuj dokumentować historie użytkowników, harmonogramy wydań, karty CRC i dokumentację systemu wizualnie w Lucidchart. Zarejestruj się na darmowe konto już dziś.

---