Manifest Agile: Różnice pomiędzy wersjami
m (Infobox update) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 17 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
''Manifest Agile'', również znany jako ''Manifest dla Deweloperów Oprogramowania'' został opublikowany w 2001 roku i zawiera podstawowe zasady zwinnego [[zarządzanie projektami|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.[[metodyka PMI|PMBOK]], [[metodyka PCM|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. | |||
<google>n</google> | |||
==Zasady rozwoju oprogramowania Agile== | ==Zasady rozwoju oprogramowania Agile== | ||
Rozwój oprogramowania Agile oparty jest na dwunastu zasadach (Ambler W.S., Holitza M 2012, s. 9): | |||
Rozwój oprogramowania Agile oparty jest | # Priorytetem jest [[zadowolenie klienta]] poprzez wczesne i ciągle dostarczanie cennego oprogramowania. | ||
# Priorytetem jest zadowolenie klienta poprzez wczesne i ciągle dostarczanie cennego oprogramowania. | # Pozytywne przyjmowanie zmieniających się potrzeb, nawet późno w rozwoju oprogramowania. | ||
# Pozytywne przyjmowanie zmieniających się potrzeb, nawet | # Działające oprogramowanie jest dostarczane często (z reguły tygodniowo). | ||
# Działające oprogramowanie jest dostarczane często (z reguły tygodniowo). | # Bliska [[współpraca]] pomiędzy interesariuszami a deweloperami. | ||
# Bliska współpraca pomiędzy interesariuszami a deweloperami. | |||
# Projekty są tworzone wokół zmotywowanych osób, którym powinno się ufać. | # Projekty są tworzone wokół zmotywowanych osób, którym powinno się ufać. | ||
# Komunikacja "twarzą w twarz" jest najlepszą komunikacją. | # [[Komunikacja]] "twarzą w twarz" jest najlepszą komunikacją. | ||
# Działające oprogramowanie jest podstawowym miernikiem sukcesu. | # Działające oprogramowanie jest podstawowym miernikiem sukcesu. | ||
# Stały rozwój, umożliwiający równe tempo. | # Stały rozwój, umożliwiający równe tempo. | ||
# Ciągłe skupianie uwagi nad techniczną doskonałością i dobrym projektem. | # Ciągłe skupianie uwagi nad techniczną doskonałością i dobrym projektem. | ||
# Niezbędna jest prostota | # Niezbędna jest prostota - sztuka maksymalizowania ilości pracy niewykonanej. | ||
# Najlepsze wymogi i projekty wychodzą z zespołów, które się samoorganizują | # 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 | # 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== | ==Zarys ogólny== | ||
'''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 | 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 | 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ść]]''' | ||
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== | ==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. | 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== | ||
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]] | |||
Popularne metody rozwoju oprogramowania Agile | * [[Kanban]] | ||
*[[Scrum]] | * [[Metodyka Extreme Programming|Extreme programming (XP)]] | ||
*[[Kanban]] | * [[Lean Software Development]] | ||
*[[Metodyka Extreme Programming|Extreme programming (XP)]] | |||
*[[Lean Software Development]] | |||
* Agile modeling | * Agile modeling | ||
* Agile unified process (AUP) | * Agile unified process (AUP) | ||
* Disciplined agile delivery | * Disciplined agile delivery | ||
{{infobox5|list1={{i5link|a=[[Scaled agile framework]]}} — {{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Testowanie w projekcie]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Scrum of scrums]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Lean Software Development]]}} — {{i5link|a=[[Test driven development]]}} — {{i5link|a=[[Metodyka MSF]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Ambler W | <noautolinks> | ||
* Kalińska-Kula M. | * Agile Manifesto (2001), ''[https://agilemanifesto.org/ Manifesto for Agile Software Development]'' | ||
* Konieczny M. | * Ambler W., Holitza M. (2012), ''Agile For Dummies'', IBM Limited Edition, John Wiley & Sons | ||
*Łabuda W. | * Kalińska-Kula M. (2015), ''Research-badania marketingowe według filozofii zwinnego marketingu'', Studia ekonomiczne regionu łódzkiego nr XVII | ||
* | * Konieczny M. (2014), ''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 | |||
* Spałek S., Zdonek D. | * PMI (2017), ''Agile Practice Guide'', PMI | ||
* Spałek S., Zdonek D. (2013), ''[https://yadda.icm.edu.pl/baztech/element/bwmeta1.element.baztech-2ed36bf2-960e-4782-b3f7-24d2d7349836/c/Spalek_ZNOiZ_64_2013.pdfZwinne podejście projektowe a projekty badawcze]'', Zeszyty naukowe Politechniki Śląskiej, nr 1894 | |||
</noautolinks> | |||
{{a|Marcin Łasek}} | {{a|Marcin Łasek}} | ||
[[Kategoria:Zarządzanie projektami]] | |||
{{#metamaster:description|Manifest Agile to formalna proklamacja zasad zwinnego zarządzania projektami, oparta na prostocie kodu, częstym testowaniu i dostarczaniu funkcjonalności. Jest alternatywą dla modelu kaskadowego.}} | |||
Aktualna wersja na dzień 17:39, 19 gru 2023
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
| Manifest Agile — artykuły polecane |
| Scaled agile framework — Metodyka Extreme Programming — Testowanie w projekcie — Feature-Driven Development — Scrum of scrums — Backlog produktu — Lean Software Development — Test driven development — Metodyka MSF |
Bibliografia
- Agile Manifesto (2001), Manifesto for Agile Software Development
- Ambler W., Holitza M. (2012), Agile For Dummies, IBM Limited Edition, John Wiley & Sons
- Kalińska-Kula M. (2015), Research-badania marketingowe według filozofii zwinnego marketingu, Studia ekonomiczne regionu łódzkiego nr XVII
- Konieczny M. (2014), 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
- PMI (2017), Agile Practice Guide, PMI
- Spałek S., Zdonek D. (2013), podejście projektowe a projekty badawcze, Zeszyty naukowe Politechniki Śląskiej, nr 1894
Autor: Marcin Łasek
