Jakość w Agile. Zwinna droga do sukcesu - ebook

Przedmowa

Praca w metodzie Scrum przypomina trochę grę w piłką nożną. Zasady gry, opracowane przez International Football Association Board (IFAB), są proste i jasno określone. Ale jak grać, by wygrać? O tym zasady już nic nie mówią. Bo sukces meczu zawsze zależy od zespołu. Przepisy gry w piłkę wyznaczają tylko ramy działania – warunki brzegowe, w obrębie których zespół może się poruszać. Scrum nie opisuje więc standardów czy konkretnych rozwiązań, z których moglibyśmy skorzystać podczas realizacji prowadzonych przedsięwzięć. Jest raczej modelem działania. Dostarcza zespołom projektowym jedynie pewnej struktury (framework) – konkretnych praktyk i zasad, które wyznaczają ramy dla ich aktywności.

Tak jak istnieją różne taktyki gry w piłkę nożną – sposoby atakowania, obrony, ustawienia zawodników – podobnie jest w Scrumie. To jest metoda, którą można implementować na różne sposoby. I chociaż nie ma jednej słusznej drogi jej stosowania, są lepsze i gorsze sposoby jej realizacji.

Książka Jakość w Agile, której autorami są Rafał Stańczak oraz Karolina Zmitrowicz, pomoże każdemu je odkryć. Z wielu względów jest to publikacja szczególna na polskim rynku wydawniczym. Przede wszystkim dlatego, że z precyzją snajpera jej twórcy skupili się na jednym, bardzo konkretnym aspekcie pracy zwinnych zespołów – zarządzaniu jakością. Od razu dodam, że nie jest to kolejna książka o testowaniu w Agile – chociaż tematyka testów jest w niej jak najbardziej obecna. Autorzy podeszli do tematu szerzej, bardziej kompleksowo. Pokazują, jak stworzyć zwinny system zarządzania jakością w firmie.

Ogromną zaletą tej pracy jest fakt, że Rafał i Karolina szanują tradycję. Sam na co dzień pomagam organizacjom w stosowaniu zwinnych metod pracy i bardzo często spotykam się z podejściem, że wdrożenie Agile w firmie powinno oznaczać wielką rewolucję. Powinien pojawić się buldożer gigant i zrównać wszystko z ziemią, byśmy mogli zbudować nasz firmowy świat od zera. Stare procesy i narzędzia są złe. Powinniśmy je jak najszybciej wymienić na nowe. To tak nie działa. Nie da się zburzyć firmy i zbudować jej od początku. Zwinna transformacja to proces ewolucyjny, który w dużym stopniu opiera się na empiryzmie, który tworzy podwaliny Scruma. Autorzy reprezentują takie właśnie podejście.

W Jakości w Agile znajdziemy „stare” praktyki i narzędzia dotyczące jakości, które zostały zaadaptowane do zwinnych metod pracy. O wielu z nich część z nas już na pewno zapomniała albo udaje, że są im niepotrzebne („bo jesteśmy Agile”). Autorzy przypominają koncepcję bramek jakości, mówią o śledzeniu powiązań wymagań, o zarządzaniu ryzykiem. Pokazują, w jaki sposób te i wiele innych praktyk z obszaru zarządzania jakością możemy wykorzystać w swoich codziennych projektach i wciąż być Agile.

Cieszę się, że ta książka powstała. Jestem przekonany, że jej lektura pomoże czytelnikom wybrać jeden z wielu możliwych sposobów wdrożenia metod zwinnych w firmach, który zapewni ich zespołom powodzenie.

Mariusz Chrapko

MariuszChrapko.com

Wydaje się, że Agile nie wniósł do świata produkcji oprogramowania rewolucyjnie nowych koncepcji. Większość proponowanych technik, choć ubranych w nowe szaty, była znana od dawna. Taki planning poker to nic innego, jak znana od lat 50. XX w. technika wide band delphi. Szeroko spotykane demo i retro są stosowane od zawsze w medycynie i edukacji pod innymi nazwami, jak sesje lesson learned, przejrzenie czy testy akceptacyjne z użytkownikiem, są znane od zawsze również w IT. Realnie patrząc, metodologia wokół zwinności porządkuje metody, które już były zdefiniowane wcześniej, i wybiera te, które wydają się być optymalne do osiągnięcia celów zwinnych projektów. Czytając manifest Agile, widzimy bardziej filozofię niż zestaw praktycznych porad. Jest tam zadowolenie klienta, zaufanie, komunikacja oraz rozwój jednostek.

Jednakże o samej jakości nie mówi się wcale w manifeście i w jego zasadach. Jest ona nienazwana, ale jednocześnie wbudowana w całą strukturę Agile. Może dlatego, że jest subiektywna, a może dlatego, że jest oczywista? Nie uzyskamy przecież zadowolenia klienta bez dostarczenia mu wysokiej jakości rozwiązania. Mówiąc o dostarczaniu oprogramowania w Agile, mówimy o walce, by w realiach trudnego rynku i wymagającego klienta dostarczyć coś, co nie tylko będzie działać, lecz także którego funkcje będą zaspokajać potrzeby jego odbiorców. A czym innym jest jakość? Jeśli klient uzna, że produkt spełnia jego wymagania i jest z niego zadowolony, to znaczy, że jakość została dostarczona.

Otwarte pytania, jakie pozostają, to JAK:

• dostarczyć produkt, by w realiach zmieniających się wymagań klient był zadowolony?

• dostarczać produkt szybko?

• tworzyć tylko potrzebne rzeczy?

Wielu powie – wdróżmy Agile, ale mnóstwo pytań ciągle pozostanie bez odpowiedzi. Kiedy mamy już chętny do zmiany zespół, na końcu musimy sobie odpowiedzieć, którą metodę, technikę i jakie narzędzia warto zastosować? I tu dochodzimy do celu powstania tej książki. Nie da się opisać wszystkiego w jednej publikacji, ale można pokazać punkt startowy. Autorzy zbierają wszystkie popularne metody kontroli i zapewnienia jakości w jednym miejscu i pokazują, czym są. Publikacja daje więc pierwszy wgląd i zachętę do kolejnych poszukiwań. Rzeczy oczywiste w Agile są nieoczywiste w bardziej klasycznych formach tworzenia oprogramowania i warto się im przyjrzeć głębiej. Przykładem może być koncept w relacji programista–tester, zwany czasami „my i oni”.

W zwinnym świecie zdewaluował się on całkowicie. Nie ma „my” czy „oni”, jest jeden zespół, w którym każdy z jego członków odpowiada za jakość wytwarzanego oprogramowania. Organizacje, w których nie ma silnej współpracy między wytwórcami oprogramowania a tymi, którzy to oprogramowanie akceptują, są archaicznym gatunkiem skazanym na wymarcie. Niby proste, ale nawet wśród członków zespołów scrumowych można znaleźć wiele osób, którym nadal trzeba to powtarzać…

Warto podkreślić, że rynek IT zmienia się w szybkim tempie. Książka, którą czytasz, zawiera analizę i podsumowanie sytuacji na rynku w momencie jej wydania. Jest to „snapshot” z 2018 r. Może być tak, że dzisiejszy dogmat jutro zmieni się w kwestionowaną teorię, a profetyzm może w przyszłości stać się rzeczywistością. Nie zmienia to faktu, że część konceptów ulega jedynie niewielkim, ewolucyjnym zmianom. Zdefiniowane już dawno temu QA, Scrum czy TDD dziś wcale nie są czymś zupełnie innym od tego, czym były w dniu swojego pojawienia się. Powstają nowe rzeczy, a ich implementacja również wymaga czasu. Święcący swój złoty czas DevOps został zdefiniowany w 2009 r., a jego propagacja i penetracja rynku IT de facto dopiero na dobre się rozpoczęła. Opóźnień w implementacji różnych, ciekawych metod, technik i koncepcji wytwarzania oprogramowania można upatrywać w wielu źródłach, ale jednym z nich będzie brak właściwych narzędzi. Przy pojawieniu się oprogramowania dostają one zastrzyk energii i nagle stają się istotną składową procesu wytwórczego. Książka daje jej czytelnikom przykłady narzędzi do wielu różnorodnych zastosowań.

W projektach Agile spotykają się ze sobą perspektywy tzw. trzech amigo – biznesu, programisty i testera. Perspektywę analizy biznesowej reprezentuje Karolina. Perspektywę zwinnej jakości pokazuje Rafał. Opisane w pracy podejście jest więc perspektywą ról klasycznie kojarzonych z jakością i odpowiedzialnych za weryfikację i odbiór jakości. Jest również ważną perspektywą idącą ze świata biznesu i testów. Za sprawą wykształcenia, przygotowania oraz ról, jakie autorzy odgrywają w projektach, opisują podejście, które wielu programistom może być nieznane. Samo to przemawia na korzyść publikacji i jej wartości dla czytelników. Jeżeli jako tester lub przedstawiciel biznesu uczycie się swojej roli w zwinnym świecie, to dzięki tej książce poznacie zakres swoich obowiązków i dowiecie się, jakich narzędzi (nie tylko software’owych) przyjdzie wam używać.

Właśnie rozpoczynacie czytać całościowe kompendium technik i metod kontrolowania i zapewniania jakości. Nie każda z nich będzie wartościowa w waszym projektowym świecie, nie każda będzie możliwa do zaimplementowania – celem jest dokonanie przez was wyboru metod optymalnych i dostosowanie ich do kontekstu środowiska, w jakim (współ)produkujecie software. Tak definiujemy zwinność.

Tak definiujemy dbanie o jakość w Agile.

Radosław Smilgin

testerzy.plWstęp

Podejścia zwinne są dzisiaj jednymi z najpopularniejszych metod tworzenia oprogramowania. Ich zastosowanie sięga daleko poza obszar technologii: Agile kreuje i współtworzy biznes, jest zalążkiem powstawania nowych organizacji, wspiera transformacje cyfrowe firm z różnych branż, obejmuje swym zasięgiem coraz szersze obszary kultury organizacyjnej oraz samej organizacji pracy. W lutym 2001 r., po tym jak 17 sygnatariuszy manifestu Agile spotkało się w Utah w USA, podejmując wysiłek zrobienia czegoś dobrego dla innych, w naszym przekonaniu powstało coś przełomowego.

Dzisiaj, po wielu latach od momentu podpisania manifestu Agile, nadal nie wiemy wszystkiego, nadal nie wszystkie karty zostały odkryte. Nadal zgodnie z jednym z podstawowych założeń Agile powinniśmy nieustannie poszukiwać lepszego jutra, dostosowując się do nieustannie zmieniającego się otoczenia. Aby wysiłek ten zakończył się sukcesem, potrzebne jest jeszcze to coś – wysoka jakość na każdym etapie prac i jej rezultatów, która od zawsze była, jest i będzie wartościowa.

Do tej pory na polskim rynku powstało wiele publikacji dotyczących wytwarzania oprogramowania, ale żadna z nich nie była dedykowana tematyce jakości w środowiskach zwinnych. Zdecydowaliśmy się napisać tę książkę, by przede wszystkim wesprzeć bez wyjątku członków zespołów zwinnych (w tym osoby z perspektywą analityczną, deweloperską, testerską czy zajmujące się utrzymaniem). Pomóc im zadbać o jakość na każdym pojedynczym etapie procesu wytwórczego, pokazując mnogość koncepcji, stylów, praktyk i narzędzi do osiągnięcia celu.

Chcemy pomóc także osobom z tzw. biznesu, spojrzeć łaskawszym okiem na wysiłek wszystkich osób zajmujących się szeroko rozumianą jakością, umożliwić im zrozumienie trudu budowania i realizowania strategii, procesów oraz wszelkich inicjatyw związanych z zarządzaniem jakością. Wierzymy, że dzięki temu łatwiej i szybciej dostrzegą wysiłek potrzebny do zapewnienia wysokiej jakości, będą potrafili przekuwać jakość wytworzonych produktów w późniejsze zyski oraz zrozumieją, w jaki sposób organizacje mogą podnosić dzięki jakości swoją konkurencyjność i efektywność na szerokim rynku.

Kiedy z czegoś małego może powstać coś większego? Wtedy, gdy ludzie znajdą dla tego wiele zastosowań i po pewnym czasie nie będą chcieli pracować w inny sposób. Na koniec chcielibyśmy zaproponować model ciągłego zapewniania jakości oparty na zestawie bramek jakości oraz na manifeście ciągłego zarządzania jakością w Agile. Wierzymy, że dzięki naszej pracy pomożemy czytelnikom uzupełnić ich własne procesy zarządzania jakością o brakujące ogniwa i przez to częściej odnosić sukcesy na co dzień.

Rafał Stańczak i Karolina ZmitrowiczPodziękowania

Ta książka to najlepszy dowód na to, że marzenia się spełniają, jeśli tylko naprawdę tego chcemy. Dziękuję żonie Magdzie oraz synom Kubie, Adamowi i Oliwierowi za to, że dzielnie znosili moją „niepełną obecność” w życiu domowym i nieustannie wspierali mnie w trudzie tworzenia tej książki. Dziękuję wszystkim pozostałym, którzy przyczynili się do jej powstania. Pisanie to fantastyczna sprawa, ale nie byłoby łatwo, gdyby nie przyjemność pracy z prawdziwymi profesjonalistami w swoim fachu. Specjalne podziękowania dla Współautorki i Wydawnictwa!

Rafał Stańczak

Wszystkim tym, którzy są dla mnie ciągłą inspiracją. Dziękuję, że jesteście.

Karolina Zmitrowicz2 Inżynieria wymagań w projektach zwinnych

Czy nie mógłby pan mnie poinformować, którędy powinnam pójść?

To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść –

odparł Kot-Dziwak. Właściwie wszystko mi jedno.

W takim razie również wszystko jedno, którędy pójdziesz.

Lewis Carroll, Alicja w Krainie Czarów

Co wspólnego mają wymagania z jakością? Dlaczego piszemy o inżynierii wymagań w książce poświęconej jakości w Agile?

Nie odkryjemy Ameryki, twierdząc, iż wymagania mają bezpośredni wpływ na zakres, kształt i rodzaj rozwiązania problemu biznesowego będącego przedmiotem określonego projektu. Między wymaganiami a jakością, zarówno produktu procesu wytwarzania, jak i samych procesów, istnieje oczywista zależność. To wymagania definiują produkty, to wymagania determinują czynności, techniki, podejścia, które trzeba zastosować celem realizacji przedmiotu projektu. Dlatego też inżynierii wymagań poświęcimy cały rozdział naszej książki.

2.1. Wprowadzenie do inżynierii wymagań

Nie sposób rozmawiać o jakości, nie analizując tematu wymagań i inżynierii wymagań. Wszak to wymagania definiują produkt – jego funkcjonalność, ale i atrybuty jakościowe. To wymagania określają potrzeby interesariuszy i mogą nakładać na przedsięwzięcie pewne ograniczenia, jak czas realizacji, budżet czy technologie. To wymagania precyzują zakres prac i minimalną jakość produktu.

Wymagania są więc podstawową informacją wejściową do procesów zarządzania jakością produktu. Bez wymagań nie jesteśmy w stanie określić pożądanego kształtu rezultatów projektu, nie mamy również kryteriów odbioru dla produktów przedsięwzięcia. Najczęstsze przyczyny niepowodzeń projektów IT zostały przedstawione na rysunku 2.1. Słaba definicja wymagań oraz zakresu prac odpowiada, bagatela, za 65% niepowodzeń projektów – to tu wszystko się zaczyna…

Rysunek 2.1. Dlaczego projekty IT się nie udają?

Źródło: ESI International survey of 2000 business professionals, 2005, https://es.slideshare.net/miroslawdabrowski/iqbba-foundation-level-business-analyst (dostęp: 20.08.2017).

O definicji wymagań oraz samej inżynierii wymagań napisano już sporo prac, nie będziemy więc szczegółowo zajmować się tym tematem. W celu przejrzystości i zrozumienia dalszej części publikacji przytoczymy jedynie podstawowe definicje.

BABOK® (Business Analysis Body of Knowledge) definiuje wymaganie jako „reprezentację potrzeby”. Według tego źródła, wymagania „skupiają się na zrozumieniu, jakiego rodzaju wartość może być dostarczona, jeśli wymaganie jest spełnione”. Widzimy tu więc bezpośrednie nawiązanie do wartości, która jest nieodłącznie związana z postrzeganą przez interesariuszy jakością.