Menu

Manifest Agile: Zrozumienie wartości i zasad Agile

  • Główny
  • Inny
  • Manifest Agile: Zrozumienie wartości i zasad Agile

agile manifesto understanding agile values

Manifest Agile Wprowadzenie:

Nasz poprzedni samouczek dotyczący Agile Methodology szczegółowo wyjaśnił nam wszystkie modele i metodologie Agile.

Ale do tej pory nie zajmowaliśmy się tym, dlaczego istniała potrzeba przede wszystkim zwinności i jak zwinna przezwyciężyła wady istniejących metodologii tworzenia oprogramowania, takich jak model kaskadowy.

W tym samouczku zagłębimy się w szczegóły dotyczące agile i manifestu agile. Zobaczymy, co mówi manifest i jakie są zapisane w nim wartości i zasady.

zwinny manifest

Czego się nauczysz:

Wprowadzenie

Jak widzieliśmy w naszym poprzedni tutorial , wcześniejsze metodologie rozwoju zajmowały zbyt dużo czasu i zanim oprogramowanie było gotowe do wdrożenia, wymagania biznesowe uległyby zmianie, a tym samym nie odpowiadały bieżącym potrzebom.

Szybkość zmian, której wówczas brakowało, powodowała wiele problemów. Kiedy liderzy różnych metodologii rozwoju spotkali się, aby zdecydować o dalszych krokach i byli w stanie uzgodnić lepszą metodę, a także mogli sfinalizować treść manifestu.

Zostało to ujęte jako 4 wartości i 12 zasad, aby pomóc praktykom zrozumieć, odnieść się do tego i zastosować w praktyce. I w tamtym czasie żaden z nich nie mógł sobie wyobrazić wpływu, jaki będzie to miało na przyszłość zarządzania projektami.

Manifest Agile

Manifest został bardzo starannie sformułowany, aby uchwycić istotę agile w minimalnych słowach i brzmi jak poniżej:

„Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym to robić. Dzięki tej pracy doszliśmy do poniższej wartości:

  • Osoby i interakcje nad procesami i narzędziami.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpraca z klientem zamiast negocjacji umowy.
  • Reagowanie na zmianę zgodnie z planem.

Oznacza to, że chociaż pozycje po prawej mają wartość, bardziej cenimy te po lewej ”.

Jak widać, są to dość zwięzłe i proste stwierdzenia, które bardzo jasno pokazują, co założyciele chcieli promować. Zwykle tradycyjne plany projektów są sztywne i kładą nacisk na procedury i ramy czasowe, ale manifest zwinny propaguje dokładnie odwrotne rzeczy.

Woli:

  • Ludzie
  • Produkt
  • Komunikacja i
  • Reakcja na coś

Zbadamy ten nowy paradygmat, który założyciele chcieli szczegółowo promować, uzyskując głębsze zrozumienie wartości i zasad zwinnych.

4 wartości zwinne

Cztery wartości wraz z 12 zasadami kierują elastycznym dostarczaniem oprogramowania. Omówimy teraz szczegółowo każdą z wartości.

Wartości zwinne

# 1) Osoby i interakcje zamiast procesów i narzędzi

Osoby i interakcje są bardziej preferowane niż procesy i narzędzia, ponieważ dzięki temu proces jest bardziej responsywny. Jeśli osoby są zgodne i gdy się rozumieją, zespół może rozwiązać wszelkie problemy z narzędziami lub procesami.

Ale jeśli zespoły będą nalegać na ślepe trzymanie się procesów, może to spowodować nieporozumienia wśród osób i stworzyć nieoczekiwane blokady drogowe, skutkujące opóźnieniami w realizacji projektów.

Dlatego zawsze lepiej jest mieć interakcje i komunikację między członkami zespołu niż ślepo polegać na procesach, które prowadzą naprzód. Jednym ze sposobów osiągnięcia tego jest zaangażowanie właściciela produktu, który pracuje i może podejmować decyzje we współpracy z zespołem programistów.

Zezwolenie na samodzielne wnoszenie wkładu pozwala im również na swobodne prezentowanie tego, co mogą wnieść do stołu. Kiedy te interakcje zespołowe są ukierunkowane na rozwiązanie typowego problemu, wyniki mogą być dość potężne.

# 2) Działające oprogramowanie zamiast kompleksowej dokumentacji

Tradycyjne zarządzanie projektem obejmowało obszerną dokumentację, co wiązało się z kilkumiesięcznym opóźnieniem. Miało to negatywny wpływ na realizację projektu, a wynikające z tego opóźnienia były nieuniknione.

Dokumentacja stworzona dla tych projektów była bardzo szczegółowa i powstało tak wiele dokumentów, że wiele z nich nie zostało nawet powołanych w trakcie realizacji projektu. To było niepotrzebne zło, z którym żyły zespoły projektowe.

Ale to również zaostrzyło problemy z dostawą. Skupiono się na dokumentacji do tego stopnia, że ​​zespoły chciały skończyć z gotowym produktem, który byłby w 100% zgodny ze specyfikacjami. Dlatego skupiono się na uchwyceniu wszystkich specyfikacji w szczegółach.

Jednak produkt końcowy był kiedyś zupełnie inny od oczekiwań lub straciłby na znaczeniu. Dlatego agile mówi, że działające oprogramowanie jest znacznie lepszą opcją do oceny oczekiwań klientów niż stosy dokumentacji.

Nie oznacza to, że dokumentacja nie jest konieczna. Oznacza to po prostu, że działający produkt jest każdego dnia lepszym wskaźnikiem dopasowania do potrzeb i oczekiwań klienta niż dokument utworzony kilka miesięcy temu. Oznacza to również, że zespoły są responsywne i gotowe do dostosowywania się do zmian w razie potrzeby, pokazując klientowi działające oprogramowanie po zakończeniu sprintu.

Brak przetestowania produktu podczas sprintów pociąga za sobą wielorakie koszty i nakłady pracy w następnym sprincie. Po wdrożeniu funkcji koszt tych zmian znacznie wzrasta.

3. Współpraca z klientem zamiast negocjacji umowy

Negocjacje oznaczają, że szczegóły są nadal rejestrowane i nie zostały sfinalizowane. Nadal istnieje możliwość renegocjacji. Ale po zakończeniu negocjacji nie można o nich dyskutować. Agile mówi, że zamiast negocjacji, postaw na współpracę.

Współpraca oznacza, że ​​wciąż jest miejsce na dyskusję, a komunikacja trwa.

Nie jest to jednorazowa rzecz. Daje to podwójną przewagę - podczas gdy pomaga zespołowi dokonać korekty kursu, jeśli jest to wymagane na wcześniejszym etapie, pomaga klientowi również udoskonalić jego wizję i przedefiniować wymagania, jeśli zajdzie taka potrzeba w trakcie projekt.

jak zrobić listę w java

Innym aspektem jest to, że podczas gdy tradycyjne modele tworzenia oprogramowania angażują klienta przed rozpoczęciem opracowywania w fazie dokumentacji i negocjacji, a oni nie są tak zaangażowani podczas opracowywania projektu.

Gdy wymagania zostaną zamrożone, widzą produkt dopiero, gdy produkt jest gotowy. Agile przełamuje również tę barierę, umożliwiając zaangażowanie klienta przez cały cykl życia.

Pomaga to zespołom zwinnym lepiej dostosować się do potrzeb klientów. Jednym ze sposobów osiągnięcia tego jest oddany i zaangażowany właściciel produktu, który może pomóc zespołowi w czasie rzeczywistym w wyjaśnieniach i dostosowaniu pracy do priorytetów klienta

4. Reagowanie na zmiany po wykonaniu planu

Standardowy sposób myślenia jest taki, że zmiany są kosztowne i powinniśmy unikać zmian za wszelką cenę. Właśnie na tym niepotrzebnie skupia się dokumentacja i szczegółowe plany realizacji, trzymając się terminów i specyfikacji produktów.

Ale jak uczy nas również doświadczenie, zmiany są przeważnie nieuniknione i zamiast uciekać od nich, powinniśmy spróbować je ogarnąć i zaplanować.

Agile pozwala nam na to przejście. Agile uważa, że ​​zmiana nie jest kosztem, to mile widziana informacja zwrotna, która pomaga ulepszyć projekt. Nie należy tego unikać, ale zamiast tego dodaje wartości.

Dzięki krótkim sprintom proponowanym przez Agile zespoły mogą uzyskać szybką informację zwrotną i zmienić priorytety w krótkim czasie. Od iteracji do iteracji można dodawać nowe funkcje.

Dlaczego to robimy? Ponieważ większość funkcji opracowanych przy użyciu metody kaskadowej nigdy nie jest używana. Dzieje się tak, ponieważ model wodospadu jest zgodny z planem, podczas gdy jest to faza, w której wiemy najmniej.

Agile również planuje, ale również stosuje podejście just in time, w którym planowanie jest wykonywane tylko wtedy, gdy jest to potrzebne. Plany są zawsze otwarte na zmiany w miarę postępu sprintu.

12 zasad Agile

Istnieje 12 zasad zwinnych, które zostały dodane po utworzeniu manifestu, aby pomóc zespołom i pokierować nimi w przejściu na agile i sprawdzić, czy stosowane przez nich praktyki są zgodne z kulturą zwinną.

Poniżej znajduje się tekst oryginalnych 12 zasad, opublikowanych w 2001 roku przez Agile Alliance:

# 1) Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesną i ciągłą dostawę wartościowego oprogramowania.

#dwa) Witamy zmieniające się wymagania, nawet na późnym etapie rozwoju. Elastyczne procesy wykorzystują zmiany do uzyskania przewagi konkurencyjnej klienta.

# 3) Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, preferując krótsze ramy czasowe.

# 4) Ludzie biznesu i programiści muszą codziennie współpracować przez cały projekt.

# 5) Twórz projekty wokół zmotywowanych osób. Zapewnij im środowisko i wsparcie, którego potrzebują, i ufaj, że wykonają swoją pracę.

# 6) Najbardziej wydajną i skuteczną metodą przekazywania informacji zespołowi programistycznemu i wewnątrz niego jest rozmowa twarzą w twarz.

# 7) Działające oprogramowanie jest podstawowym miernikiem postępu.

co to jest plik flash Shockwave

# 8) Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

# 9) Ciągła dbałość o doskonałość techniczną i dobry projekt zwiększa zwinność.

# 10) Prostota - sztuka maksymalizacji ilości niewykonanej pracy jest bardzo ważna.

#jedenaście) Najlepsze architektury, wymagania i projekty powstają dzięki samoorganizującym się zespołom.

# 12) W regularnych odstępach czasu zespół zastanawia się, jak stać się bardziej efektywnym, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie.

Te zwinne zasady zapewniają praktyczne wskazówki dla zespołów programistycznych.

Innym sposobem uporządkowania 12 zasad jest rozważenie ich w następujących czterech odrębnych grupach:

  • Satysfakcja konsumenta
  • Jakość
  • Praca zespołowa
  • Zarządzanie projektami

# 1) Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania - Klienci będą oczywiście zachwyceni, widząc działające oprogramowanie, które jest dostarczane podczas każdego sprintu, zamiast konieczności przechodzenia przez niejednoznaczny okres oczekiwania, pod koniec którego tylko oni będą mogli zobaczyć produkt.

Tutaj klienta można zdefiniować jako sponsora projektu lub osobę, która płaci za rozwój. Końcowy użytkownik produktu jest także klientem, ale możemy je rozróżnić, ponieważ użytkownik końcowy jest określany jako użytkownik.

#dwa) Witamy zmieniające się wymagania, nawet na późnym etapie rozwoju. Elastyczne procesy wykorzystują zmiany, aby uzyskać przewagę konkurencyjną klienta - Zmiany można wprowadzać bez większych opóźnień w ogólnych terminach.

Ponieważ zespoły zwinne wierzą przede wszystkim w jakość, wolą raczej wprowadzać zmiany i dostarczać je zgodnie z wymaganiami klienta, niż unikać zmian i dostarczać produkt, który nie spełnia potrzeb biznesowych.

# 3) Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, preferując krótsze ramy czasowe - Dbają o to zespoły pracujące w sprintach. Ponieważ sprinty są iteracjami ograniczonymi czasowo i dostarczają działające oprogramowanie pod koniec każdego sprintu, klienci regularnie mają pojęcie o postępie

# 4) Ludzie biznesu i programiści muszą codziennie współpracować przez cały projekt - Lepsze decyzje są podejmowane, gdy oboje pracują razem, a między nimi istnieje ciągła pętla sprzężenia zwrotnego w celu korekty kursu i sprawności zmiany. Komunikacja między interesariuszami jest zawsze kluczem w agile.

# 5) Twórz projekty wokół zmotywowanych osób. Zapewnij im środowisko i wsparcie, którego potrzebują, i zaufaj im, że wykonają swoją pracę - Musisz wspierać, ufać i motywować zespoły. Zmotywowany zespół ma większe szanse na odniesienie sukcesu i dostarczy lepszy produkt niż nieszczęśliwe zespoły, które nie chcą dać z siebie wszystkiego.

Jednym ze sposobów na to jest wzmocnienie zespołu programistów do samoorganizacji i podejmowania własnych decyzji.

# 6) Najbardziej wydajną i skuteczną metodą przekazywania informacji do zespołu programistów i wewnątrz niego jest rozmowa twarzą w twarz - Komunikacja jest lepsza i bardziej skuteczna, jeśli zespoły znajdują się w tym samym miejscu i mogą spotykać się twarzą w twarz w celu dyskusji. Pomaga budować zaufanie i zapewnia zrozumienie wśród różnych interesariuszy.

# 7) Działające oprogramowanie jest podstawowym miernikiem postępu - Działające oprogramowanie przewyższa wszystkie inne wskaźniki KPI i jest najlepszym wskaźnikiem wykonanej pracy.

# 8) Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność - Podkreśla się spójność dostaw. Zespół powinien być w stanie utrzymać swoje tempo przez cały czas trwania projektu i nie wypalić się po kilku pierwszych sprintach.

# 9) Ciągła dbałość o doskonałość techniczną i dobry projekt zwiększa zwinność - Zespół powinien mieć wszystkie umiejętności i dobry projekt produktu, aby poradzić sobie ze zmianami i wytworzyć produkt wysokiej jakości, będąc w stanie wprowadzać zmiany

# 10) Prostota - Sztuka maksymalizacji ilości niewykonanej pracy jest niezbędna i wystarczy, aby spełnić definicję wykonanej pracy.

#jedenaście) Najlepsze architektury, wymagania i projekty powstają dzięki samoorganizującym się zespołom - Samoorganizujące się zespoły są uprawnione i przejmują odpowiedzialność za swoją pracę. Prowadzi to do otwartej komunikacji i regularnego dzielenia się pomysłami między członkami zespołu.

# 12) Zespół w regularnych odstępach czasu zastanawia się, jak stać się bardziej efektywnym, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie - Samodoskonalenie prowadzi do szybszych wyników i mniejszej liczby poprawek.

Wniosek

Zorientowanie na klienta i skupienie się na komunikacji sprawiły, że zwinny sukces jest widoczny dzisiaj.

Jest to sprawdzona technika mająca wpływ nie tylko na dostarczanie oprogramowania, ale także w innych branżach, a dziś stała się branżą samą w sobie.

Nasz nadchodzący samouczek z tej serii wyjaśni więcej o Zespole Scrumowym i jego rolach !!

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^