Metodyki tworzenia oprogramowania

Cześć. Podczas dwóch ostatnich rozmów kwalifikacyjnych zapytano mnie o metodologie. To nie jest najważniejsze ani najtrudniejsze pytanie, ale miło będzie mieć ściągawkę na odpowiedź. W tym artykule postaram się dać wyobrażenie o tym, czym jest metodologia rozwoju i porównać te, z którymi osobiście się spotkałem lub o które mnie pytano. Metodologia wytwarzania oprogramowania to proces opisujący, w jaki sposób będzie rozwijany konkretny produkt, czyli jeden ze sposobów organizacji rozwoju zespołu. Istnieje wiele różnych modeli takiego procesu, z których każdy opisuje własne podejście i nie można powiedzieć, że wśród nich jest taki, który należy zastosować w każdym projekcie, wszystko jest czysto sytuacyjne. Proponuję rozważyć bardziej szczegółowo trzy z nich.

Wodospad

Wodospad (kaskada, wodospad) jest jedną z najstarszych metodologii i zakłada ścisłą sekwencyjną realizację wszystkich etapów, z których każdy musi zostać ukończony przed rozpoczęciem następnego. Oznacza to, że przejście do następnego etapu oznacza całkowite zakończenie prac nad poprzednim. Na zdjęciu widać, że najpierw analizujemy zadanie (dokumentujemy zadania, omawiamy trudności), następnie następuje projektowanie (na tym etapie powstaje struktura projektu), następnie kodowanie i testowanie. Za kolejne etapy nie ma zwrotów. Zaleca się stosowanie takiego systemu w małych projektach, gdzie wymagania są znane z góry i istnieje małe prawdopodobieństwo, że ulegną zmianie. Zalety:

• Kompletna i spójna dokumentacja na każdym etapie;
• Łatwość użycia;
• Stabilne wymagania.
• Budżet i terminy są z góry ustalone

Wady:

• Duża ilość dokumentacji;
• Niezbyt elastyczny system;
• Klient nie może zobaczyć wersji demonstracyjnej produktu;
• Nie ma możliwości cofnięcia się o krok.

Scrum

Scrum to system wytwarzania oprogramowania polegający na podziale całego procesu na iteracje, gdzie na końcu każdej z nich zespół jest gotowy dostarczyć wersję demonstracyjną produktu. Na zdjęciu widać, że zespół przechodzi przez wszystkie etapy rozwoju równolegle, co pozwala nam mieć ukończoną część projektu na koniec każdej iteracji. Spróbuję krótko i prostymi słowami wyjaśnić istotę metodologii, ale terminów jest tu sporo. Myślę, że najważniejsze jest zrozumienie istoty, a terminy zostaną zapamiętane z doświadczeniem. Cały rozwój jest podzielony na sprinty (często 2-3 tygodnie). Istnieje backlog (lista zadań) na cały okres rozwoju i dla każdego sprintu z osobna. Każde zadanie ma swój własny punkt fabularny (stopień trudności). Każdy uczestnik procesu ma swoją rolę:

• Zespół Scrumowy to zespół pracujący nad projektem (programiści, testerzy, projektanci).
• Scrum Master to osoba, która czuwa nad przestrzeganiem zasad Scruma.
• Właściciel produktu – klient.

Ponieważ w tym systemie nacisk położony jest na komunikację, istnieje duża liczba rajdów:

• Stand-up to krótkie spotkanie, odbywające się codziennie, biorą w nim udział wszyscy członkowie zespołu, a każdy uczestnik odpowiada na 3 pytania: co zrobiłeś? Co to zrobi? A jakie są blokery?
• Planowanie – odbywa się na początku sprintu i podczas tego spotkania ustalane jest, jakie zadania należy wykonać w kolejnym sprincie.
• Retrospektywa odbywa się na zakończenie sprintu i jej istotą jest sprawdzenie, co zostało zrobione dobrze, a co można poprawić.

Zalety:

• Klient może obserwować wynik w procesie rozwoju.
• Codzienna kontrola nad procesem rozwoju.
• Możliwość wprowadzania zmian w trakcie rozwoju.
• Dobra komunikacja ze wszystkimi członkami zespołu.
• Mała ilość dokumentacji.

Wady:

• Trudne do oszacowania nakłady pracy i koszty niezbędne do opracowania
• Trudno jest określić największe wąskie gardła przed rozpoczęciem prac rozwojowych.
• Konieczność zaangażowania wszystkich w rozwój pozostałych członków zespołu.

Kanban

Kanban to system zbudowany w oparciu o wizualizację procesu realizacji zadań zespołowych. Główną ideą tego systemu jest zmniejszenie liczby aktualnie realizowanych zadań (w kolumnie „w toku”).W Scrumie zespół skupia się na pomyślnym ukończeniu sprintów, w Kanbanie na pierwszym miejscu są zadania. Dobry dla projektów, które są na etapie wsparcia, gdzie główna funkcjonalność została już opracowana i pozostały minimalne ulepszenia i poprawki błędów. W Kanbanie zadania składane są indywidualnie. Zadanie, niezależnie od innych zadań, przechodzi przez wszystkie etapy na tablicy i zaraz po wykonaniu może zostać pokazane klientowi. Tablica Kanban składa się z kolumn, z których każda reprezentuje odrębny proces rozwoju. Niektóre kolumny (na przykład w toku) nakładają ograniczenia na liczbę zadań, które mogą się w nich znajdować. Pomaga to łatwo i szybko znaleźć problematyczne obszary w podziale zadań. Na zdjęciu przykład takiej prostej planszy. Liczba kolumn i nazwy mogą się różnić, ale wymienię najczęstsze:

• Do zrobienia - lista zadań do wykonania
• W toku – zadania, nad którymi aktualnie pracujemy
• Przegląd kodu – zadania, które zostały wykonane i przesłane do przeglądu
• W testowaniu – zadania gotowe do testów
• Gotowe – wykonane zadania.

Zalety:

• Łatwość użycia.
• Wizualizacja (pomaga w znalezieniu wąskich gardeł, ułatwia zrozumienie)
• Wysokie zaangażowanie zespołu w sam proces.
• Duża elastyczność w rozwoju.

Wady:

• Niestabilna lista zadań.
• Trudne do wykorzystania w projektach długoterminowych.
• Żadnych sztywnych terminów.

Podsumowując na temat metodologii tworzenia oprogramowania

Moim zdaniem osoby piastujące stanowiska kierownicze lub aspirujące do takiego stanowiska muszą posiadać dogłębną wiedzę na temat metodologii tworzenia oprogramowania, choć wskazane jest, aby każdy zrozumiał przynajmniej podstawy. Jest to integralna część procesu rozwoju i ma zastosowanie nie tylko w branży IT. Dziękuję za poświęcenie czasu na przeczytanie mojego artykułu, mam nadzieję, że okazał się pomocny. Starałem się opisać jedynie najważniejsze punkty tak jasno i krótko, jak to możliwe, dlatego artykuł nie jest wyczerpujący. Chętnie poznam Twoją opinię na ten temat i odpowiem na Twoje pytania. Wszystkiego najlepszego!