Wszystko, co musisz wiedzieć o metodologiach tworzenia oprogramowania: trendy, zasady i pułapki dla początkujących

Tworzenie oprogramowania to złożony proces biznesowy. Oznacza to, że specjaliści IT muszą posługiwać się językiem optymalizacji, planowania i kalkulacji kosztów. Zrozumienie koncepcji zarządzania daje zarówno pracodawcom, jak i programistom dużą przewagę i pomaga przenieść współpracę na wyższy poziom.

Uwaga, początkujący! Modele, metodologie i ogólne zamieszanie

Na początek musimy dokonać ważnego wyjaśnienia: modele tworzenia oprogramowania i metodologie tworzenia oprogramowania są oddzielne i odrębne. Modele przewidują zachowanie systemu. Aby system działał tak, jak powinien, wymagane są metodologie. Mylenie modeli i metodologii tworzenia oprogramowania jest standardową procedurą każdego nowicjusza IT, więc nie jest to uważane za duży błąd. Przykładem modelu jest klasyczny model kaskadowy , z jego liniową progresją, jasnym określeniem celów dla każdego etapu i ścisłą kontrolą terminów. Kolejnym modelem jest model spiralny, z naciskiem na wczesne wykrywanie i ograniczanie ryzyka projektowego. Rozwój spiralny zaczyna się od małych, najpierw rozwiązując problemy lokalne, a następnie przechodząc do bardziej złożonych. Wreszcie innym modelem jest rozwój iteracyjny i przyrostowy (IID) , w którym cykl życia projektu jest podzielony na serię iteracji, z których każda przypomina „miniprojekt”. Ogólnie rzecz biorąc, model jest opisem procesu wytwarzania oprogramowania . Ale metodologie to systemy kontroli, oceny i monitorowania pracy nad przydzielonymi zadaniami. Metodologie to kij i marchewka współczesności, potrzebne do kontrolowania każdego kroku w procesie rozwoju. Są one dobierane na podstawie kierunku projektu, jego budżetu oraz terminów realizacji produktu finalnego. Co więcej, metodologie można dobierać w oparciu o temperament lidera projektu i jego zespołu. Nawet w oparciu o filozofię firmy lub klienta. Przyjrzyjmy się najpopularniejszym metodologiom.

1. Scruma

Scrum to zwinna metoda zarządzania projektami. Opiera się na „sprintach”, czyli krótkich iteracjach, ściśle ograniczonych w czasie (zwykle 2-4 tygodnie). Minimalizuje to czas trwania spotkań, ale zwiększa ich częstotliwość. Każdy sprint składa się z listy zadań do wykonania do końca iteracji, a każde z nich ma swoją „wagę”. Podczas spotkań zespół omawia, co członkowie zespołu zrobili, co planują zrobić i jakie są problemy. Scrum wykorzystuje backlog do planowania. W tym podejściu zespoły zazwyczaj mają scrum mastera. Ta osoba pomaga zespołowi pracować bez zakłóceń i tworzy komfortowe środowisko dla zespołu. W projekcie znajdzie się również osoba pełniąca rolę właściciela produktu. Ta osoba jest szefem rozwoju, monitoruje produkt i działa jako główny łącznik między tym, czego żąda klient, a tym, co wytwarza zespół.

Plusy:

• możliwość szybkiego uruchomienia projektu przy jak najniższym budżecie;
• codzienne monitorowanie postępów, częste dema projektów;
• możliwość dokonywania korekt w trakcie projektu.

Cons:

• trudności w zawieraniu umów ze względu na brak stałego budżetu;
• nie sprawdza się w niedoświadczonym zespole lub gdy terminy lub budżet są zaniżone;
• zdolność do ciągłego wprowadzania zmian między sprintami może powodować zamieszanie.

Dla kogo to jest?

Taki system jest odpowiedni dla projektów do dziesięciu osób, niezależnie od tego, czy są niezależne, czy istnieją w dużych firmach. Jest to wygodne, jeśli zespół ma dużo pracy i długi cykl życia, który zmusza go do zmian i dostosowania się do nowych warunków rynkowych.

2. Kanban

Najważniejszą cechą Kanbana jest wizualizacja cyklu życia projektu. Tworzone są kolumny do wykonywania elementów pracy. Elementy pracy są rozwiązywane indywidualnie. Kolumny oznaczone są statusami typu: Do zrobienia, W toku, Przegląd kodu, W trakcie testowania, Gotowe (oczywiście nazwy kolumn mogą się różnić). Celem każdego członka zespołu jest zmniejszenie liczby elementów pracy w pierwszej kolumnie. Podejście Kanbana jest intuicyjne i pomaga zrozumieć, gdzie leżą problemy. Struktura Kanbana nie jest definitywnie i nieodwołalnie ustalona: w zależności od specyfiki projektu można dodawać improwizowane kolumny. Na przykład niektóre zespoły używają systemu, w którym należy zdefiniować gotowe reguły dla elementu pracy przed jego wykonaniem. W tym przypadku dodawane są dwie kolumny: Specify (określ parametry) i Implementuj (bierz się do pracy).

Plusy:

• elastyczność w planowaniu. Zespół koncentruje się tylko na bieżącej pracy, ustalany jest również priorytet zadania;
• widoczność. Gdy wszyscy uczestnicy mają dostęp do danych, problemy globalne są łatwiejsze do wykrycia;
• duże zaangażowanie w proces deweloperski. Wizualizacja procesów zwiększa samoorganizację i samokontrolę.

Cons:

• nie współpracuje z zespołami składającymi się z więcej niż pięciu osób;
• nieprzeznaczony do planowania długoterminowego;
• nie nadaje się dla niezmotywowanego zespołu. Kanban nie ma terminów dla każdego elementu pracy. Metodologia nie przewiduje również kar za opóźnienia.

Dla kogo to jest?

Kanban świetnie sprawdza się w firmach, w których zespół jest zmotywowany do rozwoju i osiągania wyników. To już powinno być oczywiste — dotyczy to małego zespołu. Być może nawet oddział lub część zespołu.

3. Racjonalny Zunifikowany Proces (RUP)

Metodologia RUP wykorzystuje iteracyjny model rozwoju. Na koniec każdej iteracji (która trwa od 2 do 6 tygodni) zespół powinien osiągnąć zaplanowane cele i otrzymać działającą, choć tymczasową, wersję projektu. RUP apeluje o podzielenie projektu na cztery etapy . W każdej fazie prowadzone są prace nad następną generacją produktu: incepcja, opracowanie, konstrukcja i przejście. Na końcu fazy osiągany jest kamień milowy projektu. Moment, w którym zespół ocenia swoje wyniki, można uznać za kamień milowy projektu. Oznacza to, że metodologia zakłada, że ​​główne funkcje są udostępniane w pierwszej fazie, a dodatki są dodawane w kolejnych fazach.

Plusy:

• umożliwia radzenie sobie ze zmieniającymi się zadaniami, zarówno ze strony klienta, jak i zmianami, które pojawiają się w toku pracy;
• zapewnia ciągłe doskonalenie produktu. Podczas iteracji możesz skrupulatnie ocenić projekt;
• pozwala identyfikować i eliminować ryzyka na wczesnych etapach prac, a także skutecznie kontrolować jakość wykonania.

Cons:

• Ta metodologia jest dość złożona i trudna do wdrożenia w małym zespole lub firmie;
• zależy od umiejętności wyznaczania zadań przez ekspertów;
• wymaga nadmiernej dokumentacji wymagań.

Dla kogo to jest?

Duże projekty z jasno określonymi wymaganiami i dobrze zrozumianymi zagrożeniami, gdy produkt musi zostać wydany tak szybko, jak to możliwe. Nawet kosztem funkcjonalności, by szybko zająć swoją niszę i dopiero później dopracować.

Istnieje wiele metodologii, ale jeden trend

Oprócz niezaprzeczalnie popularnych i opartych na zwinnych zasadach Scruma i Kanbana , a także odpornej, iteracyjnej metodologii RUP, firmy stosują wiele odmian metodyk. Jedna firma może być bliżej ekstremalnego programowania i podejmowania najszybszych i najprostszych decyzji. Inny może być bliższy programowaniu opartemu na testach. Inny nadal może preferować szybkie tworzenie aplikacji (RAD). To powiedziawszy, istnieje silny, niekwestionowany trend w kierunku jednoczesnego stosowania wielu metodologii. Lub nawet łączenie modeli i metodologii w unikalny system zarządzania. Dzisiejsze firmy dążą do eliminowania barier biurokratycznych i tworzenia atmosfery jednolitej pracy zespołowej w ramach organizacji, bez przenoszenia odpowiedzialności pomiędzy działami i jednostkami organizacyjnymi. Według Scrum Alliance, 70% firm IT korzysta ze scruma. Wśród nich są tacy giganci jak Google, Amazon, Salesforce, Microsoft czy Adobe. Startupy i młode projekty są bardziej skłonne do Kanbana, ale Toyota i np. gracze z Wargaming również z niego korzystają. Scrum to narzędzie do planowania, a Kanban do monitorowania postępów. Jeśli chodzi o RUP, to najczęściej korzystają z niego zachodnie firmy zatrudniające 50-200 pracowników i o przychodach 1-10 mln USD. Jednak IBM zmodyfikował RUP, aby zbliżyć się do zasad zwinnych, zwalniając metodologię OpenUP (RUP, ale zwinny). Ta osławiona zwinna metodologia napędza obecnie świat IT . To nie jest tylko przejściowa moda — wciąż jest innowacyjna iw rzeczywistości jest wykorzystywana w wielu dużych firmach. Agile jest używany w Dolinie Krzemowej. Korzystają z niego Facebook i Uber.

Najważniejsze

Każdy projekt ma swoją własną metodologię tworzenia oprogramowania, która zależy od zespołu, finansowania, terminów i wymagań klienta. Nie ma uniwersalnej techniki zarządzania: nawet szalenie popularna metodologia zwinna nie może zapewnić najlepszego podejścia do procesu rozwoju. W rezultacie metodologie są wybierane ostrożnie, czasem nawet z zasady. Do tego stopnia, że ​​możemy wyciągnąć wnioski na temat samej firmy lub jej klientów, patrząc na jej metodologię. Metodologie są mieszane, uzupełniane modelami i dostosowywane. Tak bardzo, że dają początek nowym podejść. To powiedziawszy, sfera zarządzania ostatecznie pozostaje w rękach scruma i Kanbana, z nieoczekiwanymi elementami modelu kaskadowego lub iteracyjnej metodologii RUP.