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 IT musi mówić językiem optymalizacji, planowania i kalkulacji. Zrozumienie koncepcji zarządzania zapewnia ogromną przewagę zarówno pracodawcom, jak i programistom oraz pomaga przenieść współpracę na wyższy poziom.

Uwaga dla początkujących: modele, metodologie i ogólne zamieszanie

Na początek ważne wyjaśnienie: istnieją osobne modele tworzenia oprogramowania i osobna metodologia dla tego samego rozwoju. Modele przewidują przyszłe zachowanie systemu. Aby system działał tak, jak powinien, potrzebne są metodologie. Mylenie modeli i metodologii tworzenia oprogramowania jest świętym zadaniem każdego początkującego informatyka, dlatego nie jest to uważane za rażący błąd. A jednak modele to klasyczny kaskadowy Wodospad , charakteryzujący się liniowością, jasnym wyznaczaniem celów na każdym etapie i ścisłą kontrolą terminów. Modele te to Spiral , skupiający się na wczesnej identyfikacji i łagodzeniu ryzyk projektowych. Rozwój spirali rozpoczyna się na małą skalę, rozwiązując najpierw problemy lokalne, a następnie bardziej złożone. Ostatecznym modelem jest IID , który dzieli cykl życia projektu na sekwencję iteracji, z których każda przypomina „miniprojekt”. Ogólnie rzecz biorąc, model to coś, co opisuje proces tworzenia oprogramowania . Metodologie to jednak systemy kontroli, oceny i monitorowania pracy nad powierzonymi zadaniami. Metodologie to marchewka i kij współczesnego rozwoju, które są potrzebne do kontrolowania każdego ogniwa procesu rozwoju. Dobierane są one na podstawie kierunku projektu, jego budżetu i terminu powstania produktu końcowego. Ponadto metodologie można dobierać w oparciu o temperament kierownika projektu i jego zespołu. Nawet w oparciu o filozofię firmy lub klienta. Przyjrzyjmy się najpopularniejszym metodologiom.

1. Metodologia Scrum

Scrum to zwinna metoda zarządzania projektami . Opiera się na „sprintach” – krótkich iteracjach, ściśle ograniczonych w czasie (zwykle 2-4 tygodnie). Czas trwania spotkań zostaje skrócony do minimum, ale zwiększa się ich częstotliwość. Każdy sprint składa się z listy zadań do końca iteracji, a każde z nich ma swoją „wagę”. Podczas spotkań zespół omawia, kto co zrobił, co zamierza zrobić i jakie są problemy. Scrum wykorzystuje dziennik sprintu do planowania. W takim podejściu często w zespole pojawia się Scrum master, który ustala ciągłą pracę całego zespołu, tworząc dla niej komfortowe warunki. Również w projekcie pojawia się rola Product Ownera – menadżera ds. rozwoju, osoby, która monitoruje produkt i jest głównym łącznikiem pomiędzy prośbą klienta a wynikiem zespołu.

Plusy:

• szybkie uruchomienie projektu przy możliwie najniższym budżecie;
• codzienne monitorowanie postępu prac, częste pokazy projektu;
• możliwość wprowadzania zmian w miarę postępu projektu.

Wady:

• trudności w zawieraniu umów ze względu na brak stałego budżetu;
• nie działa przy niskich kwalifikacjach zespołu, niedoszacowanych terminach prac i budżecie;
• zdolność do ciągłego wprowadzania zmian pomiędzy sprintami może powodować zamieszanie.

Dla kogo jest odpowiedni:

System ten nadaje się do projektów do dziesięciu osób - niezależnych lub w dużych firmach. Jest to wygodne, jeśli zespół ma duży nakład pracy i długi cykl życia, co zmusza go do zmian i dostosowania się do nowych warunków rynkowych.

2. Metodologia Kanbana

Najważniejszą cechą Kanbana jest wizualizacja cyklu życia projektu . Kolumny tworzone są w celu realizacji zadań, które są zgłaszane indywidualnie. Kolumny oznaczone są znacznikami typu: Do zrobienia, W toku, Przegląd kodu, W trakcie testów, Gotowe (nazwy kolumn oczywiście mogą ulec zmianie). Celem każdego członka zespołu jest zmniejszenie liczby zadań w pierwszej kolumnie. Podejście Kanban jest wizualne i pomaga zrozumieć, gdzie leży problem. Struktura Kanbana nie jest ustalona definitywnie i nieodwołalnie: w zależności od specyfiki projektu można dodać improwizowane kolumny. Na przykład niektóre zespoły stosują system, w którym muszą określić kryteria gotowości zadania przed jego wykonaniem. Następnie dodawane są dwie kolumny - określ (określ parametry) i wykonaj (zabierz się do pracy).

Plusy:

• elastyczność planowania. Zespół koncentruje się wyłącznie na bieżącej pracy, ustalany jest także priorytet zadania;
• widoczność. Kiedy wszyscy aktorzy mają dostęp do danych, łatwiej jest dostrzec problemy globalne;
• duże zaangażowanie w proces rozwoju. Wizualizacja procesów zwiększa samoorganizację i samokontrolę.

Wady:

• nie współpracuje z zespołami liczącymi więcej niż pięć osób;
• nie jest przeznaczony do planowania długoterminowego;
• nie nadaje się do pracy w zespole bez motywacji. W Kanbanie nie ma ustalonych terminów wykonania każdego zadania, a metodologia nie przewiduje kar za opóźnienie.

Dla kogo jest odpowiedni:

Kanban świetnie sprawdza się w firmach, w których zespół jest zmotywowany do rozwoju i osiągania wyników. Jak już widać, mały zespół. Być może nawet oddział lub część zespołu.

3. Metodologia 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 posiadać tymczasową, ale działającą wersję projektu. RUP polega na podzieleniu projektu na cztery fazy , w każdej z nich prowadzone są prace nad nową generacją produktu: faza inicjacji projektu, udoskonalenie, budowa i wdrożenie. Na koniec fazy umieszczany jest znacznik zakończenia etapu (kamień milowy projektu). Kamień milowy projektu można uznać za moment, w którym zespół ocenia osiągnięte rezultaty. W rezultacie metodologia zakłada, że ​​główne funkcje są udostępniane w pierwszej fazie, a dodatki dodawane są w kolejnych fazach.

Plusy:

• pozwala poradzić sobie ze zmieniającymi się zadaniami pochodzącymi zarówno od Klienta, jak i tymi powstającymi w trakcie pracy;
• zapewnia ciągłe doskonalenie produktu. Podczas iteracji projekt można dokładnie przeanalizować;
• pozwala identyfikować i eliminować ryzyka już na wczesnych etapach prac, a także skutecznie kontrolować jakość realizacji.

Wady:

• dość złożona metoda, trudna do wdrożenia w małym zespole lub firmie;
• zależność od zdolności ekspertów do wyznaczania zadań;
• wymaga nadmiernej dokumentacji wymagań.

Dla kogo jest odpowiedni:

Duże projekty z jasno określonymi wymaganiami i określonym ryzykiem, gdy produkt musi zostać wydany tak szybko, jak to możliwe. Nawet kosztem funkcjonalności, aby szybko zająć swoją niszę i dopiero wtedy dopracować niuanse.

Wiele metodologii, jeden trend

Oprócz niezaprzeczalnie popularnych Scrum i Kanban, które opierają się na zasadach elastyczności pod ogólną nazwą „Agile” , a także wytrwałego iteracyjnego RUP, firmy pracują wieloma odmianami metodyk. Niektórzy wolą ekstremalne programowanie i podejmowanie najszybszych i najprostszych decyzji, niektórzy preferują rozwój oparty na testach, a jeszcze inni preferują szybkie tworzenie aplikacji (RAD). Jednocześnie głównym i bezwarunkowym trendem jest stosowanie kilku metodologii jednocześnie . Lub nawet połączenie modeli i metodologii w unikalny system sterowania. Nowoczesne firmy dążą do eliminowania barier biurokratycznych i tworzenia atmosfery ogólnej pracy zespołowej w organizacji, bez przenoszenia odpowiedzialności pomiędzy działami i blokami. Jak wynika z raportu Scrumalliance , 70% firm IT korzysta ze Scruma. Wśród nich są tacy giganci jak Google, Amazon, Salesforce, Microsoft, Adobe. Startupy i młode projekty chętniej sięgają po Kanban, ale korzysta z niego także Toyota i np. gracze z Wargaming. Skromniejsze firmy z WNP Prom.ua, Bigl.ua, Kabanchik.ua korzystają z metodologii Scrum i Kanban jednocześnie, ale do różnych zadań. Scrum – jako narzędzie planistyczne, Kanban – do monitorowania postępu prac. Jeśli chodzi o RUP, to najczęściej stosują go zachodnie firmy zatrudniające 50-200 pracowników i osiągające przychody na poziomie 1-10 milionów dolarów. Ale jednocześnie IBM zmienił RUP, aby zbliżyć się do zasad Agile, wypuszczając metodologię OpenUP - „RUP, tylko zwinny”. Ta sama osławiona zwinność Agile rządzi teraz krajobrazem IT . To już nie tylko chwilowa moda – to wciąż innowacyjność, która sprawdza się w wielu dużych firmach. Agile jest używany w Dolinie Krzemowej i jest używany przez Facebooka i Ubera.

Konkluzja

Każdy projekt ma własną metodologię tworzenia oprogramowania, w zależności od zespołu, finansowania, harmonogramu i wymagań klienta. Nie ma uniwersalnej technologii zarządzania: nawet niezwykle popularny Agile nie jest w stanie zapewnić najlepszego podejścia do procesu rozwoju. Dlatego metodologię wybiera się ostrożnie, a czasem nawet zasadniczo. Do tego stopnia, że ​​można na jego podstawie wyciągnąć wnioski na temat samej firmy lub jej klientów. Metodologie są mieszane, uzupełniane modelami i dostosowywane do własnych potrzeb. Do tego stopnia, że ​​dają początek nowym podejściu. Choć ostatecznie sfera zarządzania pozostaje w rękach Scruma i Kanbana, z nieoczekiwanymi dodatkami modelu Waterfall czy iteracyjnego RUP.