Manifest Agile: Różnice pomiędzy wersjami
m (Czyszczenie tekstu) |
m (Czyszczenie tekstu) |
||
| Linia 50: | Linia 50: | ||
'''Iteracyjny, stopniowy oraz ewolucyjny''' | '''Iteracyjny, stopniowy oraz ewolucyjny''' | ||
Większość zwinnych metod zarządzania projektem rozbija tworzenie produktu na małe stopnie, które minimalizują ilość pracy na początku planowania oraz w czasie trwania całego projektu. Stopnie te to iteracje, często zwane również jako sprinty. Trwają one [[krótki okres]] czasu, najczęściej od jednego do czterech tygodni. Każda powtórka zazwyczaj angażuje różne zespoły pracujące w dziedzinach takich jak: [[planowanie]], analiza, [[projekt]], kodowanie, testowanie, czy też [[akceptacja]] testów. Na koniec każdej iteracji funkcjonujący [[produkt]] jest demonstrowany interesariuszom | Większość zwinnych metod zarządzania projektem rozbija tworzenie produktu na małe stopnie, które minimalizują ilość pracy na początku planowania oraz w czasie trwania całego projektu. Stopnie te to iteracje, często zwane również jako sprinty. Trwają one [[krótki okres]] czasu, najczęściej od jednego do czterech tygodni. Każda powtórka zazwyczaj angażuje różne zespoły pracujące w dziedzinach takich jak: [[planowanie]], analiza, [[projekt]], kodowanie, testowanie, czy też [[akceptacja]] testów. Na koniec każdej iteracji funkcjonujący [[produkt]] jest demonstrowany interesariuszom (PMI 2017, s. 21) | ||
'''Efektywna komunikacja ''twarzą w twarz''' | '''Efektywna komunikacja ''twarzą w twarz''' | ||
Bez względu którą metodyką się podąża, każdy [[zespół]] powinien włączyć przedstawiciela ze strony klienta, w Scrumie zwanym - Product Owner'em. Wybrany przez interesariuszy przedstawiciel działa w ich imieniu i jest dostępny dla deweloperów, aby odpowiadać na ich pytania podczas iteracji. Na końcu każdej iteracji, [[interesariusze]] oraz przedstawiciel klienta oceniają postęp oraz oszacowywać priorytety biorąc pod uwagę zwrot z inwestycji. Ponadto, upewniają się co do zgodności ze strategią firmy oraz że wszystkie [[cele]] zostaną osiągnięte | Bez względu którą metodyką się podąża, każdy [[zespół]] powinien włączyć przedstawiciela ze strony klienta, w Scrumie zwanym - Product Owner'em. Wybrany przez interesariuszy przedstawiciel działa w ich imieniu i jest dostępny dla deweloperów, aby odpowiadać na ich pytania podczas iteracji. Na końcu każdej iteracji, [[interesariusze]] oraz przedstawiciel klienta oceniają postęp oraz oszacowywać priorytety biorąc pod uwagę zwrot z inwestycji. Ponadto, upewniają się co do zgodności ze strategią firmy oraz że wszystkie [[cele]] zostaną osiągnięte (PMI 2017, s. 46) | ||
'''[[Cykl]] adaptacyjny oraz bardzo krótki czas uzyskania opinii''' | '''[[Cykl]] adaptacyjny oraz bardzo krótki czas uzyskania opinii''' | ||
Charakterystyczną cechą tworzenia oprogramowania w Agile są tak zwane "daily stand-upy" (również znane jako dzienny scrum). Jest to krótka sesja, podczas której członkowie zespołu po kolei raportują co zostało zrobione poprzedniego dnia, co zamierzają zrobić dzisiaj oraz każde przeszkody czy utrudnienia które są w stanie wykryć, a które mogłyby wpłynąć na efekt końcowy iteracji | Charakterystyczną cechą tworzenia oprogramowania w Agile są tak zwane "daily stand-upy" (również znane jako dzienny scrum). Jest to krótka sesja, podczas której członkowie zespołu po kolei raportują co zostało zrobione poprzedniego dnia, co zamierzają zrobić dzisiaj oraz każde przeszkody czy utrudnienia które są w stanie wykryć, a które mogłyby wpłynąć na efekt końcowy iteracji (PMI 2017, s. 53) | ||
'''Ukierunkowany na [[jakość]]''' | '''Ukierunkowany na [[jakość]]''' | ||
| Linia 65: | Linia 65: | ||
==Filozofia Agile== | ==Filozofia Agile== | ||
W porównaniu do tradycyjnego tworzenia oprogramowania, zwinne tworzenie oprogramowania głównie ma na celu tworzenie złożonych systemów oraz rozwój produktów w oparciu o dynamiczne, nieokreślone oraz nieliniowe cechy. Dokładne oszacowanie, stabilne plany oraz prognozy są bardzo często ciężkie do określenia w początkowych stadiach projektu. [[Zaufanie]] w te [[dane]] jest bardzo znikome. Użytkownicy Agile szukają minimalizacji ‘braku wiary’ potrzebnej zanim dowody wartości będą mogły być dostarczone. Wymogi oraz projekty przychodzą wraz z rozwojem projektu. Duże specyfikacje prawdopodobnie powodowałyby duże straty w większości przypadków. Te podstawowe argumenty oraz oczekiwania przemysłu poprzedzone latami sukcesów oraz porażek pomogły ukształtować zwinne podejście do rozwoju oprogramowania | W porównaniu do tradycyjnego tworzenia oprogramowania, zwinne tworzenie oprogramowania głównie ma na celu tworzenie złożonych systemów oraz rozwój produktów w oparciu o dynamiczne, nieokreślone oraz nieliniowe cechy. Dokładne oszacowanie, stabilne plany oraz prognozy są bardzo często ciężkie do określenia w początkowych stadiach projektu. [[Zaufanie]] w te [[dane]] jest bardzo znikome. Użytkownicy Agile szukają minimalizacji ‘braku wiary’ potrzebnej zanim dowody wartości będą mogły być dostarczone. Wymogi oraz projekty przychodzą wraz z rozwojem projektu. Duże specyfikacje prawdopodobnie powodowałyby duże straty w większości przypadków. Te podstawowe argumenty oraz oczekiwania przemysłu poprzedzone latami sukcesów oraz porażek pomogły ukształtować zwinne podejście do rozwoju oprogramowania (PMI 2017, s. 7) | ||
==Metody rozwoju oprogramowania Agile== | ==Metody rozwoju oprogramowania Agile== | ||
Wersja z 16:39, 2 lis 2023
| Manifest Agile |
|---|
| Polecane artykuły |
Manifest Agile, również znany jako Manifest dla Deweloperów Oprogramowania został opublikowany w 2001 roku i zawiera podstawowe zasady zwinnego zarządzania projektami. Jest on formalną proklamacją czterech wartości i dwunastu zasad, które służą, jako przewodnik do iteracyjnego i skoncentrowanego na ludziach podejścia w rozwoju oprogramowania. Rozwój oprogramowania Agile koncentruje się na przestrzeganiu tego, by stosowany kod był prosty, często testowany oraz skupia się na dostarczaniu funkcjonalnych części aplikacji. Został stworzony jako alternatywa dla kierowanego dokumentacją procesu Waterfall, czyli modelu kaskadowego. (np.PMBOK, PCM, PRINCE2)
Jego początki związane są z rokiem 2001, kiedy to siedemnastu deweloperów spotkało się w resorcie Snowbird w stanie Utah w celu przedyskutowania lekkiego podejścia do tworzenia oprogramowania. Wśród uczestników spotkania byli między innymi: Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn oraz Bob Martin. Razem opracowali oraz opublikowali Manifest Agile dla Deweloperów Oprogramowania. (Łabuda 2015, s. 60-61)
TL;DR
Manifest Agile, znany również jako Manifest dla Deweloperów Oprogramowania, został opublikowany w 2001 roku i zawiera zasady zwinnego zarządzania projektami. Podkreśla on wartość ludzi, działającego oprogramowania, współpracy z klientem i reagowania na zmiany. Agile skupia się na iteracyjnym i skoncentrowanym na ludziach podejściu w rozwoju oprogramowania. Manifest Agile powstał jako alternatywa dla modelu kaskadowego. Metody Agile, takie jak Scrum, Kanban czy Extreme Programming, wspierają cykl rozwoju oprogramowania i skupiają się na jakości, efektywnej komunikacji i adaptacyjnym podejściu.
Wartości manifestu Agile
W oparciu o ich połączone doświadczenie w tworzeniu oprogramowania oraz chęci pomocy innym, siedemnastu sygnatariuszy manifestu ogłosiło, że ich podstawowymi wartościami są:
- Ludzie oraz interakcje ponad procesami i narzędziami
- Działające oprogramowanie ponad złożoną dokumentacją
- Współpraca z klientem ponad negocjacją kontraktu
- Reagowanie na zmianę ponad trzymanie się planu
Zasady, te można znaleźć na oficjalniej stronie manifestu. Bardzo ważne jest zwrócenie uwagi na fakt, że w podejściu Manifest Agile pomimo tego, że wartości wymienione po stronie prawej mają wartość materialną, autorzy bardziej cenią sobie pozycje wymienione po stronie lewej (pogrubione). Świadczy to przede wszystkim o skupianiu uwagi na czynniku ludzkim oraz wszystkich wartościach, które przynoszą korzyści zarówno klientowi jak i deweloperom.
Zasady rozwoju oprogramowania Agile
Rozwój oprogramowania Agile oparty jest na dwunastu zasadach (Ambler W.S., Holitza M 2012, s. 9):
- Priorytetem jest zadowolenie klienta poprzez wczesne i ciągle dostarczanie cennego oprogramowania.
- Pozytywne przyjmowanie zmieniających się potrzeb, nawet późno w rozwoju oprogramowania.
- Działające oprogramowanie jest dostarczane często (z reguły tygodniowo).
- Bliska współpraca pomiędzy interesariuszami a deweloperami.
- Projekty są tworzone wokół zmotywowanych osób, którym powinno się ufać.
- Komunikacja "twarzą w twarz" jest najlepszą komunikacją.
- Działające oprogramowanie jest podstawowym miernikiem sukcesu.
- Stały rozwój, umożliwiający równe tempo.
- Ciągłe skupianie uwagi nad techniczną doskonałością i dobrym projektem.
- Niezbędna jest prostota - sztuka maksymalizowania ilości pracy niewykonanej.
- Najlepsze wymogi i projekty wychodzą z zespołów, które się samoorganizują
- Niezbędne jest ciągłe poprawianie wydajności poprzez analizowanie możliwości poprawy oraz dostosowywanie ich do uzyskanych wniosków.
Zarys ogólny
Iteracyjny, stopniowy oraz ewolucyjny
Większość zwinnych metod zarządzania projektem rozbija tworzenie produktu na małe stopnie, które minimalizują ilość pracy na początku planowania oraz w czasie trwania całego projektu. Stopnie te to iteracje, często zwane również jako sprinty. Trwają one krótki okres czasu, najczęściej od jednego do czterech tygodni. Każda powtórka zazwyczaj angażuje różne zespoły pracujące w dziedzinach takich jak: planowanie, analiza, projekt, kodowanie, testowanie, czy też akceptacja testów. Na koniec każdej iteracji funkcjonujący produkt jest demonstrowany interesariuszom (PMI 2017, s. 21)
Efektywna komunikacja twarzą w twarz
Bez względu którą metodyką się podąża, każdy zespół powinien włączyć przedstawiciela ze strony klienta, w Scrumie zwanym - Product Owner'em. Wybrany przez interesariuszy przedstawiciel działa w ich imieniu i jest dostępny dla deweloperów, aby odpowiadać na ich pytania podczas iteracji. Na końcu każdej iteracji, interesariusze oraz przedstawiciel klienta oceniają postęp oraz oszacowywać priorytety biorąc pod uwagę zwrot z inwestycji. Ponadto, upewniają się co do zgodności ze strategią firmy oraz że wszystkie cele zostaną osiągnięte (PMI 2017, s. 46)
Cykl adaptacyjny oraz bardzo krótki czas uzyskania opinii
Charakterystyczną cechą tworzenia oprogramowania w Agile są tak zwane "daily stand-upy" (również znane jako dzienny scrum). Jest to krótka sesja, podczas której członkowie zespołu po kolei raportują co zostało zrobione poprzedniego dnia, co zamierzają zrobić dzisiaj oraz każde przeszkody czy utrudnienia które są w stanie wykryć, a które mogłyby wpłynąć na efekt końcowy iteracji (PMI 2017, s. 53)
Ukierunkowany na jakość
Specyficzne narzędzia i techniki, takie jak: ciągła integracja, automatyczne testowanie, programowanie w parach, rozwój oparty na testach używane są do ciągłej poprawy jakości i wzbogacenia produktu. Zasada ta oparta jest na przekonaniu, że jakość jest wbudowana w oprogramowanie. (Łabuda 2015, s. 63-65)
Filozofia Agile
W porównaniu do tradycyjnego tworzenia oprogramowania, zwinne tworzenie oprogramowania głównie ma na celu tworzenie złożonych systemów oraz rozwój produktów w oparciu o dynamiczne, nieokreślone oraz nieliniowe cechy. Dokładne oszacowanie, stabilne plany oraz prognozy są bardzo często ciężkie do określenia w początkowych stadiach projektu. Zaufanie w te dane jest bardzo znikome. Użytkownicy Agile szukają minimalizacji ‘braku wiary’ potrzebnej zanim dowody wartości będą mogły być dostarczone. Wymogi oraz projekty przychodzą wraz z rozwojem projektu. Duże specyfikacje prawdopodobnie powodowałyby duże straty w większości przypadków. Te podstawowe argumenty oraz oczekiwania przemysłu poprzedzone latami sukcesów oraz porażek pomogły ukształtować zwinne podejście do rozwoju oprogramowania (PMI 2017, s. 7)
Metody rozwoju oprogramowania Agile
Metody rozwoju oprogramowania Agile wspierają szerokie grono cyklu rozwoju oprogramowania. Niektóre koncentrują się na praktykach, inne zaś skupiają się na zarządzaniu schematem pracy. Niektóre praktyki wspierają specyfikację wymogów oraz rozwoju, inne pokrywają cały cykl rozwoju oprogramowania.
Popularne metody rozwoju oprogramowania Agile obejmują (Ambler W.S., Holitza M 2012, s. 25):
- Scrum
- Kanban
- Extreme programming (XP)
- Lean Software Development
- Agile modeling
- Agile unified process (AUP)
- Disciplined agile delivery
Bibliografia
- Ambler W. S., Holitza M.,(2012). Agile For Dummies, IBM Limited Edition, John Wiley & Sons
- "Manifest programowania zwinnego"
- Kalińska-Kula M., (2015), Research-badania marketingowe według filozofii zwinnego marketingu", "Studia ekonomiczne regionu łódzkiego" nr XVII
- Konieczny M., (2014), "Przykłady wykorzystania metodyk typu Agile w zarządzaniu projektami w sektorze publicznym", "Zarządzanie publiczne", 4 (28)
- Łabuda W., (2015). Podejście zwinne a tradycyjne do projektów wytwarzania oprogramowania, Zeszyty Naukowe WWSI, nr 13, Warszawa
- Project Management Institute, (2017). Agile Practice Guide, PMI
- Spałek S., Zdonek D., (2013), "Zwinne podejście projektowe a projekty badawcze","Zeszyty naukowe Politechniki Śląskiej" nr 1894
Autor: Marcin Łasek
