Seria „Jak powstaje oprogramowanie?” 2/3
Agile, Waterfall, Scrum… Czym różnią się metodyki wytwarzania oprogramowania?
Przeglądając oferty pracy w IT, w wielu z nich można natknąć się na pojęcia takie jak „scrum”, „agile”, „waterfall”. Jeśli te słowa brzmią dla Ciebie tajemniczo i zastanawiasz się, o co chodzi, ten artykuł jest dla Ciebie.
W obiegowej opinii krążącej wśród osób zainteresowanych przebranżowieniem się do IT największą trudność stanowi zdobycie wiedzy technicznej, takiej jak umiejętność programowania, praca z bazami danych czy też znajomość działania oprogramowania od podszewki. Warto jednak pamiętać, że równie istotne dla rekruterów są umiejętności miękkie oraz wiedza dotycząca organizacji pracy w zespołach programistycznych. Niezależnie od tego, czy chcesz zostać testerem, programistą, project managerem, analitykiem biznesowym lub DevOpsem – potrzebujesz wiedzy związanej z metodykami wytwarzania oprogramowania. Co kryje się pod tym pojęciem i dlaczego jest to tak ważne?
Oprogramowanie jest produktem, który nie powstaje w próżni. Jest on albo produkowany i wytwarzany pod konkretne, istniejące zamówienie klienta, albo z myślą o potrzebach użytkowników, którzy pewnego dnia zechcą go kupić. Wymaga pracy z deadline’ami i konieczności dostarczenia produktu lub odpowiedniej jego części w określonym terminie. Na dodatek wytworzenie owego produktu jest kosztownym procesem, który wymaga sprawnej współpracy całego zespołu (lub kilku zespołów). Cykl wytwarzania oprogramowania składa się z różnych faz (więcej o samym cyklu wytwarzania oprogramowania dowiesz się z poprzedniego artykułu). Angażuje też kilka różnych specjalizacji: analiza biznesowa, projektowanie interfejsów, programowanie, testowanie… Biorąc to wszystko pod uwagę nie powinniśmy być zdziwieni, że wytwarzanie oprogramowania odbywa się według zasad ujętych w tak zwane metodyki, opracowane na bazie doświadczeń z wielu projektów i dostarczające gotowych wzorców postępowania.
Choć istnieje wiele metodyk wytwarzania oprogramowania, zwykle wyróżnia się dwa podstawowe typy: metodyki tradycyjne (spośród których najbardziej znaną jest kaskadowy model wytwarzania oprogramowania, z ang. Waterfall) oraz zwinne (ang. agile, spośród których obecnie jedną z najpopularniejszych jest Scrum).
Model kaskadowy najłatwiej skojarzyć z wodospadem układającym się w kaskady, który stał się inspiracją dla anglojęzycznej nazwy. Poszczególne fazy wytwarzania oprogramowania następują jedna po drugiej, a kolejna faza rozpoczyna się dopiero po zakończeniu poprzedniej. W ten sposób mamy do czynienia ze stosunkowo długimi fazami, obejmującymi odpowiednio całościowe planowanie, całościowy development, całościowe testowanie… Podobnie jak w przypadku wodospadu, po spłynięciu do niższej kaskady nie ma już powrotu wyżej – poprzednia faza jest sfinalizowana. Gotowy produkt w postaci działającej aplikacji jest dostarczany i przekazywany klientowi jako kompletna całość.
Wytwarzanie oprogramowania w powyższy sposób niesie za sobą pewne niedogodności. Przygotowanie produktu zajmuje stosunkowo długi czas, po upływie którego może się okazać, że system przestał spełniać dynamicznie zmieniające się potrzeby rynkowe i że już wymaga przerobienia, pomimo że jeszcze nawet nie oddano go do użytku! Co więcej, kompletne zaprojektowanie aplikacji zawczasu jest trudne, ponieważ dopiero podczas programowania, testowania i kontaktu z „żywym” oprogramowaniem możliwe jest dostrzeżenie pewnych ograniczeń technicznych, potrzeb biznesowych i potencjalnych ulepszeń. Powyższe argumenty były jednym z bodźców do powstania różnych modyfikacji modelu kaskadowego – przykładowo V-modelu, w którym poszczególne fazy zazębiają się – oraz, ostatecznie, tak zwanych modeli zwinnych, w których wytwarzanie oprogramowania zachodzi iteracyjnie.
Źródłem powstania metodyk zwinnych stał się opublikowany w 2001 roku zwięzły Manifest Agile, brzmiący następująco:
„Odkrywamy nowe metody programowania dzięki praktyce w programowaniu
i wspieraniu w nim innych.
W wyniku naszej pracy zaczęliśmy bardziej cenić:
Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
Oznacza to, że elementy wypisane po prawej są wartościowe,
ale większą wartość mają dla nas te, które wypisano po lewej.”
Manifest określa ogólne wskazówki postępowania, lecz jak widać nie zawiera sztywnych wytycznych – najważniejszą zasadą jest wszak zwinność. Dziś sam Agile to tak naprawdę zbiór różnych modeli i sposobów pracy (frameworków), takich jak Scrum i Kanban. Precyzują one pewne zasady postępowania, ale w stosunkowo lakoniczny sposób – założenia Scruma mieszczą się zaledwie na kilku stronach (spisane w tzw. Scrum Guide) – podążając tym samym za Manifestem Agile i zakładając dużą elastyczność.
Jak właściwie wygląda wspomniana zwinność w praktyce? W przeciwieństwie do tradycyjnych modeli wytwarzania oprogramowania z ich długimi, wyspecjalizowanymi fazami, metodyki zwinne charakteryzują się zwykle krótszymi, kilkutygodniowymi blokami pracy, tzw. iteracjami, które konsolidują wszystkie specjalizacje (projektowanie, programowanie i testowanie odbywają się równolegle) i tym samym angażują od razu cały zespół. Praca podzielona jest na niewielkie zadania, możliwe do wykonania w krótkim czasie. Iteracje są zakończone powstaniem fragmentów aplikacji, gotowymi do przekazania klientom znacznie wcześniej niż ma to miejsce w modelach tradycyjnych. Po każdej iteracji zespół dyskutuje nad możliwymi usprawnieniami i na bieżąco stara się ulepszać organizację pracy. Oprogramowanie może być wypuszczone na rynek o wiele wcześniej niż w tradycyjnym podejściu – jako MVP (ang. Minimum Viable Product), czyli wersja niezawierająca jeszcze wszystkich docelowych funkcji, lecz nadająca się już do użytku. Kolejne funkcje są następnie sukcesywnie dodawane do systemu. Takie podejście umożliwia wczesne zbieranie opinii użytkowników, zwinne reagowanie na potrzeby i właściwie dostosowywanie oprogramowania. Ponadto w metodykach zwinnych działające oprogramowanie jest nadrzędnym celem, ważniejszym niż procedury i sztywny formalizm, który w tradycyjnych metodykach powoduje niekiedy tonięcie w odmętach dokumentacji, często niepełniącej żadnej praktycznej roli. Z tego powodu w projektach zwinnych zwykle ogranicza się ilość dokumentacji tak, żeby poświęcać czas tylko na sporządzanie dokumentów faktycznie potrzebnych do pracy i spełniających konkretną rolę.
Jest to druga część artykułu z serii „Jak powstaje oprogramowanie?” – część 1/3 TUTAJ
Czy metodyki zwinne całkowicie wyparły Waterfall i inne bardziej tradycyjne podejścia? Skoro są popularne, dlaczego często słyszy się ich krytykę? Wytwarzanie oprogramowania nie jest łatwym do zorganizowania procesem, a każdy system stawia przed zespołem inne wyzwania. W niektórych sytuacjach tradycyjne, bardziej sformalizowane i podzielone na dłuższe fazy modele sprawdzają się lepiej. Jak często zdarza się w IT, „to zależy” i najważniejsze jest dobranie odpowiedniego podejścia do odpowiedniej sytuacji. Ponadto Agile nie eliminuje wszystkich problemów i trudności. Zwinność może ułatwić adaptację do zmieniających się warunków i opracowanie przez zespół deweloperski najlepszego możliwego sposobu pracy, ale nie ma sytuacji ani projektów idealnych. Brak jednego elementu może łatwo zachwiać równowagę – przykładowo nieobecność w zespole osoby o roli Scrum Mastera (rola w zespole scrumowym odpowiadająca za jego wsparcie, moderowanie spotkań i pomoc w usuwaniu problemów) może prowadzić do chaosu, braku spójnej wizji dotyczącej organizacji pracy i – w następstwie – do małej efektywności. Ponadto zalety zwinności mogą przekształcić się w pewnych sytuacjach w wady. Niewielka ilość dokumentacji może stać się przekleństwem, jeśli przestaje ona być wystarczająca do zrozumienia wymagań biznesowych. Elastyczność może stać się frustrująca kiedy wizja wytwarzanego produktu zmienia się zbyt często i utrudnia skupienie się na konkretnym kierunku i na tworzeniu oprogramowania, które byłoby spójną całością. Każdy projekt jest inny i w każdej sytuacji należy przemyśleć wybór odpowiedniej metodyki oraz dostosowanie jej do potrzeb.