Programowanie zwinne

Z Wikipedii, wolnej encyklopedii
Przejdź do nawigacji Przejdź do wyszukiwania

Programowanie zwinne (ang. agile software development) – grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu[1]. Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto.

Generalnie grupa metodyk oparta jest na zdyscyplinowanym zarządzaniu procesem produkcji oprogramowania, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania). Najczęściej znajdują zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Nastawione są na szybkie wytwarzanie oprogramowania wysokiej jakości.

Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii organizacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele.

Metodyki zwinne dużą wagę przywiązują do bezpośredniej komunikacji między członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e-mail itp.).

Częstym błędem występującym u osób i zespołów stosujących metodykę agile jest nadinterpretacja jej założeń i całkowicie błędne pomijanie bardzo ważnych etapów projektu tj. "zbierania wymagań", a następnie na ich podstawie "analizy" oraz "planowania".

Metodyka "Agile" sprawdza się bardzo dobrze gdy wykorzystują ją osoby oraz zespoły potrafiące dobrze ustrukturyzować swoją pracę nad danym projektem oraz jego poszczególnymi zadaniami w oparciu o "etapy" programowania zwinnego. Wynika to z faktu, iż jest ona mniej sformalizowana przez co większy ciężar dbania o organizację i systematykę pracy spoczywa na osobach bezpośrednio realizujących poszczególne zadania. W przypadku osób i zespołów o "chaotycznym/niezorganizowanym" podejściu nie potrafiących ustrukturyzować swojej pracy, zalecane jest korzystanie ze sformalizowanych metod programowania. Metodyki te przejmują na siebie większy ciężar szczegółowego strukturyzowania zadań w projekcie i tym samym pozwalają zapewnić większą kontrolę nad spójną realizacją poszczególnych elementów projektu.

Etapy[edytuj | edytuj kod]

Przy realizacji zadań w projektach w oparciu o metodykę programowania zwinnego "Agile" wyróżnia się następujące po sobie etapy:

  • Plan (Planowanie)
  • Design (Projektowanie)
  • Develop (Programowanie)
  • Test (Testowanie)
  • Release (Implementacja)
  • Feedback (Informacja zwrotna)

Powyższe etapy tworzą cykl powtarzany do czasu zakończenia danego zadania. Bardzo ważne jest zaznaczenie, iż kolejne cykle mają służyć ewentualnemu skorygowaniu przygotowanego zadania na bazie informacji klienta lub elastycznemu wprowadzaniu ewentualnych zmian wymagań ze strony klienta jeżeli takie się pojawiły w formie informacji zwrotnej (Feedback). Kolejne cykle nie mają natomiast na celu - jak błędnie przyjmuje część "chaotycznych/niezorganizowanych" osób lub zespołów - nieskończone poprawianie błędów danego zadania wynikających z pominięcia lub niedokładnego przeprowadzenia etapu Planowania w tym zbierania i analizy wymagań od klienta.

Poszczególne etapy można opisać następująco:

Planowanie - zbieranie dokładnych wymagań od klienta dotyczących danego zadania, ich analiza oraz zaplanowanie kroków koniecznych do realizacji danego zadania w oparciu o pozyskane informacje. To bardzo ważny etap mający kluczowe znaczenie dla czasu i jakości realizowanego zadania dlatego nigdy nie powinien być pomijany (jak zresztą wszystkie pozostałe etapy) Etap ten wymaga bezpośredniego kontaktu z klientem, a co za tym idzie umiejętności dobrej komunikacji i zrozumienia drugiej osoby. Etap ten jest czasem pomijany przez osoby i zespoły nie posiadające umiejętności komunikacji, odczuwające niechęć do komunikacji lub obawiające się komunikacji z klientem. Takie osoby lub zespoły nie powinny korzystać z metodyki Agile lecz skorzystać z bardziej sformalizowanych metod i/lub z dedykowanych do tego etapu analityków, którzy będą odpowiedzialni za dokładne zebranie wymagań i ich analizę.

Projektowanie - projektowanie wykonania danego elementu będącego celem zadania na bazie informacji zebranych na etapie Planowania. Można to porównać do wykonania projektu elementu domu przez architekta przed przystąpieniem do prac nad nim przez ekipę budowlaną. Ten etap jest również czasem pomijany przez osoby lub zespoły, które mylnie rozumieją fazę projektowania jako wykonywanie dokumentacji powykonawczej uznając ją w związku z tym za zbędną.

Programowanie - właściwy etap prac nad danym zadaniem na bazie przygotowanego projektu zadania

Testowanie - testowanie danego elementu będącego podmiotem zadania od strony technicznej przez osobę lub zespół wykonujący dane zadanie oraz od strony klienta (User Acceptance Test) czy dany element jest tym czego klient oczekiwał

Implementacja - po pozytywnych wynikach testów zarówno technicznych jak i klienckich (akceptacji przez klienta) przekazanie danego elementu projektu na "produkcję" do finalnego użytkowania przez klienta

Informacja zwrotna - przekazanie informacji zwrotnej przez klienta do osoby lub zespołu realizującego dane zadanie w projekcie odnośnie ewentualnych mniejszych błędów, których nie wykryto podczas testów, zgłaszanie potencjalnych usprawnień do realizacji w kolejnych cyklach lub zgłoszenie zmiany wymagań klienta. Mając na myśli zmianę wymagań mówimy o rzeczywistej zmianie wymagań - wynikłej np. ze zmiany procesów lub potrzeb klienta - nie natomiast jak zaznaczono wcześniej o zmianie wynikającej z pominięcia lub niedokładnego przeprowadzenia etapu Planowania (nie pozyskanie od klienta dokładnej specyfikacji, brak zrozumienia oczekiwań klienta, praca na niepełnej informacji, brak kontaktu z klientem, budowanie zadania w oparciu o własne domysły i uznanie bez kontaktu z klientem)

Podstawowe zasady[edytuj | edytuj kod]

 Osobny artykuł: Manifest Agile.

Manifest Agile (ang. Agile Manifesto) – założenia:

  • osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania,
  • działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie),
  • podstawową miarą postępu jest działające oprogramowanie,
  • późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
  • bliska, codzienna współpraca pomiędzy biznesem a deweloperem,
  • bezpośredni kontakt jako najlepsza forma komunikacji w zespole i poza nim,
  • ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design),
  • prostota,
  • samozarządzalność zespołów,
  • regularna adaptacja do zmieniających się wymagań.

Zobacz też[edytuj | edytuj kod]

Przypisy[edytuj | edytuj kod]

Linki zewnętrzne[edytuj | edytuj kod]