Co jest takiego wspaniałego w Agile? Podstawa metodologii zwinnej

Agile Zdefiniuj jako Agile Management Systems, które istnieją już od jakiegoś czasu, ale zyskały na wartości w ostatnim czasie. W rzeczywistości, Agile Management konsekwentnie pojawia się w Top Trendach zarządzania projektami prawie każdego bloga IT Project Management każdego roku.

Zastosowania Agile w projektach informatycznych są bezdyskusyjne, ponieważ znajdują zastosowanie nie tylko w projektach oprogramowania IT, ale także w rozwoju produktów i innowacjach.

Co jest takiego wspaniałego w Agile? Zapytaj pracowników, którzy przeszli z tradycyjnego systemu na Agile, a mogą żałować stałych spotkań i „spotkań na temat spotkań”.

Okazuje się, że Agile to coś więcej niż tylko spotkania i opinie. Koncentruje się na wzmacnianiu zespołów i usuwaniu sekwencyjnych sposobów opracowywania projektów, aby zapewnić większą elastyczność i innowacje. Oznacza to jednak, że spotkania i rezultaty są częstsze niż w przypadku tradycyjnych systemów, ale także mniejsza szansa na iteracje i zmiany później włączone w cyklu projektu.

Jest reklamowany jako lekarstwo na typowe problemy, które nękają projekty związane z IT. Co to dokładnie jest i jak jest lepsze od tradycyjnych systemów?

Need for Agile Methodology - praktyki zarządzania

Każdy, kto pracował nad zwinną metodologią w projektach programistycznych, będzie miał pojęcie o niektórych typowych problemach pojawiających się w trakcie projektu: zmianie zakresu, terminach, które wydają się niemożliwe do spełnienia, i przepracowanych zasobach.

Tradycyjne metodyki zwinne w zarządzaniu projektami miały wiele wad, z powodu których nie radziły sobie z ciągle zmieniającym się środowiskiem biznesowym, szczególnie w zakresie tworzenia oprogramowania, a powyższe sytuacje były niestety zbyt powszechne. Nie oznacza to, że tradycyjne metody nigdzie nie mają zastosowania . Nadal są najlepszym wyborem dla projektów, w których pomysł jest w pełni ukształtowany od samego początku.

Praktyki zwinnego zarządzania stały się potrzebą godziny, ponieważ zaspokajały następujące potrzeby produktu wprowadzanego na rynek w dynamicznym środowisku:

  • Potrzebujesz prędkości, aby dotrzeć do produktu na rynek
  • Potrzeba elastyczności, aby uwzględnić wiele zmian specyfikacji
  • Wady scenariusza „podziału pracy”
  • Dylemat klienta
  • Potrzeba redukcji kosztów

Potrzeba prędkości, aby dotrzeć do produktu na rynek:

Żyjemy w szybko zmieniającym się środowisku, w którym elastyczność i szybkość są kluczem do sukcesu.

Technologia jest jednym z najszybciej zmieniających się sektorów w branży. Co minutę pojawia się nowszy pomysł, produkt lub innowacja. W tym kontekście tradycyjne podejście do zarządzania projektami nie przynosi rezultatów. Kolejny projekt musi koniecznie zależeć od tego, czy sprawne kroki metodologiczne zostaną wykonane w zadowalający sposób. Terminy w tradycyjnie zarządzanych projektach są zawsze kością niezgody.

Organizacje i zespoły, które nie są dynamiczne, przegrają wyścig z tymi, którzy zmieniają się, by dopasować się do zmieniającego się środowiska.

Potrzeba elastyczności, aby uwzględnić wiele zmian specyfikacji:

Oczekiwania i wymagania klientów często zmieniają się w trakcie opracowywania produktu. Zanim Agile Management Systems znalazło się w głównym nurcie, projekty informatyczne często kończyły się niepowodzeniem, ponieważ tradycyjny system zarządzania projektami został zbudowany w celu „orania”. W przypadku jakichkolwiek zmian klienci często odczuwali uszczypnięcie swoich portfeli lub linii czasu. Tradycyjny model zarządzania projektami, dostosowany z innych branż, po prostu nie działał dla dynamicznej branży, takiej jak IT.

Podział pracy:

W modelu tradycyjnym istnieją odrębne fazy, poczynając od analizy wymagań systemowych, aż do wydania i utrzymania produktu. Powoduje to podział pracy i etykietowanie członków jako „projektantów”, „programistów” lub „testerów”. Ale w rzeczywistości dzisiejsze zasoby są niezwykle cross-funkcjonalne, a takie wyraźne rozróżnienie ról nie jest możliwe w większości projektów.

Dylemat klienta:

W niestabilnych projektach bardzo często klienci nie są do końca pewni, jaki musi być ich produkt końcowy ze wszystkimi specyfikacjami. Funkcje i wymagania często się zmieniają w miarę wykonywania pracy. Tradycyjne modele, takie jak model Waterfall, podkreślają przejrzystość w odniesieniu do produktu końcowego, a odchylenia w planach kładą ogromny nacisk na system. To prowadzi nas do ostatniego czynnika, który doprowadził do opracowania systemów Agile.

Potrzeba redukcji kosztów:

Tradycyjnie odradzano zmiany wymagań w dowolnym momencie po rozpoczęciu projektu. Przeciwnie, koszty każdego dodatkowego komponentu były wysokie, czasem zbyt wygórowane. Konieczne było zatem uwzględnienie wszystkich możliwych scenariuszy na samym etapie planowania. Oznaczało to, że wszystkie scenariusze zostały wzięte pod uwagę i zaproponowano rozwiązanie. Ponieważ jednak prawie na pewno nie wiadomo, która część produktu będzie preferowana przez użytkownika, zespoły często opracowywały „rozdęte wersje” produktu. Zawierało to wszystkie możliwe scenariusze, z których typowy użytkownik wykorzystałby nie więcej niż 20%. Spowodowało to niepotrzebne koszty i rozwój.

Nie trzeba dodawać, że oznaczało to, że wszystkie projekty były planowane globalnie.

A kiedy pojawił się zupełnie nowy nieplanowany scenariusz, pomimo całego planowania, i tak były dodatkowe koszty.

Grupa ludzi spotkała się w lutym 2001 r., Aby dokładnie to omówić: potrzebę elastycznego i zwinnego modelu tworzenia oprogramowania, który pomógłby opracować produkty, które faktycznie działały dla klienta i programisty. Wynikiem tego był „Agile Manifesto”, który był zaletą tworzenia zwinnego oprogramowania metodologicznego, tj. Zestaw czterech zasad, które są tak proste, jak są opisowe. Opracowano również dwanaście „zasad zwinności” wyjaśniających, w jaki sposób systemy zwinne mogłyby faktycznie działać w środowisku projektowym.

Dzięki tej pracy doceniliśmy:

  • Osoby i interakcje dotyczące procesów i narzędzi
  • Działające oprogramowanie w obszernej dokumentacji
  • Współpraca z klientami w zakresie negocjacji umów
  • Reagowanie na zmianę po wykonaniu planu

Oznacza to, że chociaż w przedmiotach po prawej stronie znajduje się wartość, bardziej cenimy przedmioty po lewej stronie.

12 zasad zwinnych

12 zasad zwinności to zbiór koncepcji przewodnich stojących za manifestem zwinności, które wspierają zespoły projektowe we wdrażaniu projektów zwinnych. Oni są:

  1. Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie cennego oprogramowania.
  2. Przyjmujemy zmieniające się wymagania, nawet na późnym etapie rozwoju. Metodologia zwinna przetwarza zmiany w celu wykorzystania przewagi konkurencyjnej klienta.
  3. Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, z preferencją do krótszej skali czasowej.
  4. Ludzie biznesu i programiści muszą codziennie współpracować przez cały czas trwania projektu.
  5. Twórz projekty wokół zmotywowanych osób. Daj im środowisko i wsparcie, którego potrzebują, i ufaj im, że wykonają zadanie.
  6. Najbardziej wydajną i skuteczną metodą przekazywania informacji do zespołu programistów i w jego obrębie jest rozmowa twarzą w twarz.
  7. Działające oprogramowanie jest podstawową miarą postępu.
  8. Zwinne procesy metodologiczne 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 design zwiększają zwinność.
  10. Prostota - sztuka maksymalizacji ilości niewykonanej pracy - jest niezbędna.
  11. Najlepsze architektury, wymagania i projekty powstają z samoorganizujących się zespołów.
  12. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć skuteczność, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie.

Przykład projektu wymagającego zwinnego zarządzania

Wyobraź sobie start-up, który tworzy aplikację mobilną dla klienta. Zamrożenie całego projektu aplikacji przed rozpoczęciem programowania może być katastrofalne. Jest również ograniczony czas na przeprowadzenie badania rynku, sporządzenie szczegółowego planu, wybranie wariantów, które chcą zaoferować, a następnie opracowanie produktu. Oprócz ogromnych kosztów związanych z tym podejściem, ryzykują, że inna firma może opracować aplikację, zanim to zrobią.

Zwinna metodologia zarządzania projektami pomaga przezwyciężyć te problemy. W ramach tego systemu aplikacja jest opracowywana etapami, z interakcją z klientem każdego dnia, a cele lub etapy projektu określane są, powiedzmy, na każdy tydzień.

Wiele zespołów może również pracować nad tą samą aplikacją, co znacznie skraca czas programowania.

Funkcje są dopracowywane przy każdym spotkaniu, a produkt końcowy odzwierciedla ostateczną potrzebę. Uczą się krok po kroku, co działa dla klienta i improwizują oferty, aż uzyskają pożądany produkt.

W tradycyjnym podejściu do zarządzania projektami przed wypuszczeniem produktu pomyślałby się o wszystkich zmianach. Spowodowałoby to przekroczenie terminów, zwiększenie obciążenia pracą i inflację kosztów. Co więcej, produkt mógł całkowicie stracić na znaczeniu do czasu wydania.

Jak dokładnie działa Agile Management?

Chociaż zwinne zarządzanie jest najczęściej określane jako koncepcja IT, jego zastosowania nie ograniczają się do branży IT. Na przykład sieć sprzedaży detalicznej odzieży Zara wykorzystała zasady Agile Management do przekształcenia swojej działalności.

Stosując zasady Agile, Zara wytwarzała produkty małymi partiami, zamiast koncentrować się na dużej produkcji przed nowym sezonem. Dzięki tej metodzie firma uniknęła kosztów związanych z wysokimi zapasami i nieprzewidywalnymi ofertami rabatowymi.

Niektóre kluczowe aspekty Agile Project Management to:

  • Agile Project Management stosuje elastyczne podejście.

Zwinne zarządzanie z zadowoleniem przyjmuje uzupełnienia i zmiany w trakcie opracowywania produktu, zamiast dostosowywać go do oryginalnych specyfikacji.

  • Zwinne projekty są zwykle podzielone na osobne części pracy, a zespoły są zaangażowane w opracowanie jednego lub więcej z tych „części” pracy.

Możliwe jest na przykład, że cztery zespoły pracują jednocześnie nad różnymi częściami projektu, dzięki czemu terminy projektu zostaną skrócone. Zespoły codziennie koordynują się ze sobą oraz z klientem w celu dostarczenia produktów.

  • Odbywają się codzienne spotkania na temat postępów lub przeszkód w projekcie z ciągłym sprzężeniem zwrotnym.

Po otrzymaniu opinii od klientów zmiany są uwzględniane, a zespoły przechodzą do następnej części. Proces ten zapewnia produkt, który jest bardziej dynamiczny i lepiej dostosowany do potrzeb klienta.

  • Członkowie zespołu są bardziej zaangażowani niż odgórnie.

W cyklu życia oprogramowania członkowie zespołu biorą udział we wszystkich etapach: wymaganiu, projektowaniu, rozwoju i zwinnym testowaniu metodologii. Ponieważ istnieje regularny przegląd wydajności zadań, członkowie zespołu odpowiednio dostosowują zachowanie i procedury.

  • Profil kierownika projektu w projekcie Agile zmieni się z tradycyjnej roli.

Nie spędza już dużo czasu na planowaniu lub monitorowaniu zasobów, ale teraz spędza więcej czasu na współpracy z zespołami i upewnieniu się, że ogólny obraz jest zawsze widoczny. Nie jest to łatwe przejście, a menedżerowie przechodzący na systemy Agile muszą szybko się dostosować, aby projekt odniósł sukces.

Kilka słów o Scrumie:

Scrum to jedna z najpopularniejszych platform do wdrażania metodyki Agile. Co to jest metodologia zwinna? Jest wcześniejszy niż Agile i został po raz pierwszy zaproponowany w 1986 r. I wdrożony w przemyśle motoryzacyjnym i drukarskim.

Metodologia zwinna z Scrum nie jest synonimem; istnieją inne frameworki, które można wykorzystać do wdrożenia Agile, ale Scrum jest jednym z najbardziej skutecznych i prawdopodobnie najpopularniejszym. Co to jest Scrum? Scrum ma zwykle tylko trzy role: właściciela produktu, zespół i mistrza Scrum. Mistrz metodologii Scrum nie jest kierownikiem projektu. Obowiązki tradycyjnej roli kierownika projektu są podzielone na trzy role zarządzania projektami Scrum. Projekt jest wbudowany w szereg iteracji o stałej długości, zwanych sprintami. Sukces każdego zwinnego sprintu metodologicznego wywołuje poczucie namacalnego postępu i ciągłej inspiracji. Celem każdej iteracji jest wytworzenie działającego produktu, który można przedstawić interesariuszom. Zwinny scrum master scrum master współpracuje z właścicielem produktu i zespołem, aby ułatwić realizację celów poprzez usunięcie przeszkód. Zwinny zespół programistów ds. Metodologii jest interdyscyplinarny i oprócz programistów obejmuje testerów, projektantów i inżynierów operacyjnych.

Tradycyjne zarządzanie projektami: wodospad

Jednym z najbardziej znanych tradycyjnych systemów zarządzania projektami jest wodospad. Był często używany od 1970 roku. Istnieje kilka dobrze znanych i szeroko wdrażanych metodologii kaskadowych w projektach informatycznych. Należą do nich PRINCE2, który został stworzony przez rząd Zjednoczonego Królestwa dla jego sektora publicznego.

Podobnie jak sugeruje nazwa, jest to sekwencyjny przepływ pracy. Produkt końcowy jest ustalany na początku projektu. Następnie poszczególne etapy przepływu pracy są wykonywane sekwencyjnie (inicjacja koncepcji, analiza, projektowanie, budowa, testowanie, wdrożenie i utrzymanie). Po zakończeniu poprzedniego kroku programiści przechodzą do następnego kroku. Plan projektu powinien być głupi; po zakończeniu etapu w sekwencji programiści nie mogą wrócić do niego bez ponownego uruchomienia. Jest to statyczne podejście do zwinnej metodologii zarządzania projektami. Nie ma miejsca na zmiany lub błędy, dlatego należy starannie przestrzegać planu projektu dotyczącego metodyki zwinnej.

Można wyciągnąć analogię między zarządzaniem wodospadem a malowaniem arcydzieła. Obraz ostatecznego arcydzieła jest już w umyśle artysty i stale do niego dąży. Jeśli z jakiegokolwiek powodu produkt końcowy różni się od wizualizowanego, nie może go łatwo zmodyfikować.

Zwinny czy wodospad?

  • Co to jest Agile? Agile jest bardziej odpowiedni dla małych zespołów pracujących nad projektami przyrostowymi i ewolucyjnymi, podczas gdy Waterfall nadaje się do dużych projektów lub projektów rozwojowych. Zarządzanie wodospadami może być lepiej dostosowane do branż takich jak budownictwo. Zwinność jest wykorzystywana w bardziej dynamicznych projektach, takich jak projekty branży IT.
  • Zwinne systemy wymagają wysoko wykwalifikowanych członków zespołu, którzy są w stanie obsłużyć wszystkie etapy projektu. Wymaga to radykalnej zmiany roli kierownika projektu. Proces kaskadowy ma bardziej tradycyjną strukturę, jest liniowy i być może jest łatwiejszy do zrozumienia dla osób, które nie są programistami i nowymi programistami.
  • Wiele organizacji uważa metodologię wodospadu za pocieszającą, ponieważ jest ona lepiej udokumentowana. Zwinny znany jest z tego, że nie podkreśla obszernej dokumentacji. Jest bardziej zależny od ludzi, co może być niewygodne w organizacjach, w których wskaźnik zużycia jest wysoki.
  • Mniejsze, proste projekty mogą nie wymagać ram metodologii zwinnej, a sekwencyjny model wodospadu może równie dobrze działać.

Gdzie to wszystko zmierza?

Według ankiety HP przeprowadzonej w maju 2015 r. Metodologia zwinnego programowania stanowi ponad dwie trzecie wszystkich projektów IT w USA.

Ale Agile nie zawsze jest „idealnym” rozwiązaniem. Nie jest to rozwiązanie uniwersalne, dlatego wiele organizacji (24% według ankiety HP) przyjęło podejście hybrydowe.

Hybrydowe metody Agile i Waterfall mogłyby wykorzystać zalety obu. To hybrydowe podejście może działać w przypadku skomplikowanych projektów z klientami zewnętrznymi i dużymi zespołami. Podejście to opisali Erick Bergmann i Andy Hamilton. Jest to kompromis między tymi dwiema metodami, umożliwiający zespołom oprogramowania „sprawną” pracę, podczas gdy zespoły programistów i menedżerowie produktu korzystają z tradycyjnej metody.

Mark Fromson, konsultant cyfrowy, wskazuje na inny sposób działania hybrydy:

Podział projektu na fazy przypominające wodospad, aby umożliwić zawieranie umów o stałej stawce i określony zakres w mniejszej fazie, ale utrzymanie płynności projektu jako całości.

Bez względu na formę, jaką przyjmą przyszłe zespoły, jasne jest, że rozwój metodologii zwinnej pozostanie. Umożliwiło to elastyczność, oszczędność czasu i kosztów, a także najważniejszy ze wszystkich czynników: dawanie poczucia satysfakcji i motywującej atmosfery ludziom, którzy pracują nad tymi projektami.

Źródło:

Dla Agile Manifesto i The 12 Agile Principles- www.agilemanifesto.org

Powiązane kursy: -

Zwinne zarządzanie projektami - poznaj metodyki zwinne

Kategoria:

Rozwój przedsiębiorczości