Scrum - lepsza jakość tworzenia oprogramowania

Po wdrożeniu scrum w naszej agencji drupalowej zaobserwowaliśmy rewelacyjne efekty, jeśli chodzi o jakość projektów. Naszym zdaniem scrum nie tylko wspomaga utrzymanie jakości, a wręcz je wymusza. Jak to robi? Kładzie nacisk na jak najwcześniejsze testowanie. Konieczne staje się pisanie dobrego kodu, który da się rozwijać. Wspiera testy automatyczne i automatyzacje procesu tworzenia kodu. Redukuje zbędne koszty i zwiększa elastyczność biznesową. Nie wierzysz? Koniecznie przeczytaj ten tekst i powiedz nam, co o tym myślisz!

Jakość

Jeśli zapytalibyśmy dużą grupę ludzi, z czym kojarzy im się jakość projektu, uzyskalibyśmy z pewnością wiele różnych odpowiedzi. Mnie osobiście najbardziej podoba się definicja Josepha Phillipsa, który uważa, że “jakość jest potencjałem projektu w zakresie możliwości spełniania wymagań oczekiwanych i zdefiniowanych przez klienta projektu. Jakość jest dobrem, wartością i źródłem zysków czerpanych z odpowiednio przeprowadzonej realizacji projektu”. 

Jest to stwierdzenie może dość ogólne, ale sprowadza się do prostej rzeczy - dobre jakościowo oprogramowanie powinno robić dokładnie to, czego od niego oczekiwaliśmy jako klient i końcowy użytkownik. Możemy sobie te definicje rozszerzyć, mówiąc też, że dobre jakościowo oprogramowanie nie powinno robić tego, czego od niego nie oczekiwaliśmy. 

Czym jest scrum?

Scrum to iteracyjno-przyrostwy sposób prowadzenia projektu, realizowany na podstawie zasad zawartych w manifeście Agile, a więc:

• Ludzie i interakcje ponad procesy i narzędzia.
• Działające oprogramowanie ponad szczegółową dokumentacją.
• Współpraca z klientem ponad negocjowanie umów.
• Reagowanie na zmiany ponad realizację założonego planu.

Jeśli chcielibyście się dokładniej zaznajomić z tematem scruma, polecam przeczytać Scrum Guide lub uważnie śledzić naszego bloga, bo zapewne w najbliższej przyszłości pojawi się tutaj jeszcze kilka wpisów na ten temat.

Jak scrum pomaga utrzymać jakość?

W scrumie, podobnie jak w innych metodykach zwinnych, kładzie się dość duży nacisk na jakość, czego świadomi są nasi programiści. Jednak czy naprawdę pomaga on w podnoszeniu jakości? Mam nadzieję, że poniższe argumentu przekonają Cię, drogi czytelniku, że tak jest.

Częste wydania wymagają dobrego kodu

Scrum na końcu każdego okresu musimy mieć wersję, którą można wdrożyć i pokazać użytkownikowi końcowemu. Wyobraźmy sobie w takim razie, że piszemy kod słabej jakości. Po kilku wydaniach narasta nam dług technologiczny i utrzymywanie takiej architektury zacznie nam blokować pracę, z czego nasz klient na pewno nie będzie zadowolony. Model scrumowy wymaga od nas pisania kodu, który da się łatwo utrzymywać i rozwijać.

Testy już od początku trwania projektu

W scrumie projekt podzielony jest na sprinty (od tygodniowych, do maksymalnie miesięcznych okresów), na których koniec musimy dostarczyć jakiś działający fragment kodu. Wymusza to prowadzenie testów już od pierwszego sprintu i to możliwie jak najwcześniej, aby móc zaprezentować klientowi sprawdzone rozwiązanie. Sprawia to, że tester przestaje być kontrolerem, który stoi na końcowej “bramce” i odrzuca brzydkie rozwiązania. Staje się natomiast graczem zespołu developerskiego, któremu pomaga w dbaniu o jakość projektu. Przestaje istnieć typowa rola testera, a jej miejsce zajmuje jeden zespół, który dąży do realizacji celu na zakończenie sprintu.

Już podczas planowania sprintu może przydać się “testerskie” spojrzenie na projekt i dociekanie jak system zachowa się w określonych przypadkach.

Innym ciekawym rozwiązaniem może być pisanie testów jeszcze zanim powstanie kod. Wówczas tester będzie musiał przemyśleć przypadki użycia i dopytać się o te, na które programista mógłby nie wpaść podczas pisania danej funkcji.

Pomyłka nie jest aż tak kosztowna

W tradycyjnym modelu biznesowym zespołowi programistów dostarczana jest specyfikacja, zgodnie z którą powstaje projekt. Możemy więc wyobrazić sobie przypadek, w którym z dobrze przygotowanej specyfikacji tworzymy projekt w 100% zgodny ze wszystkimi zawartymi tam wymaganiami. Projekt trwa pół roku i po tym czasie trafia do użytkownika końcowego, ale temu nie podoba się to, co wymyślił projektant. Wydawałoby się, że dostarczony przez nas projekt jest doskonały jakościowo, bo był zgodny z tym, czego chciał od nas klient. Jednak rynek nie zapamięta tego jako naszego sukcesu.

W scrumie na koniec każdego sprintu dostarczamy działający fragment, który - jeśli tylko klient sobie tego życzy - wdrażamy i pokazujemy użytkownikowi końcowemu. Dzięki czemu, jeśli podążamy w złym kierunku, tracimy co najwyżej prace z jednego sprintu. 

Szybkie dostarczanie wspiera automatyzowanie

Z jednej strony co sprint musimy dostarczać nowy fragment działającego kodu, z drugiej - nie psuć funkcji już działającej. W efekcie liczba rzeczy do przetestowania zaczyna narastać w takim tempie, że bez zautomatyzowania tego procesu, musielibyśmy zwiększyć liczbę osób, które będą sprawdzały stronę przed wdrożeniem. A ponieważ za jakość projektu nie jest odpowiedzialny tylko tester, a cały zespół, to programiści chętniej pomagają we wprowadzeniu frameworka testującego.

Komunikacja, komunikacja i jeszcze raz komunikacja

Codzienne spotkania zespołu developerów, wśród którego są też testerzy, wspierają komunikację w zespole. W przypadku wykrycia błędu wie o nim cały zespół i może zareagować odpowiednio szybko.

W scrumie nie tylko zespół musi się ze sobą komunikować, ale wymuszone są też rozmowy z przedstawicielem klienta (Product Owner). Ma to duże znaczenie, ponieważ zespół nie tylko informuje go o postępie swoich prac, ale również dostaje odpowiedzi od niego w sprawie zadań, co do których są wątpliwości (np. jak pewna funkcja ma działać).

Oczywiście klient mówi z reguły językiem biznesowym, a programiści technicznym, ale z naszego doświadczenia wynika, że podczas kolejnych spotkań zaczynają się oni coraz lepiej dogadywać. Eliminuje to przypadki, w których programista musi się domyślać, jak powinien działać system oraz takie, w których to klient chciałby się czegoś dowiedzieć o postępie pracy, ale w sumie nie wie, od kogo mógłby takie informacje uzyskać.

Reaguj szybko i łap okazje

Jak już wcześniej wspominałem, w projektach zwinnych (a więc także scrumowych), staramy się możliwie często dostarczać wersje projektów gotowe do wdrożenia i pokazania użytkownikowi. Dzięki temu możemy szybciej niż w tradycyjnym sposobie tworzenia, sprawdzać nasze koncepcje biznesowe i wcześniej zacząć czerpać z nich korzyści. 

Tak samo sprawa ma się ze zmianami, które wymusza na nas rynek. Ponieważ nasz projekt musi powstawać w sposób, który pozwala na jego łatwiejsze modyfikacje, możemy w szybszy sposób przystosować nasz projekt do nowych warunków.  

Myślę, że przytoczone tutaj argumenty są wystarczające, żeby przemyśleć czy nie warto przypadkiem spróbować prowadzić projekt w scrumie. Jeśli chcesz dowiedzieć się więcej o scrumie koniecznie sprawdź inne nasze artykuły na ten temat:

• Zdalny Zespoł Scrum,
• Modele współpracy zespołu developerskiego z klientem,
• Jak działa Sprint Retrospective?

Zachęcam również do śledzenia naszego bloga, bo na pewno nie jest to nasz ostatni wpis, poświęcony tej tematyce.

Na zakończenie chciałbym przytoczyć motto rodziny Gucci: “Jakość pamięta się o wiele dłużej niż cenę”. Nie chodzi tutaj jednak o wskazanie, że tylko drogie projekty są dobre, ale o to, że jeżeli nie zadbamy o właściwą jakość projektu, nasi użytkownicy szybko nam tego nie zapomną. Starajmy się więc - w kontekście projektów - zawsze myśleć o ich odpowiedniej jakości, a z pewnością nasi klienci docenią takie podejście.