Co to jest metodologia zwinna? [Zamknięte]

Czy ktoś może wyjaśnić metodykę zwinną w prostych zdaniach?

Zwinność to wiele rzeczy i praktyk, ale myślę, że jej sednem jest tylko iteracyjny rozwój.

Iteratywny: Pomyśl o kilku bardzo małych wodospadach. Oznacza to, że metoda kaskadowa (wymagania-> specyfikacja-> kod-> test), ale zamiast robić to w ciągu około roku, robisz to w ciągu kilku tygodni dla rozsądnego kawałka całości projekt. Na końcu „iteracji / sprintu / przyrostu” masz mały, ale kompletny i przetestowany zestaw dodatkowych funkcji.

Pozwala to szybko zmienić przebieg projektu, jeśli okaże się, że to, co robisz, nie jest tym, czego chce klient, zmiana potrzeb biznesowych, czy cokolwiek innego. Stąd termin „zwinny”.

Myślę, że nic nie lepiej niż sam Manifest Agile:

Odkrywamy lepsze sposoby tworzenia
oprogramowania, robiąc to i pomagając innym.
Dzięki tej pracy doceniliśmy:

Osoby i interakcje między procesami i narzędziami
Oprogramowanie robocze nad obszerną dokumentacją
Współpraca z klientami nad negocjacjami umowy
Reagowanie na zmianę w związku z planem

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

z http://agilemanifesto.org/

Dla mnie najważniejszy pomysł to:

Nastąpią zmiany wymagań, ponieważ jesteśmy zmuszeni do projektowania oprogramowania przy minimalnej wiedzy na temat tego, co jest potrzebne (początek projektu), a wymagania staną się wyraźniejsze dopiero w trakcie realizacji projektu.

Tradycyjne (wodospad) podejścia próbują złagodzić tę zmianę, blokując wszystkich na początku projektu poprzez podpisanie się pod wyczerpującymi specyfikacjami. Może to działać jako CYA, ale nie uszczęśliwia nikogo, kto dostarcza coś, co nie zaspokaja potrzeb użytkowników, zwłaszcza jeśli ich sprzeciw zostanie spełniony z „Cóż, podpisałeś się na to!”

Metody zwinne mają na celu uwzględnienie nieuchronnych zmian, zamiast chronić zespół programistów przed nimi. Robi to na wiele sposobów, z których najważniejszym jest iteracyjny rozwój i ciągłe zaangażowanie zainteresowanych stron w ten proces. Z mojego doświadczenia wynika, że ​​w końcu wszyscy są bardziej szczęśliwi, chociaż może to być bardziej niewygodne dla niektórych typów zarządzania, którzy są zagorzałymi planistami.

W jednym zdaniu wygląda to tak:

Zwinne tworzenie oprogramowania to grupa metodologii opracowywania oprogramowania opartych na iteracyjnym i przyrostowym rozwoju, w których wymagania i rozwiązania ewoluują dzięki współpracy między samoorganizującymi się, wielofunkcyjnymi zespołami .

Pochodzi z definicji wikipedii i bardzo mi się podoba. Podkreśliłem podstawowe zasady.

Chciałbym tylko dodać również, czym NIE jest Agile. Istnieje wiele sklepów, które twierdzą, że są zwinne, ale w ten sposób oznacza to, że nie są zainteresowane planowaniem swoich projektów i oczekują rzeczy wykonanych w nieuzasadnionym krótkim czasie.

Zwinny! = Brak planu projektu. Trudno jest poradzić sobie z ludźmi, którzy domyślnie uważają, że to stwierdzenie jest fałszywe, ponieważ zwykle są typami kierownictwa i nie zawsze łatwo jest im zaprzeczać.

Andy powiązał już z Manifestem Zwinności, o którym myślę, że właśnie to opisuje.

Myślę, że warto również przyjrzeć się, skąd wziął się Manifest Agile. Istnieje wiele metodologii, które mają pewne wspólne elementy i wiele podobnych motywacji: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming (lista z Alistair Cockburn ). Ludzie proponujący te metodologie postanowili opracować termin marketingowy obejmujący to, co ich łączy, aby siła tego, co mówili, została wzmocniona.

Co ciekawe (zgodnie z tym, co ktoś mi powiedział) na krótkiej liście znalazło się kilka nazw, które można było wybrać zamiast „Agile” - jednym z nich było „Adaptive”. Osobiście uważam, że jako jedno słowo, które lepiej podsumowuje, czym tak naprawdę jest zwinność, niż „zwinność”!

Zastosowanie zwinnej metodologii sprowadza się do podkreślenia jakości dostarczania produktów w porównaniu z innymi aspektami rozwoju produktu i uświadomienia sobie, że informacje zwrotne od społeczności użytkowników są istotną częścią tworzenia produktów wysokiej jakości.

Porównaj to z tradycyjnym podejściem do projektowania / wodospadu, które kładzie nacisk na wstępne projektowanie, dokumentację i definicję interfejsu, jednocześnie zmniejszając nacisk na wdrażanie i przechodzenie produktu od rozwoju do wydania.

Moim zdaniem zespół ma wbudowaną jakość produktu. Widzę to w formie weryfikacji, czy produkt funkcjonuje zgodnie z zamierzeniami zespołu programistycznego i może w rozsądny sposób uwzględniać możliwe do przewidzenia ulepszenia. Istnieją również czynniki jakościowe oparte całkowicie na percepcji, które mierzą, jak dobrze produkt spełnia potrzeby jego użytkowników.

Podejścia zwinne mają tendencję do iteracyjnego dostarczania produktów , włączając opinie użytkowników i deweloperów do każdej iteracji, i promują dostarczanie każdego przyrostu funkcjonalności, gdy osiąga minimalną żywotność jako funkcję wymuszającą uzyskiwanie częstych opinii użytkowników i przeciwdziałanie tendencji do kontynuowania działań programistycznych przedłużone okresy czasu bez informacji zwrotnych od użytkowników. Moim zdaniem inne aspekty zwinnego podejścia wspierają te kluczowe założenia.

• Podkreślanie częstej współpracy z klientem generuje informacje zwrotne od użytkowników, pozostając jednocześnie elastycznym na zmiany wymagań, dzięki czemu rozwój produktu może regularnie je integrować
• Częsta integracja z odpowiednimi konfiguracjami i środowiskami wdrażania idzie w parze z ciągłą identyfikacją, które konfiguracje i środowiska pozostają istotne, aby zapewnić, że produkt pozostanie cenny i odpowiedni dla użytkowników przesyłających opinie
• Samoorganizacja i promowanie zespołów wielofunkcyjnych przemawia na rzecz tworzenia osobistej odpowiedzialności w zespole i umożliwienia zespołowi określenia, w jaki sposób najlepiej usunąć przeszkody w skuteczny sposób bez przeszkadzania im z góry przypisane role i hierarchia zarządzania w zespole