W tym odcinku omówiam różne pojęcia związane z metodykami tworzenia oprogramowania, w szczególności koncentrując się na dopasowaniu najlepszych metodyk do danego projektu.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek siedemnasty - „Kanban, Waterfall, Agile, Scrum. Jak zrealizować projekt IT, aby nie było kwasu?”. W tym odcinku omówię różne pojęcia związane z metodykami tworzenia oprogramowania, w szczególności koncentrując się na dopasowaniu najlepszych metodyk, czyli sposobów tworzenia oprogramowania do danego projektu.

Jak pewnie pamiętacie z licznych wcześniejszych odcinków, mam przyjemność uczyć studentów informatyki na jednej z warszawskich uczelni różnych zagadnień, natomiast najczęściej te zagadnienia mają związek z programowaniem. To, z czym dość często się spotykam - i muszę przyznać, że w dawnych czasach sam myślałem podobnie - to że jak nauczę się dobrze programować, to będę w stanie zrobić każdy projekt. Oczywiście projekt może być duży i wtedy po prostu wezmę sobie kogoś do pomocy, ale dogadamy się i zrobimy projekt i będzie wszystko w jak najlepszym porządku. Gdyby jednak tak było, to w IT naprawdę nie byłoby problemów, zwłaszcza w świecie tworzenia jakichś aplikacji i systemów, bo powstawałyby one szybko, bez dodatkowych komplikacji i życie wszystkich byłoby prostsze. Problem tkwi w tym, że prawidłowa identyfikacja problemu i celu biznesowego, który dany projekt ma rozwiązać, analiza wymagań, zrozumienie klienta, i wreszcie, zaproponowanie właściwego sposobu prowadzenia projektu, dopasowanego do tych wszystkich okoliczności to nie są niestety proste zagadnienia.

W zasadzie nad każdą z wymienionych kwestii można by się pochylić na dłużej, na taki jeden odcinek, czy wręcz stworzyć cały wykład na ten temat, natomiast dziś skupimy się na tej kwestii poruszanej jako ostatnia, czy w jaki sposób prowadzić dany projekt, który charakteryzuje się pewnymi cechami. A może nawet nie tyle jak prowadzić projekt, co jak postępować w stosunku do pewnego klienta, jakiejś organizacji, do tego w jaki sposób ta organizacja funkcjonuje, by zmaksymalizować szanse na sukces.

Przytoczone w tytule cztery pojęcia zostały dobrane przeze mnie, aby ułożyć tytułowy kwas. Żartuję oczywiście. Natomiast, gdy ułożyłem w tytule te słowa, gdy je napisałem, to potem okazało się, że w sumie można z nich ułożyć taki właśnie akronim KWAS i stwierdziłem, że bardzo dobrze to pasuje do tej tematyki. Nie da się ukryć, że te pojęcia należą do najpopularniejszych, jeżeli chodzi o kwestie metodyk, czyli tych sposobów prowadzenia projektów informatycznych, choć oczywiście nie są one jedyne. Natomiast nawet w ich przypadku, w przypadku tych czterech pojęć, trzeba przede wszystkim wyróżnić te dwa kluczowe, czyli Waterfall i Agile. Są to dwa zasadnicze pojęcia, nieco przeciwstawne sobie, i na nich się głównie skupimy.

Waterfall to podejście starsze, używane od lat 70., choć w zasadzie jeszcze wcześniej pojawiały się koncepcje może nie tak sprecyzowane, dokładnie za pomocą tego pojęcia, ale o podobnym pomyśle, o podobnych założeniach. W Waterfall zakładamy, że oprogramowanie, bądź też inne procesy, bo przecież waterfallowo można realizować różne projekty, natomiast w przypadku oprogramowania działamy sekwencyjnie. Gdybyśmy mieli użyć jednego słowa, to właśnie będzie to „sekwencja”. To znaczy, najpierw realizujemy etapy wstępne, takie jak np. zbieranie wymagań, później przechodzimy do etapu projektowania oprogramowania, a dopiero potem do pracy siadają programiści, testerzy i oczywiście na koniec wdrożeniowcy, na koniec oprogramowanie jest wdrażane w środowisku produkcyjnym.

Podążanie taką metodyką, np. przy procesie budowy domu zdecydowanie ma sens. Najpierw musimy dokładnie określić, co właściwie chcemy zbudować - czy domek jednorodzinny, szeregowy, a może potrzebujemy tak naprawdę domku holenderskiego, czyli popularnego baraku. Dopiero potem projektujemy taki dom i zgodzicie się chyba, że nie ma sensu takiego domu budować, zacząć stawiać fundamenty, kolejne kondygnacje dopóki projekt nie jest skończony. Potem następuje implementacja, czyli właściwa budowa domu, a na koniec weryfikacja, czy wszystko zostało zbudowane zgodnie z życzeniem klienta, odbiór, czyli wdrożenie i oczywiście przeprowadzka. Każdy, kto mieszkał w remontowanym czy też budowanym domu, myślę, że zgodzi się ze stwierdzeniem, że zdecydowanie jest lepiej poczekać do końca budowy, czy też remontu.

Popularność Waterfalla mogła wziąć się właśnie z tego praktycznego charakteru i pozytywnych doświadczeń z innych branż. Skoro działa w budowlance - a przecież jest wiele odwołań, chociażby takich jak nazywanie ról w świecie tworzenia aplikacji, takich jak architekt czy deweloper - to zastosujmy też metodykę, która sprawdza się właśnie w tego rodzaju projektach. Natomiast po pewnym czasie okazało się, że nie zawsze jest to dobra opcja, bo w branży IT tak naprawdę mamy do czynienia z bardzo dużą zmiennością wymagań i oczekiwań, coś, czego, krótko mówiąc, w takich innych tradycyjnych branżach po prostu nie ma.

W związku z tym, wraz z rozwojem coraz to nowych rodzajów oprogramowania, też wraz z upowszechnianiem się oprogramowania, na które kiedyś było stać tylko wielkie korporacje, organizacje rządowe, później coraz mniejsze i mniejsze firmy, w latach 90. zaczęły pojawiać się trendy w rozwoju oprogramowania zmierzające w stronę podejścia bardziej elastycznego, czy też zwinnego, nazywanego po angielsku agile. Historycznie takim ważnym momentem był 2001 rok, kiedy to w Utah w jednym z hoteli zebrała się grupa programistów, którzy opracowali i ogłosili później tzw. Manifest Agile, Agile Manifesto, w którym zebrano takie podstawowe, ich zdaniem, reguły elastycznej, zwinnej pracy w projektach, co doprowadziło do takiego podsumowania i ułatwiło popularyzację tego rodzaju działań. Samo zaś słowo „agile” stało się taką zbiorczą nazwą tych elastycznych metodyk istniejących oczywiście w zgodzie, z grubsza rzecz ujmując, z tym rzeczonym manifestem.

W ramach metodyk zwinnych wyróżniamy wiele szczegółowych, konkretnych już metodyk, czyli sposobów prowadzenia projektu. I do takich najpopularniejszych należą Scrum i Kanban. Scrum to pojęcie ze świata rugby i jest to metodyka, która opiera się na dość małych, bo tak co do zasady, około dziesięcioosobowych maksymalnie zespołach, w dużej mierze samoorganizujących się. Zespoły takie mają także przypisanego product ownera, właściciela produktu, którego głównym zadaniem, w zasadzie można powiedzieć, jednym zadaniem, jest dbanie o rozwój produktu, reprezentowanie interesariuszy, priorytetyzacja, krótko mówiąc, upewnianie się, że produkt rozwija się w dobrą stronę, zgodnie z głównymi założeniami biznesowymi projektu. W projektach scrumowych pojawia się także Scrum Master, który dba o zachowanie dyscypliny w prowadzeniu takiego projektu, służy radą również innym członkom zespołu. Generalnie, zgodnie z nazwą jest takim mistrzem Scruma. Sam Scrum zakłada pracę iteracyjną, jest to niezwykle ważne, zresztą, tak naprawdę większość, jak nie wszystkie metodyki zwinne opierają się właśnie o pracę iteracyjną, czyli taką cykliczną. W Scrumie kluczowe jest regularne planowanie i wypuszczanie kolejnych wersji oprogramowania. Praca nad pojedynczą wersją nosi nazwę Sprintu i kluczowe jest to, aby te Sprinty nie były zbyt długie. Najczęściej w przypadku oprogramowania mówimy o Sprintach dwu-, czasem trzytygodniowych, czasem mogą to być Sprinty tygodniowe, mogą oczywiście być dłuższe, natomiast trochę to wtedy zaczyna przeczyć idei zwinności. Z całym Sprintem są związane różne wydarzenia, ważne są też spotkania Daily Scrums, czyli takie codzienne aktualizacje wśród członków zespołu, co się dzieje, jakie są problemy, wyzwania. Natomiast ważne jest też, aby na końcu każdego Sprintu pojawiła się retrospektywa, czyli takie podsumowanie i wyciągnięcie wniosków na przyszłość.

Kanban z kolei to metoda zorientowana na śledzenie postępu pracy w projekcie, przede wszystkim za pomocą tablicy zawierającej kolumny określające stan poszczególnych zadań. Kanban pochodzi z Japonii, podobnie jak w przypadku zwinnych podejść, duże zasługi ma firma Toyota. A w kontekście samego tworzenia oprogramowania Kanban jest często używany właśnie pod kątem stosowania tablicy, gdzie kolumny mogą reprezentować zadania np. do zrobienia, w trakcie realizacji, do weryfikacji czy też testów, zaakceptowane, do wdrożenia, wdrożone, tak naprawdę wiele innych kolumn można też dodać, chociaż najważniejsze jest nie komplikować bytu ponad miarę i, krótko mówiąc, nie przesadzać. Nie da się ukryć, że Kanban stanowi jedno z przydatniejszych narzędzi w pracy Agile. Tutaj, moim skromnym zdaniem, nazywanie Kanbana taką osobną metodą nie zawsze jest uzasadnione. Często łączy się Scruma i Kanbana, czyli z jednej strony mamy sposób pracy zgodny ze Scrumem, z drugiej strony mamy Kanbana do zarządzania zadaniami. Można spotkać się z takim określeniem mieszanym, czyli Scrumban.

Oczywiście taka metodyka też zakłada bardziej zaawansowane aspekty Kanbana, nie jest to jedynie Scrum z doklejoną tablicą, Kanban też wiąże się z kontrolą przepływu pracy, aby unikać nadmiernego np. obciążenia zbyt dużą liczbą zadań do zrobienia, czy w trakcie. Ale tak czy siak, chodzi o to, aby obie metody połączyć i uzyskać pozytywny efekt.

Oczywiście wszystkie te powyższe informacje przedstawione przeze mnie przed chwilą trzeba traktować jako taki kondensat, koncentrat w zasadzie, bo można o nich mówić dużo dłużej w dużo bardziej rozbudowany sposób, a nawet robić certyfikaty z niektórych metodyk. Warto też pamiętać, że w wielu firmach, choćby u nas w Makimo, można spotkać się z bardzo różnymi interpretacjami dopasowanymi do danej organizacji i w gruncie rzeczy nie tak często można się spotkać z czystym Scrumem czy Kanbanem, bo koniec końców trzeba pamiętać, że to metodyki są dla ludzi i dla organizacji, a nie odwrotnie.

Dobrze, przeszliśmy przez te wszystkie kwasowe, można powiedzieć, pojęcia. To teraz zastanówmy się, gdzie stosować które z tych podejść. To już w ogóle jest temat rzeka i trzeba działać na zasadzie case by case, każdego przypadku z osobna, natomiast postaram się wskazać kilka kluczowych założeń pomiędzy podejściem waterfallowym i podejściami Agile. Nie będę tu już wchodził w takie poszczególne metodyki jak Scrum, Kanban czy jeszcze inne, bo przecież to nie są jedyne, chociażby eXtreme Programming. Ale tak naprawdę najważniejsze pytanie, na które trzeba sobie odpowiedzieć to jest właśnie to, czy idziemy w Waterfall, czy idziemy w Agile. Zadajmy sobie więc kilka kluczowych pytań i spróbujmy na nie odpowiedzieć. Czy klient dobrze wie, czego chce, tudzież czego potrzebuje? I jednocześnie, czy w razie czego da się tego klienta przekonać do tego, czego faktycznie potrzebuje? Jeżeli tutaj klient jest dobrze zdecydowany, ma świadomość istniejących rozwiązań, ma świadomość swoich potrzeb i wykazuje w tym zakresie taką sporą dojrzałość, to nie da się ukryć, że te wszystkie założenia działają pozytywnie na korzyść Waterfalla. Natomiast trzeba pamiętać, że często nawet klienci, którzy na początku wydają się pewni lubią zmieniać zdanie. Dlatego też taką popularnością cieszą się właśnie metodyki zwinne.

Kolejna ważna kwestia to zmienność klienta w trakcie samych rozmów. Czy klient zmienia zdanie, czy zmienia swoje wymagania co do projektu, czy może zmienia się np. struktura zespołu, osób, które biorą udział w rozmowach, to  zwłaszcza w większych firmach, im mniej stabilny jest tu grunt, tym sensowniej jest iść w Agile, to bez dwóch zdań.

Tworząc oprogramowanie, nie zapominajmy, że to oprogramowanie nie wisi w próżni, tylko jest związane na ogół z pewnymi procesami biznesowymi. Pytanie, czy, tworząc to oprogramowanie, mamy do czynienia z digitalizacją jakiegoś dobrze istniejącego zdefiniowanego procesu, czy też wraz z oprogramowaniem będzie tworzony zupełnie nowy proces. Wszystko to, co istnieje i jest stabilne może nas faktycznie przekierować bardziej do Waterfalla. Natomiast warto też mieć świadomość, że nawet jeżeli digitalizujemy proces, który może od lat funkcjonować bez problemu, to może się okazać, że samo pojawienie się oprogramowania, które zdigitalizuje ten proces może go zmienić, bo zastosowanie rozwiązań cyfrowych może np. usprawnić pewne elementy. Tak że tutaj znowu rozwiązania zwinne, metodyki zwinne często są lepszym wyborem.

Myślę, że już po tych kilku pytaniach widać, że tak naprawdę to na różne sposoby pytamy o jedną rzecz: jak stabilna i dojrzała jest organizacja, w której chcemy tworzyć oprogramowanie, dla której chcemy tworzyć oprogramowanie, jak również jak stabilne i dojrzałe są procesy. Pokusiłbym się o takie, może nie podparte dowodami, stwierdzenie, że Agile z upływem czasu coraz bardziej dominuje w branży właśnie z uwagi na swoją elastyczność i dopasowanie do organizacji, które nie są aż tak stabilne, przewidywalne. Również, żeby to tak nie zabrzmiało przeciwko organizacjom dynamicznie zmieniającym się, często organizacje w przypadku dużego wzrostu po prostu siłą rzeczy muszą się zmieniać i wtedy to zwinne podejście w tworzeniu oprogramowania też działa lepiej, jest po prostu jedynym możliwym rozwiązaniem. Natomiast chcę tylko podkreślić, bo z taką opinią też można się spotkać, że Agile jest dobry na wszystko. Natomiast pamiętajmy, że jeżeli rozwiązujemy naprawdę duży problem biznesowy, czy też digitalizujemy, transformujemy cyfrowo jakąś dużą organizację, to podejście zwinne, które zakłada szybszy start prac, szybsze wypuszczanie jakiś pierwszych rezultatów, ale niekoniecznie poprzedza w takiej sytuacji start prac porządna analiza, niestety podejście zwinne może skutkować pewnymi problemami w przyszłości. Bo brak porządnej analizy, takiej, która by miała miejsce w Waterfallu, w takim bardzo dużym projekcie może spowodować sytuację, w której po kilku, kilkunastu Sprintach okaże się, że oprogramowanie w ogóle nie przewidziało jakichś konsekwencji długoterminowych związanych właśnie z wielkością projektu.

Natomiast w tym miejscu powtórzę: metodyki są dla nas, a nie my dla metodyk. Nikt nie broni zastosowania podejść hybrydowych, mieszanych, w których np. wykonamy sobie porządnie etap analizy, szeroko, długoterminowo, przewidując nawet konsekwencje, co może wydarzyć się w projekcie za kilka lat. I gdy upewnimy się, że nie ma żadnych większych ryzyk, możemy wtedy przejść do pracy w Scrumie czy w Kanbanie dopasowanej do organizacji.

Na tym kończymy ten odcinek. Tak jak wspominałem, można by o metodykach rozmawiać, przywoływać konkretne przykłady, więc to można traktować jako taki wstęp do kolejnych dyskusji. Ciekaw jestem waszym opinii. W czym wy pracujecie, jakie metodyki stosujecie, ewentualnie jakie metodyki znacie ze swoich organizacji. Dajcie znać w komentarzach, na różnych mediach czy też w prywatnych wiadomościach na LinkedIn. Na dziś już się z wami żegnam. Dziękuję bardzo za uwagę, kłaniam się i do usłyszenia.