Co to jest metodologia zwinna? Wyjaśnienie nowoczesnego rozwoju oprogramowania

Wydaje się, że obecnie każda organizacja technologiczna praktykuje zwinną metodologię tworzenia oprogramowania lub jej wersję. A przynajmniej wierzą, że tak. Niezależnie od tego, czy dopiero zaczynasz tworzyć zwinne aplikacje, czy też nauczyłeś się tworzenia oprogramowania dziesiątki lat temu, korzystając z metodologii tworzenia oprogramowania kaskadowego, dziś co najmniej wpływ na Twoją pracę ma ta metodologia.

Ale czym jest metodologia zwinna i jak powinna być praktykowana w tworzeniu oprogramowania? Czym w praktyce różni się programowanie zwinne od kaskadowego? Jaki jest zwinny cykl życia oprogramowania lub zwinny SDLC? A czym jest agile Scrum w porównaniu z Kanbanem i innymi modelami zwinnymi? 

Agile został oficjalnie uruchomiony w 2001 r., Kiedy 17 technologów opracowało Manifest Agile. Napisali cztery główne zasady zwinnego zarządzania projektami, których celem jest opracowanie lepszego oprogramowania:

  • 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

Przed agile: era metodologii kaskadowej

Stare ręce, takie jak ja, pamiętają czasy, kiedy metodologia kaskadowa była złotym standardem w tworzeniu oprogramowania. Proces tworzenia oprogramowania wymagał mnóstwa dokumentacji przed rozpoczęciem kodowania. Ktoś, zwykle analityk biznesowy, najpierw napisał dokument wymagań biznesowych, który zawierał wszystko, czego firma potrzebowała w aplikacji. Te dokumenty wymagań biznesowych były długie i szczegółowo opisywały wszystko: ogólną strategię, kompleksowe specyfikacje funkcjonalne i projekty wizualnego interfejsu użytkownika.

Technologowie wzięli dokument wymagań biznesowych i opracowali własny dokument wymagań technicznych. W tym dokumencie zdefiniowano architekturę aplikacji, struktury danych, zorientowane obiektowo projekty funkcjonalne, interfejsy użytkownika i inne wymagania niefunkcjonalne.

Ten kaskadowy proces tworzenia oprogramowania w końcu rozpoczął kodowanie, potem integrację i wreszcie testowanie, zanim aplikacja została uznana za gotową do produkcji. Cały proces może zająć kilka lat.

Od nas, programistów, oczekiwano, że będziemy znać „specyfikację”, jak nazywano całą dokumentację, tak samo dobrze jak autorzy dokumentów, i często byliśmy karceni, jeśli zapomnieliśmy poprawnie zaimplementować kluczowy szczegół opisany na stronie 77 w 200- dokument strony.

W tamtych czasach samo tworzenie oprogramowania również nie było łatwe. Wiele narzędzi programistycznych wymagało specjalistycznego szkolenia i nie było w pobliżu istniejących obecnie komponentów oprogramowania typu open source lub komercyjnego, interfejsów API i usług internetowych. Musieliśmy opracować kwestie niskiego poziomu, takie jak otwieranie połączeń z bazami danych i wielowątkowość przetwarzania danych.

Nawet w przypadku podstawowych aplikacji zespoły były duże, a narzędzia komunikacyjne ograniczone. Nasze specyfikacje techniczne były tym, co nas dostosowało i wykorzystaliśmy je jak Biblia. Jeśli wymaganie uległo zmianie, poddaliśmy liderów biznesu długi proces przeglądu i podpisania umowy, ponieważ informowanie o zmianach w zespole i naprawianie kodu było kosztowne.

Ponieważ oprogramowanie zostało opracowane w oparciu o architekturę techniczną, najpierw opracowano artefakty niższego poziomu, a później artefakty zależne. Zadania były przydzielane według umiejętności i często inżynierowie baz danych najpierw konstruowali tabele i inne artefakty bazy danych, a następnie programiści aplikacji kodujący funkcjonalność i logikę biznesową, a na końcu nakładali na siebie interfejs użytkownika. Minęły miesiące, zanim ktokolwiek zobaczył, że aplikacja działa, a do tego czasu interesariusze byli coraz bardziej zdenerwowani i często mądrzejsi w kwestii tego, czego naprawdę chcą. Nic dziwnego, że wprowadzanie zmian było tak drogie!

Nie wszystko, co przedstawiłeś użytkownikom, działało zgodnie z oczekiwaniami. Czasami użytkownicy w ogóle nie korzystali z funkcji. Innym razem funkcja odniosła duży sukces, ale wymagała przeprojektowania w celu zapewnienia niezbędnej skalowalności i wydajności. W świecie wodospadów nauczyłeś się tych rzeczy dopiero po wdrożeniu oprogramowania, po długim cyklu rozwoju.

Powiązane wideo: Jak naprawdę działa metodologia zwinna

Wydaje się, że wszyscy mówią o zwinnym tworzeniu oprogramowania, ale wiele organizacji nie ma dokładnego zrozumienia, jak działa ten proces. Obejrzyj ten pięciominutowy film, aby przyspieszyć.

Punkt zwrotny w kierunku zwinnego tworzenia oprogramowania

Wynaleziona w 1970 roku metodologia kaskadowa była rewolucyjna, ponieważ wprowadziła dyscyplinę w tworzenie oprogramowania, aby zapewnić jasną specyfikację do naśladowania. Opierał się on na metodzie produkcji wodospadu wywodzącej się z innowacji linii montażowej Henry'ego Forda z 1913 r., Która zapewniała pewność na każdym etapie procesu produkcyjnego, gwarantując, że produkt końcowy pasuje do specyfikacji w pierwszej kolejności.

Kiedy metodologia kaskadowa pojawiła się w świecie oprogramowania, systemy obliczeniowe i ich aplikacje były zwykle złożone i monolityczne, a ich dostarczenie wymagało dyscypliny i jasnych wyników. Również wymagania zmieniały się powoli w porównaniu z obecnymi, więc wysiłki na dużą skalę były mniej problematyczne. W rzeczywistości systemy były budowane przy założeniu, że nie ulegną zmianie, ale będą wiecznymi pancernikami. Wieloletnie ramy czasowe były powszechne nie tylko w tworzeniu oprogramowania, ale także w produkcji i innych działaniach przedsiębiorstw. Jednak sztywność wodospadu stała się piętą achillesową w erze internetu, w której wymagana była szybkość i elastyczność.

Metodologia tworzenia oprogramowania zaczęła się zmieniać, gdy programiści zaczęli pracować nad aplikacjami internetowymi. Wiele wczesnych prac wykonano w startupach, w których zespoły były mniejsze, były kolokowane i często nie miały tradycyjnego zaplecza informatycznego. Istniała presja finansowa i konkurencyjna, aby szybciej wprowadzać strony internetowe, aplikacje i nowe funkcje na rynek. Narzędzia i platformy programistyczne szybko się zmieniły w odpowiedzi.

To sprawiło, że wielu z nas pracujących w startupach zakwestionowało metodologię kaskadową i szukało sposobów na zwiększenie wydajności. Nie mogliśmy sobie pozwolić na wykonanie całej szczegółowej dokumentacji z góry i potrzebowaliśmy bardziej iteracyjnego i opartego na współpracy procesu. Nadal debatowaliśmy nad zmianami w wymaganiach, ale byliśmy bardziej otwarci na eksperymenty i dostosowywanie się do potrzeb użytkowników końcowych. Nasze organizacje były mniej ustrukturyzowane, a nasze aplikacje były mniej złożone niż starsze systemy korporacyjne, więc byliśmy znacznie bardziej otwarci na tworzenie niż kupowanie aplikacji. Co ważniejsze, staraliśmy się rozwijać firmy, więc kiedy nasi użytkownicy powiedzieli nam, że coś nie działa, częściej niż nie decydowaliśmy się ich słuchać.

Nasze umiejętności i zdolność do innowacji stały się strategicznie ważne. Mógłbyś zebrać wszystkie potrzebne pieniądze, ale nie mógłbyś przyciągnąć utalentowanych programistów zdolnych do pracy z szybko zmieniającymi się technologiami internetowymi, gdybyś miał traktować ich jako podległych programistów niewolniczo przestrzegających „specyfikacji”. Odrzuciliśmy kierowników projektów, którzy przychodzili z kompleksowymi harmonogramami opisującymi, co powinniśmy opracować, kiedy powinny zostać wysłane aplikacje, a czasem nawet jak zorganizować kod. Byliśmy okropni, gdy dotarliśmy do trzymiesięcznych i sześciomiesięcznych harmonogramów, które kierownicy projektów wodospadu sporządzali i nieustannie aktualizowali.

Zamiast tego zaczęliśmy im mówić, w jaki sposób należy projektować aplikacje internetowe, i dostarczyliśmy wyniki zgodnie z harmonogramem, który opracowaliśmy iteracyjnie. Okazuje się, że nie byliśmy tacy źli w dostarczaniu tego, co powiedzieliśmy, robiąc to w małych, tygodniowych do czterech tygodniowych odstępach.

W 2001 roku grupa doświadczonych programistów zebrała się i zdała sobie sprawę, że wspólnie praktykują tworzenie oprogramowania inaczej niż klasyczna metodologia kaskadowa. I nie wszyscy byli w startupach. Grupa ta, w skład której wchodzili luminarze technologii Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber i Jeff Sutherland, opracowała Manifest Agile, który udokumentował ich wspólne przekonania o tym, jak powinien działać nowoczesny proces tworzenia oprogramowania. Podkreślili współpracę nad dokumentacją, samoorganizację zamiast sztywnych praktyk zarządzania oraz zdolność do radzenia sobie z ciągłymi zmianami, zamiast ograniczać się do sztywnego procesu rozwoju kaskadowego.

Z tych zasad narodziła się zwinna metodologia tworzenia oprogramowania.

Role w metodyce zwinnej

Zwinny proces tworzenia oprogramowania zawsze rozpoczyna się od zdefiniowania użytkowników i udokumentowania wizji zakresu problemów, możliwości i wartości, którymi należy się zająć. Właściciel produktu uchwycił tę wizję i współpracuje z multidyscyplinarnym zespołem (lub zespołami), aby zrealizować tę wizję. Oto role w tym procesie.

Użytkownik

Zwinne procesy zawsze rozpoczynają się z myślą o użytkowniku lub kliencie. Obecnie często definiujemy je za pomocą person użytkownika, aby zilustrować różne role w przepływie pracy, który obsługuje oprogramowanie, lub różne typy potrzeb i zachowań klientów.

Właściciel Produktu

Sam proces zwinnego rozwoju zaczyna się od kogoś, kto musi być głosem klienta, w tym wszystkich wewnętrznych interesariuszy. Ta osoba destyluje wszystkie spostrzeżenia, pomysły i opinie, aby stworzyć wizję produktu. Te wizje produktów są często krótkie i proste, ale mimo to przedstawiają obraz tego, kim jest klient, jakie wartości są adresowane i strategię, jak się do nich odnosić. Mogę sobie wyobrazić, że pierwotna wizja Google wyglądała mniej więcej tak: „Ułatwmy każdemu, kto ma dostęp do internetu, znajdowanie odpowiednich witryn i stron internetowych za pomocą prostego interfejsu opartego na słowach kluczowych i algorytmu, który plasuje renomowane źródła wyżej w wynikach wyszukiwania”.

Nazywamy tę osobę właścicielem produktu . Jego lub jej obowiązkiem jest zdefiniowanie tej wizji, a następnie praca z zespołem programistów nad jej urzeczywistnieniem.

Aby współpracować z zespołem programistów, właściciel produktu dzieli wizję produktu na serię historii użytkowników, które bardziej szczegółowo opisują, kim jest docelowy użytkownik, jaki problem jest dla niego rozwiązywany, dlaczego rozwiązanie jest dla niego ważne oraz jakie ograniczenia i kryteria akceptacji definiują rozwiązanie. Właściciel produktu nadaje priorytet tym historiom użytkowników, a następnie przegląda je zespół, aby upewnić się, że wspólnie rozumieją, o co są proszeni.

Zespół programistów

W agile, obowiązki zespołu programistów i jego członków różnią się od tych, które występują w przypadku tradycyjnego tworzenia oprogramowania.

Zespoły są multidyscyplinarne i składają się z różnorodnej grupy osób posiadających umiejętności potrzebne do wykonania pracy. Ponieważ nacisk kładziony jest na dostarczanie działającego oprogramowania, zespół musi tworzyć kompleksowe, działające aplikacje. Zatem baza danych, logika biznesowa i interfejs użytkownika części aplikacji są opracowywane, a następnie demonstrowane, a nie cała aplikacja. Aby to zrobić, członkowie zespołu muszą współpracować. Spotykają się często, aby upewnić się, że wszyscy są zgodni co do tego, co tworzą, kto co robi i jak dokładnie jest rozwijane oprogramowanie.

Oprócz programistów, zespoły programistyczne mogą obejmować inżynierów zapewniania jakości (QA), innych inżynierów (takich jak bazy danych i systemy zaplecza), projektantów i analityków, w zależności od typu projektu oprogramowania.

Scrum, Kanban i inne zwinne frameworki

Wiele zwinnych frameworków, które zapewniają szczegółowe informacje na temat procesów programistycznych i zwinnych praktyk programistycznych, dostosowanych do cyklu życia oprogramowania.

Najpopularniejszym frameworkiem agile jest scrum . Koncentruje się na kadencji dostawy zwanej sprintem i strukturach spotkań, które obejmują:

  • Planowanie - gdzie identyfikowane są priorytety sprintu
  • Zaangażowanie - gdzie zespół przegląda listę lub zaległości w historiach użytkowników i decyduje, ile pracy można wykonać w czasie trwania sprintu 
  • Codzienne spotkania standup - aby zespoły mogły przekazywać aktualne informacje na temat ich statusu rozwoju i strategii)

Sprinty kończą się spotkaniem demonstracyjnym, na którym prezentowana jest funkcjonalność właścicielowi produktu, po którym następuje spotkanie retrospektywne, podczas którego zespół omawia, co poszło dobrze, a co wymaga poprawy w ich procesie.

Wiele organizacji zatrudnia scrum masterów lub coachów do pomocy zespołom w zarządzaniu procesem scrum.

Chociaż dominuje scrum, istnieją inne zwinne ramy:

  • Kanban działa jako proces wprowadzania i rozpowszechniania, w którym zespół pobiera historie użytkowników z tablicy przyjęć i kieruje je przez etapowy proces rozwoju, aż do ich ukończenia.
  • Niektóre organizacje przyjmują hybrydowe podejście zwinne i kaskadowe, wykorzystując procesy zwinne do nowych aplikacji i kaskadowe do starszych.
  • Istnieje również kilka ram umożliwiających organizacjom skalowanie praktyki do wielu zespołów.

Podczas gdy zwinne struktury definiują proces i współpracę, zwinne praktyki programistyczne są specyficzne dla zadań związanych z tworzeniem oprogramowania wykonywanych w zgodzie ze zwinną strukturą.

Na przykład:

  • Niektóre zespoły stosują programowanie w parach, w którym dwóch programistów koduje razem, aby generować kod wyższej jakości i umożliwić starszym programistom opiekę nad młodszymi.
  • Bardziej zaawansowane zespoły stosują programowanie i automatyzację opartą na testach, aby zapewnić, że podstawowa funkcjonalność zapewnia oczekiwane rezultaty.
  • Wiele zespołów przyjmuje również standardy techniczne, aby interpretacja historii użytkownika przez programistę nie prowadziła tylko do pożądanej funkcjonalności, ale także spełniała wymogi bezpieczeństwa, jakości kodu, konwencji nazewnictwa i innych standardów technicznych.

Dlaczego zwinna metodologia jest lepsza