Projekt okładki Hubert Zacharski

Wydawcy Łukasz Łopuszański, Edyta Kawala

Redaktor prowadzący Jolanta Kowalczuk

Korekta Dorota Polewicz

Koordynator produkcji Anna Bączkowska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN Marcin Kapusta / konwersja.virtualo.pl

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji

Copyright © by Wydawnictwo Naukowe PWN SA

Warszawa 2018

eBook został przygotowany na podstawie wydania papierowego z 2018 r., (wyd. I)

Warszawa 2018

ISBN 978-83-01-20068-8

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl, www.pwn.pl

Spis treści

Przedmowa

Wstęp

Podziękowania

1. Zarządzanie jakością. Kultura jakości w organizacji

1.1. Koncepcja zarządzania jakością

Koncepcja jakości

Zarządzanie jakością

Zarządzanie przez jakość

1.2. Ustalenie procesu zarządzania jakością

1.3. Proces transformacji z podejścia tradycyjnego do zwinnego

Kontekst zarządzania jakością

Planowanie czynności zapewniania jakości i testowania

Postęp prac

Proces zgłaszania i naprawy defektów

1.4. Modele funkcjonowania zespołów – podejście tradycyjne a zwinne

Zapewnianie jakości w organizacji

Pojedyńczy zespół pracujący nad jednym produktem

Wiele zespołów pracujących nad jednym produktem

2. Inżynieria wymagań w projektach zwinnych

2.1. Wprowadzenie do inżynierii wymagań

Zadania i czynności inżynierii wymagań

Śledzenie powiązań

2.2. Interesariusze – z kim i dla kogo?

Wizja produktu

2.3. Metody oraz formy pozyskiwania i dokumentacji wymagań

Historyjki użytkownika

Model INVEST

Persona

Przypadki użycia

Prototypy, makiety, szkielety

2.4. Przegląd wymagań i zgłaszanie poprawek

Kontrola jakości

Definicja gotowości i ukończenia – kiedy można zacząć, a kiedy już skończyć

Walidacja wymagań i współpraca z biznesem – pielęgnacja rejestru produktu

2.5. Wsparcie narzędziowe

Mapy myśli

Modelowanie oprogramowania

Modelowanie procesów biznesowych

Prototypowanie

Narzędzia wspierające pracę grupową

3. Budowanie strategii testów w organizacji

3.1. Strategia na poziomie organizacji

3.2. Polityka i ogólna strategia testów

3.3. Poziomy testów

Pojęcie weryfikacji i walidacji

Poziomy testów

3.4. Piramida testów w Agile

3.5. Koncepcja kwadrantów testowych

3.6. Różne podejścia do testowania

Testowanie oparte na ryzyku

Testowanie oparte na modelach

3.7. Podejścia do tworzenia i wytwarzania architektury

TDD

BDD, SBE, ATDD

Mikroserwisy

3.8. Zarządzanie ryzykiem – techniki i metody

Tradycyjne zarządzanie ryzykiem

Plan zarządzania ryzykiem

Zwinny proces zarządzania ryzykiem

Identyfikacja ryzyk w projektach zwinnych

Wartość zarządzania ryzykiem

Strategie reakcji na ryzyko

3.9. Strategia automatyzacji

Cel automatyzacji

Co warto i można automatyzować

Problemy związane z automatyzacją

Wykorzystanie narzędzi

Wprowadzanie nowych narzędzi w organizacji

Weryfikacja zakładanej koncepcji

Analiza porównawcza

3.10. Dokumentacja testów – szablony i dobre praktyki

3.11. Organizacja pracy w zespole

Wartości wspierające pracę zespołową

Praca w parach

Praca w zespołach rozproszonych

3.12. Wsparcie narzędziowe

Narzędzia wspierające pracę grupową

Narzędzia wspierające planowanie prac

Inne narzędzia

4. Planowanie testów w projekcie

4.1. Testowanie w projekcie

4.2. Organizacja i model pracy

Przygotowanie modelu

Budowa repozytorium scenariuszy testowych

Przepływ pracy dla scenariuszy testowych

Planowanie działań testowych

4.3. Realizacja kampanii testowej

4.4. Raportowanie wyników kampanii testowej

Raporty z procesów zarządzania jakością

4.5. Środowiska i dane testowe

4.6. Wsparcie narzędziowe

Narzędzia do zarządzania wiedzą

Narzędzia do zarządzania zgłoszeniami

Narzędzia do zarządzania testami

Narzędzia wspierające planowanie prac

Narzędzia wspierające pracę grupową

5. Techniczne zapewnienie jakości

5.1. Pojęcie długu technicznego

5.2. Standardy budowania kodu

5.3. Testy jednostkowe

Raportowanie z testów automatycznych

5.4. Statyczna analiza kodu

5.5. Przeglądy/inspekcje kodu

5.6. Agile a DevOps

Praktyki pracy ciągłej

5.7. Wsparcie narzędziowe

Zintegrowane środowisko programistyczne

Repozytoria kodu źródłowego

Narzędzia do testów jednostkowych

Narzędzia do raportowania pokrycia kodu testami jednostkowymi

Narzędzia do analizy statycznej

Narzędzia do budowania wersji

6. Testowanie wartości biznesowej produktu

Testy eksploracyjne

Zarządzanie testami oparte na sesjach

Inne rodzaje testów

6.1. Retrospekcja postępu prac

6.2. Wsparcie narzędziowe

Raportowanie z SBTM

Narzędzia wspierające testy na wielu przeglądarkach i systemach operacyjnych

7. Utrzymanie produktu

7.1. Zarządzanie incydentami

7.2. Koncepcje obsługi zgłoszeń na produkcji

Analiza przyczyn źródłowych problemu wraz z sugestią procesu naprawczego

7.3. Wsparcie narzędziowe

Narzędzia wspierające RCA

Narzędzia do monitoringu wsparcia produkcji

Narzędzia do zarządzania wiedzą

Wspólne tworzenie dokumentów

Tablice kanbanowe

8. Ciągłe zapewnienie jakości

Zwinne myślenie

8.1. Koncepcja łańcucha bramek jakości

8.2. Zapobieganie występowaniu problemów

Techniki i metody zapewniania jakości

Monitoring

8.3. Wsparcie narzędziowe

Narzędzia do monitoringu infrastruktury i systemów IT

9. Dobrze. Lepiej. Bardzo dobrze Lepsze zarządzanie jakością w Agile

9.1. Wizualizacja potrzeb związanych z zarządzaniem jakością w organizacji plus edukacja wewnątrz firmy

Ewangelista zapewniania jakości

Zwinne gildie. Model Spotify

9.2. Jak i gdzie zdobywać wiedzę?

Szkolenia i certyfikacje

Coaching

Meetupy – cykliczne spotkania społeczności

Idea open space

Konferencje

Podsumowanie

Manifest zwinnego zarządzania jakością

Praktyki zwinnego zarządzania jakością

Bibliografia

Spis rysunków

Spis tabel

Przypisy

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.pl

Wstę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 Zmitrowicz

Podzię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 Zmitrowicz

1

Zarządzanie jakością. Kultura jakości w organizacji

O jakości można mówić,

kiedy tym, co do nas wraca,

są klienci, a nie produkty.

Motto Siemensa

1.1. Koncepcja zarządzania jakością

Pojęcie „zarządzanie jakością” pojawia się w niemal każdym podręczniku do zarządzania projektami. Proces ten stanowi nieodłączny element dobrej organizacji wszelkiego rodzaju projektów, w tym informatycznych. I o ile o zarządzaniu jakością ogólnie napisano już wiele, o tyle brakuje dobrego usystematyzowania tej wiedzy w kontekście metod zwinnych.

Przyjrzyjmy się więc tematom jakości i zarządzania jakością.

Koncepcja jakości

Pisząc o jakości w świecie Agile, nie sposób nie poruszyć samego pojęcia jakości. Nie jest to termin nowy – podobnie jak nie są nowe założenia stojące za samą filozofią Agile. O jakości wspominali już starożytni – pierwsze (a przynajmniej najbardziej znane i uważane za pionierskie) udokumentowane zastosowanie pojęcia znanego dziś jako jakość pojawiło się w Kodeksie Hammurabiego z 1750 r. p.n.e. Nie jest to jedyny przykład faktu poświadczającego świadomość jakości istniejącą wieki przed naszą erą – w jednym z grobowców faraonów odkryto opis metody kontroli równoległości bloków kamiennych za pomocą sznura. Metodę tę datowano na 1450 r. p.n.e.[1]

Współcześnie dominujące definicje jakości określają ją najczęściej jako spełnienie określonych wymagań klienta czy użytkownika. Nacisk na spełnianie wymagań odbiorcy wynika w dużym stopniu z konieczności dopasowania produktów i usług do potrzeb i oczekiwań grupy docelowej, co przekłada się na wzrost potencjalnych zysków producenta. W erze konsumpcjonizmu i nadmiaru wszelkich dóbr skłonienie konsumenta do wyboru naszej oferty spośród setek innych wiąże się z koniecznością wyróżnienia się. Jednym ze sposobów wyróżnienia jest ponadprzeciętna jakość – rozumiana jako spełnienie, a idealnie – przekroczenie, oczekiwań potencjalnego nabywcy.

Współczesnych definicji jakości jest wiele – czytelników zainteresowanych tym tematem odsyłamy do literatury i źródeł poświęconych stricte pojęciu jakości. Stosując uproszczenie, pozwolimy sobie przedstawić własną definicję jakości: to stopień, w jakim proponowane rozwiązanie dostarcza wartość określonym interesariuszom w ich środowisku biznesowym, technologicznym i kulturowym[2]. Tematem tej książki nie jest jednak sama definicja jakości, a jej implementacja w różnych obszarach i kontekstach.

Znając już definicję jakości, przejdźmy do kolejnych pojęć, których zrozumienie jest niezbędne do zbudowania własnej strategii jakości.

Zarządzanie jakością

Zarządzanie jakością – ileż to razy słyszymy to wyrażenie… i odkrywamy po pewnym czasie, że jest ono używane w kompletnie błędnym kontekście, a samo pojęcie zarządzania jakością nie do końca jest rozumiane… Jest to istotny problem, jak bowiem chcemy podejść do planowania i wdrażania jakiejkolwiek strategii jakości, nie rozumiejąc podstawowych koncepcji, na których taka strategia ma się opierać?

Wyjaśnijmy, czym jest zarządzanie jakością. Najprościej rzecz ujmując, to jedna z koncepcji zarządzania, której podstawowym celem jest zapewnienie procesów, metod i środków umożliwiających dostarczenie produktów i usług o określonej (zadeklarowanej uprzednio) jakości. Warto zwrócić uwagę na ostatnie słowa poprzedniego zdania – aby wdrożyć proces zarządzania jakością, należy najpierw zdefiniować i uzgodnić między interesariuszami inicjatywy wspólne pojęcie jakości – bez niego nie ma możliwości skutecznej realizacji tego procesu. Jako argument można przywołać tu słynne stwierdzenie przypisywane E. Demingowi: „Jeśli nie możesz czegoś zmierzyć, nie możesz tym zarządzać”. Jeśli chcemy zarządzać jakością, najpierw musimy wiedzieć, czym ona jest: jak definiują ją nasi interesariusze, jakich aspektów produktu/usługi dotyczy, jak ją mierzalnie wyrazić i sprawdzić, czy osiągnięto jej zakładany poziom.

Planując czynności zarządzania jakością, warto uwzględnić fakt, że koncentrują się one nie tylko na finalnej jakości produktów procesów wytwórczych, lecz także na środkach pozwalających na osiągnięcie tej jakości, czyli procesach. Zarządzanie jakością można więc postrzegać jako planowanie i sterowanie jakością procesów w celu osiągnięcia stałego, określonego poziomu jakości.

Zarządzanie przez jakość

Pisząc o jakości w świecie Agile, nie sposób nie nawiązać do TQM (Total Quality Management), filozofii jakości, w której można doszukiwać się źródeł co najmniej kilku zasad i praktyk zwinnych. TQM, czyli zarządzanie przez jakość lub kompleksowe zarządzanie jakością, to wywodzące się z Japonii projakościowe podejście do zarządzania organizacją – w TQM każdy aspekt działalności przedsiębiorstwa powinien osiągać określony poziom jakości. Celowi temu służą następujące koncepcje, stanowiące podwaliny zarządzania przez jakość: praca zespołowa, zaangażowanie, samokontrola i stałe podnoszenie kwalifikacji personelu. Warto zwrócić uwagę na to, że zgodnie z filozofią TQM wszyscy członkowie firmy biorą czynny udział w czynnościach związanych z zapewnieniem jakości. Za jakość odpowiada cała kadra, począwszy od kadry menedżerskiej, odpowiedzialnej za aktywne budowanie świadomości jakościowej u pracowników i dążenie do osiągnięcia wysokiej satysfakcji konsumentów, co w skali czasu przekłada się na sukces działalności biznesowej. Klient jest podstawowym elementem podejścia TQM.

Wyraźne widać tu analogie do metodyk zwinnych, również dążących do zapewnienia satysfakcji odbiorcy końcowemu, co realizowane jest m.in. przez zaangażowane (wynikające m.in. z poczucia odpowiedzialności za projekt, produkt i jego jakość) oraz samoorganizujące się zespoły (samoorganizacja wymaga wszak silnie rozbudowanej świadomości projakościowej).

W naszych polskich realiach TQM reprezentuje od wielu wielu lat – polski uczony, profesor matematyki oraz znany warszawski cukiernik – Andrzej Blikle. Otóż profesor w swojej rodzinnej firmie cukierniczej, prowadzonej przez pokolenia od 1863 r., stosuje z sukcesami kompleksowe zarządzanie jakością. Elementami jego stylu zarządzania są m.in.: zarządzanie bez kar i nagród, niezmienne wynagrodzenie, które rośnie w miarę realizacji całościowych celów firmy, dbałość o szeroko zakrojone szkolenia wewnętrzne – o to, aby każdy pracownik znał dokładnie asortyment oferowanych produktów, standaryzacja procesu sprzedaży i obsługi klienta we wszystkich lokalizacjach oraz ogólne przykładanie uwagi do małych detali. Elementy te czynią z jego cukierni dobrze naoliwioną maszynę do zarabiania pieniędzy oraz stanowią doskonały przykład potwierdzający teorię w praktyce.

Wracając jednak do samej istoty TQM, warto przypomnieć jej podstawy. Są to przede wszystkim zasady Deminga, zasada ciągłego doskonalenia procesów (kaizen) oraz zasada zera błędów, której autorstwo przypisuje się Philipowi B. Crosby’emu.

Wspomniane zasady Deminga obejmują m.in.:

• stałą dbałość o doskonałość produktu, z celem spełnienia potrzeb klientów w możliwie największym stopniu;

• budowanie przekonania o konieczności wdrożenia zintegrowanego systemu zarządzania jakością;

• stałe usprawnianie procesów wpływających na jakość;

• wdrożenie nowoczesnych metod nadzoru.

Zasada ciągłego doskonalenia procesów postuluje wprowadzanie zmian prowadzących do doskonalenia produktu oraz poprawy postrzegania samego producenta przez pryzmat jakości. Samo słowo kaizen pochodzi od japońskich wyrazów kai (zmiana) oraz zen (dobry), co można przełożyć na istotną koncepcję filozofii kaizen – wprowadzanie wartościowych, doskonalących produkt zmian.

Zasada zera błędów kojarzona jest często z powiedzeniem Philipa Crosby’ego: „Jakość jest za darmo”. Zero błędów to bezusterkowe wytwarzanie produktu czy usługi – co oznacza, że proces wytwarzania musi być zaplanowany i zrealizowany w taki sposób, by wyeliminować z niego błędy mogące prowadzić do usterek w finalym produkcie.

Przykład zastosowania zasady zera błędów możemy zaobserwować w ujęciu przywołanych wcześniej cukierni Blikle [Blikle]. „Zero błędów” w ujęciu Blikle oznacza brak charakterystycznego jaśniejszego pierścienia wokół pączka, który profesor uznaje za błąd w sztuce pieczenia. To m.in. również dzięki stosowaniu zasady zera błędów profesor uzyskuje przewagę konkurencyjną oraz efekt wyjątkowości swojego produktu na szerokim rynku.

Koncepcja TQM łączy elementy wielu podejść, zasad i filozofii, czerpiąc z nich i budując na ich podstawie własne zasady. Analizując zasady TQM, nie można oprzeć się wrażeniu, że wiele z nich można odnaleźć w praktykach Agile. Tak jest w istocie – warto znać genezę realizowanych praktyk oraz wyznawanych wartości, ponieważ często ta historia może dostarczyć wskazówek, dlaczego coś działa lub dlaczego w danym kontekście nie zadziała w ogóle.

1.2. Ustalenie procesu zarządzania jakością

W poprzednim podrozdziale wyjaśniliśmy pojęcie jakości oraz zarządzania jakością. Znamy już znaczenie jakości dla satysfakcji odbiorcy i skuteczności funkcjonowania dostawcy produktu czy usługi; wiemy, z czego składa się proces zarządzania jakością.

Teraz – jak ten proces wdrożyć w danej organizacji czy projekcie? Od czego zacząć? Co uwzględnić, a co pominąć? Na początek wyjaśnimy pojęcie procesu.

Powołajmy się na międzynarodową normę ISO 9000, która w wersji z 2008 definiuje proces jako „Zbiór wzajemnie powiązanych i wpływających na siebie działań, które przekształcają wejścia (np. zasoby) w wyjścia (produkty)”. Zasada działania procesu rozumianego w ten sposób jest przedstawiona za pomocą wizualizacji na rysunku 1.1. Do definicji ISO warto dodać nawiązanie do interesującego nas tematu – jakości. Element ten pojawia się w innej interpretacji pojęcia procesu: „zbiór czynności wymagających na wejściu wkładu i dający na wyjściu rezultat mający pewną wartość dla klienta” [Hammer, Champy].

Czym w prostych słowach jest proces? W organizacji wytwarzającej dowolne dobra są to wszelkie działania przyczyniające się do realizacji określonych wartości (produktów czy usług). Co istotne, w ramach jednej firmy zwykle funkcjonuje wiele procesów – wśród nich zarówno te bezpośrednio związane z wytwarzaniem, jak i inne, pomocnicze – np. obejmujące zarządzanie, księgowość. Dla sukcesu funkcjonowania organizacji wszystkie te procesy muszą być ze sobą logicznie i spójnie powiązane. Na tej koncepcji opiera się zarządzanie procesowe stanowiące podstawę wielu nowoczesnych metod zarządzania organizacją.

Rysunek 1.1. Podstawowa budowa procesu według ISO 9000: 2008

Źródło: oprac. własne na podstawie ISO 9000: 2008.

Znajomość koncepcji procesu i zarządzania procesowego jest niezbędna do prawidłowego ustawienia zarządzania jakością – w tym momencie mniej istotny jest fakt, jakimi metodami realizujemy prace, zwinnymi czy tradycyjnymi. Istotne jest to, żeby osiągnąć pożądany poziom jakości produktu, należy zaplanować odpowiednie czynności, sekwencje czynności, które można zwizualizować za pomocą przepływu (workflow), metody, techniki, zasoby, informacje, powiązania między elementami – czyli wdrożyć proces. W tym przypadku mówimy o procesie zarządzania jakością.

Proces ten nie jest niczym nowym – został on już wielokrotnie opisany, a nawet ustandaryzowany. Przykładowo, PMBOK (Project Management Body of Knowledge) wyjaśnia zarządzanie jakością jako zestaw trzech elementów: planowanie jakości, kontrola jakości oraz zapewnienie jakości [PMBOK].

Rysunek 1.2. Procesy zarządzania jakością w kontekście realizacji przedsięwzięcia według PMBOK

Źródło: oprac. własne na podstawie [PMBOK].

Model PMBOK jest wartościowy, jednak brak w nim elementu najważniejszego dla sukcesu systemu zarządzania jakością. Brak w nim koncentracji na ciągłym doskonaleniu, aspekcie niezwykle ważnym w metodach zwinnych. Dlatego też osobiście preferujemy modele wymieniające doskonalenie jakości jako niezbędny element całościowego zarządzania jakością. Takim modelem jest np. ISO 9001. Idealny model systemu zarządzania jakością powinien więc obejmować co najmniej elementy:

• planowania jakości;

• zapewnienia jakości;

• kontroli jakości;

• ciągłego doskonalenia jakości.

Opierając się na własnym doświadczeniu, polecamy rozpocząć pracę od analizy potrzeb jakościowych i wyłonienia na tej podstawie elementów niezbędnych do zaplanowania skutecznego procesu zarządzania jakością. Proces ten możemy usystematyzować i opisać za pomocą tzw. systemu zarządzania jakością opartego na wyjaśnionej wcześniej koncepcji procesu i zarządzania procesowego. System zarządzania jakością obejmuje procesy istotne dla zapewnienia jakości produktu i samego procesu wytwarzania na ustalonym poziomie.

Przykładowe elementy systemu zarządzania jakością możemy zobaczyć na rysunku 1.3.

Sama mapa myśli może nie wystarczyć w przypadku złożonych procesów, obejmujących wiele elementów i dostarczających wiele produktów. Można więc posiłkować się listą kontrolną, dzięki której będziemy w stanie skutecznie określić informacje dotyczące planowanego procesu zarządzania jakością. Przykład listy kontrolnej wspierającej opracowanie kompleksowego systemu zarządzania jakością przedstawiono w tabeli 1.1.

Rysunek 1.3. Mapa myśli przedstawiająca elementy systemu zarządzania jakością

Źródło: oprac. własne K. Zmitrowicz.

Tabela 1.1. Lista kontrolna dla ustalenia procesów zarządzania jakością

Obszar

Tak

Nie

Nie wiem

Lokalizacja informacji

Uwagi

Wizja i cele

Czy określono właściciela procesu analizy biznesowej projektu?

Czy jest znana wizja produktu?

Czy znane są cele biznesowe projektu?

Czy znane są grupy interesariuszy?

Czy wykonano analizę wpływu i zainteresowania interesariuszy ( power-interest)?1

Czy istnieją wymagania najwyższego poziomu (tzw. lista top ten 2)?

Czy istnieją krytyczne kryteria akceptacji dla projektu?

Czy istnieją krytyczne kryteria akceptacji dla produktu?

Zarządzanie ryzykiem

Czy określono właściciela procesu zarządzania ryzykiem?

Czy określono ryzyka biznesowe projektu?

Czy określono ryzyka techniczne projektu?

Czy interesariusze znają zasady realizacji procesu zarządzania ryzykiem?

Czy istnieje plan radzenia sobie z ryzykiem?

Czy w ramach realizacji prac projektowych istnieją mechanizmy ciągłego monitorowania ryzyka?

Komunikacja

Czy zdefiniowano właściciela procesu zarządzania komunikacją?

Czy w projekcie istnieje plan komunikacji?

Czy każdy interesariusz zna swoją rolę i odpowiedzialność w projekcie?

Czy istnieje macierz RACI 3 dla poszczególnych obszarów i ma ona odzwierciedlenie w planie komunikacji?

Czy interesariusze znają zasady procesu zarządzania komunikacją?

Czy ustalono słownik pojęć projektowych?

Zarządzanie informacją

Czy zdefiniowano właściciela procesu zarządzania informacją?

Czy istnieje zdefiniowana architektura informacji w projekcie (np. system zarządzania jakością)?

Czy wszyscy interesariusze wiedzą, gdzie znaleźć określone informacje?

Czy zdefiniowano i wprowadzono zasady zarządzania informacją (np. notatki po spotkaniach)?

Czy zdefiniowano rodzaje informacji podstawowej, która musi być dokumentowana?

Czy wszyscy interesariusze znają zasady tworzenia/aktualizacji informacji?

Czy wszyscy interesariusze przestrzegają zasad tworzenia/aktualizacji informacji?

Jeśli nie – czy zidentyfikowano przyczyny nieprzestrzegania zasad? Jakie one są?

Czy istnieje proces wymiany informacji (np. spotkania Scrumowe)?

Czy interesariuszom znane są zasady realizacji procesu wymiany informacji?

Zarządzanie wymaganiami

Czy zdefiniowano właściciela procesu zarządzania wymaganiami?

Czy zdefiniowano proces zarządzania wymaganiami (np. workflow)?

Czy istnieją udokumentowane wymagania funkcjonalne?

Czy istnieją udokumentowane wymagania niefunkcjonalne?

Czy każde wymaganie ma kryteria akceptacji?

Czy każde wymaganie ma zdefiniowanych interesariuszy (właściciel, odbiorca)?

Czy każde wymaganie ma uzasadnienie biznesowe?

Czy każde wymaganie ma zdefiniowane testy akceptacji?

Czy zdefiniowano techniki identyfikacji wymagań?

Czy zdefiniowano techniki analizy wymagań?

Czy zdefiniowano techniki/notacje do modelowania wymagań?

Czy istnieje wsparcie narzędziowe dla modelowania?

Czy istnieje wsparcie narzędziowe dla zarządzania wymaganiami?

Czy istnieją szablony specyfikacji wymagań?

Czy istnieje wsparcie narzędziowe dla specyfikacji wymagań?

Czy wymagania są mapowane na artefakty projektowe (makiety, zadania projektowe, programistyczne, testowe)?

Czy w ramach realizacji prac projektowych istnieją mechanizmy ciągłego monitorowania jakości procesu zarządzania wymaganiami?

Powiązania – śledzenie

Czy zdefiniowano uczestników procesu śledzenia powiązań?

Czy zdefiniowano wymagania na powiązania między artefaktami projektowymi?

Czy zdefiniowano zasady tworzenia powiązań?

Czy istnieją powiązania między artefaktami projektowymi?

W jaki sposób powiązania są tworzone/utrzymywane?

W jaki sposób mierzone jest pokrycie (różne)?

Czy wykonywana jest analiza wpływu zmian?

Produkty

Czy zdefiniowano listę wymaganych produktów projektu?

Czy znana jest forma dostarczenia produktu?

Czy istnieją szczególne wymagania interesariuszy dotyczące określonych produktów?

Czy zdefiniowano globalną definicję ukończenia DoD (kryteria „odbioru” produktu/półproduktu)?

Czy zdefiniowano definicje gotowości na różnych etapach DoR (kryteria gotowości/wejścia dla określonych prac)?

Testowanie

Czy określono ogólne cele testowania?

Czy znane są podstawy testów dla poziomów testów?

Czy zdefiniowano podejście do testów zgodne z celami projektu?

Czy określono wymagane poziomy testów?

Czy zdefiniowano kryteria wejścia/wyjścia dla poziomów testów?

Czy określono techniki testowe wymagane na różnych poziomach testów?

Czy zdefiniowano proces zarządzania testowaniem (np. workflow)?

Czy istnieje plan na testowanie każdego wymagania?

Czy każdy przypadek testowy ma jasne powiązanie z odpowiednim wymaganiem/zmianą?

Czy testy niesformalizowane (np. eksploracyjne) posiadają mechanizm zapewniania minimum informacji celem podejmowania decyzji?

Czy zdefiniowano wymagania na raportowanie wyników testów?

W jaki sposób raportuje się wyniki testów?

Czy istnieje jasna definicja usterki?

Czy istnieje jasna definicja priorytetu usterki?

Czy zdefiniowano proces zarządzania usterkami (defektami)?

Czy każda usterka/defekt jest powiązana z odpowiednim przypadkiem testowym?

Czy w ramach analizy defektu odbywa się analiza przyczyn źródłowych (RCA)?

Czy zdefiniowano wymagania na raportowanie postępu testów?

W jaki sposób raportuje się postęp testów?

Czy istnieje mechanizm ciągłego monitorowania jakości procesu zarządzania testowaniem?

1 opis metody https://www.stakeholdermap.com/stakeholder-analysis.html (dostęp: 18.08.2017)

2 https://www.gilb.com/blog/on-limiting-your-project-to-10-critical-objectives-initially (dostęp: 18.08.2017)

3 patrz podrozdz.2.2

Źródło: oprac. własne K. Zmitrowicz.

1.3. Proces transformacji z podejścia tradycyjnego do zwinnego

Cały czas obserwujemy na polskim rynku rosnący trend ku zwinnym metodom pracy. Jest to zdecydowanie pozytywne zjawisko, jednak istnieje obawa, że nie zawsze ma to zwieńczenie w finalnej zmianie stylu pracy, systemie wartości, temu wszystkiemu, co przyświeca Agile. Często proces transformacji bywa upraszczany wyłącznie do wdrożenia konkretnych metod i praktyk według zaleceń danej metody – a to nie wystarcza.

Sama decyzja o transformacji powinna zawsze mieć swój początek w postaci konkretnego celu biznesowego, który organizacja wyznaczy sobie sama. Decyzja ta powinna być poparta zmianą sposobu myślenia na temat zarządzania organizacją, produktem oraz pracą z ludźmi. Nie wystarczy w piątek podjąć decyzję, a w poniedziałek rano obudzić się w nowej rzeczywistości i ot tak przejść na zwinny model pracy jako cała organizacja. Nic bardziej mylnego, transformacja to zdecydowanie długotrwały proces.

Odwołajmy się do wyników ankiety amerykańskiej firmy Version One, która corocznie robi badanie na grupie kilku tysięcy respondentów pochodzących z firm związanych z IT z całego świata [VersionOne]. Otóż Version One w swoich raportach mierzy trendy rynkowe związane ze zwinnym zarządzaniem projektami oraz sposoby i kierunek, w jakim ewoluuje cały globalny rynek. Posłużymy się danymi 11 raportu „State of Agile Report” podsumowującymi dane za 2016 r. Warto spojrzeć, jakie nadzieje wiązały organizacje z transformacją na podejścia zwinne oraz jaki był ich główny, ujawniony cel transformacji? Przy okazji poszukajmy wśród tych celów odwołań do jakości. Na rysunku 1.4 przedstawiono 13 najistotniejszych (zdaniem respondentów) powodów adaptacji metod i praktyk zwinnych. Potrzeby zaprezentowane w raporcie można uogólnić na cały rynek – podobne cele mogą przyświecać organizacjom naszych czytelników.

W ankiecie można znaleźć także bezpośrednie odwołania do zarządzania jakością produktów. Znajdziemy je choćby na pozycji numer 5 od góry na rysunku 1.4 z odpowiadającymi 43% głosów respondentów, ale również pośrednio w kilku innych punktach. Skoro prawie co drugi respondent wskazuje zwiększenie jakości produktów jako powód transformacji, potwierdza to hipotezę, że firmy upatrują na to swoich szans właśnie w transformacji zwinnej.

Jeżeli jako organizacja sformułowaliśmy cel transformacji zwinnej, to następnie powinniśmy wyznaczyć metryki sukcesu. W ten sposób należy zwizualizować czy zwerbalizować to, co konkretnie zamierzamy osiągnąć w wyznaczonym horyzoncie czasowym. Wartości metryk zbierane co jakiś czas, niczym punkty kontrolne na trasie wyścigu Formuły 1, dostarczą organizacji informacji o kierunku, w którym podąża transformacja. Ponadto ich odczyty mogą również szybko sygnalizować potrzebę korekty kursu w razie rozmijania się z założeniami. Potwierdzając konieczność zmiany kierunku, powinniśmy również zadać sobie pytanie: „dlaczego zboczyliśmy”. Potrzebne jest zrozumienie, może się okazać niezbędne wprowadzenie poprawek do pierwotnego planu lub modyfikacja samego celu, który w realiach całej organizacji może okazać się niewykonalny.

Rysunek 1.4. Cele organizacji będące przyczyną zwinnych transformacji

Źródło: Version One.

Dobrze dobrane metryki, które zostaną użyte we właściwym kontekście, powinny motywować organizację i poszczególne zespoły do kontynuowania przemian. Kolejny wykres (rys. 1.5) przedstawia kryteria wskazane przez respondentów ankiety Version One jako mierniki sukcesu. Informacje tu przedstawione pokazują raczej wysokopoziomowe kryteria sukcesu. Rzeczywiste, ustalane w danej organizacji, kryteria sukcesu powinny być SMART[3]. Warto nadmienić, że dostarczanie projektu na czas, wysoka wartość biznesowa, zadowolenie klientów/użytkowników końcowych oraz ogólna jakość produktu od wielu lat są niezmiennymi kryteriami sukcesu respondentów ankiety, wymieniają się tylko kolejnością miejsc.

Kolejną informacją godną uwagi i dopełniającą całokształt niezbędnych informacji jest aktualny podział „tortu Agile” – przedstawiający popularność obecnych na rynku metod i podejść zwinnych w ujęciu globalnym.

Dla niektórych czytelników będzie to pewnym zaskoczeniem, ale jednoznacznie widać, że niezmiennie prym wśród wszystkich podejść zwinnych od wielu lat wiedzie Scrum. Scrum wspólnie z wszystkimi swoimi hybrydami (głównie z XP i Kanbanem) osiąga wynik 76%, daleko w tyle pozostawiając inne konkurencyjne podejścia. Z badania wynika, że mocno rozwijającym się podejściem jest lekki Kanban, oparty wyłącznie na trzech prostych zasadach:

• wizualizacji pracy w postaci tablicy (fizycznej lub elektronicznej) – na której w każdym momencie widać aktualny status prac;

• limitowaniu pracy w toku (work in progress, WIP) – reguluje poziom skupienia osób operacyjnych wyłącznie na kilku, przykładowo 2–3, przypisanych zadaniach i nie pozwala rozpoczynać nowych, jeśli aktualne nie zostaną zakończone;

• pomiarze czasu, ile zajmie praca nad każdym zadaniem w określonej kolumnie – dzięki tej informacji zespół jednoznacznie wie, które wymagania generują opóźnienia, pozwala przyjrzeć się im, usuwać potencjalne wąskie gardła i wesprzeć naukę radzenia sobie z podobnymi kłopotami w przyszłości.

Rysunek 1.5. Mierniki sukcesu transformacji zwinnych

Źródło: Version One.

Rysunek 1.6. Zasięg wszystkich podejść zwinnych

Źródło: Version One.

Kontekst zarządzania jakością

Przybliżyliśmy informacje na temat potrzeb związanych z transformacjami organizacji. Przyjrzyjmy się zatem bliżej zagadnieniom zarządzania jakością i procesu testowania. Wiele procesów w tradycyjnym modelu zarządzania projektami nie da się łatwo transformować, ponieważ są „ciężkie” w swojej charakterystyce, wymagają określonej daty początku i końca prac, skrupulatnego dokumentowania przebiegu prac, formalnego procesu rejestracji błędów itd. Transformując podejście do pracy, każda organizacja zrobi to z pewnością w nieco inny sposób, bazując na swojej specyfice działalności i potrzebach biznesowych. Część klasycznych procesów zapewne uda się przeobrazić od razu, inne będą stopniowo zastępowane w drodze nieustannej poprawy, a część zaniknie całkowicie dopiero po pewnym czasie. Ogólnie chodzi o to, aby dzięki empirycznym usprawnieniom stworzyć nowe, zadowalające status quo.

Jedną z najważniejszych zmian w nowym modelu to również konieczność zmiany mentalności całej organizacji, a przez to również zespołów wytwórczych. Mamy tu na myśli pełną świadomość i odpowiedzialność zbiorową zespołu za dostarczaną do klienta wartość. Zmiana ta wiąże się bardzo mocno z przeświadczeniem, że za jakość naszego produktu nie odpowiada już tylko wybrana grupa ludzi (testerzy czy inne osoby czasem zmuszone do egzekucji procesów zarządzania jakością i testowania), ale cały zespół lub wręcz cała organizacja. Idąc dalej tym tropem – każdy członek z osobna musi na co dzień dokładać wszelkich starań, aby jakość produktu była na najwyższym poziomie i aby unikać „pójścia na skróty”, kiedy tylko coś nie idzie pomyślnie. W kontekście testowania, przejście na metody zwinne oznacza fundamentalną zmianę względem podejścia klasycznego, gdzie faza testów nie jest procesem ciągłym, a wydzielonym, ograniczonym w harmonogramie etapem prac. Ponadto faza testowania w podejściu klasycznym nie zawsze bywa traktowana z właściwą starannością. Często bywa skracana kosztem przedłużania się fazy implementacji wymagań i poprawek błędów z niej wynikających. Może się zdarzyć, że klient będzie pierwszym testerem dostarczonego produktu.

Przyglądając się bliżej kontekstowi zarządzania jakością w projektach zwinnych, można odnieść wrażenie, że prawdopodobnie będzie on mniej formalny (niewymagający skomplikowanego planowania z góry, tj. rygorystycznych polityk jakości, planów testów, sztywnych dat rozpoczęcia i zakończenia prac itp). Tak jak wspominaliśmy wcześniej, podejścia zwinne najczęściej nie definiują metod i procesów zarządzania jakością, pozostawiając decyzję o wyborze sposobów zapewnienia jakości zespołom wytwórczym. Mimo to pewne aspekty zarządzania jakością niezależnie od wybranego modelu pracy zawsze muszą być jasne. Z pewnością zaliczają się do nich następujące procesy:

• planowanie czynności zapewniania jakości i testowania;

• pomiar postępu prac;

• proces zgłaszania i naprawy defektów.

Oczywiście nowo wprowadzane lub modyfikowane procesy powinny pozwalać szybko i z dbałością o jakość dostarczać rozwiązania do klientów. Może się również pojawić potrzeba dostosowania naszego podejścia do już istniejących modeli jakości obowiązujących w organizacji. Takim przykładem są banki, które podlegają jurysdykcji prawa bankowego. Mają obowiązek poddawać się kontrolom regulatorów rynku i audytom instytucji nadzoru finansowego (w przypadku Polski to przede wszystkim Komisja Nadzoru Finansowego). Na konkretne pytania audytora o nową wersję oprogramowania członkowie zespołu muszą być w stanie bez wahania udzielić odpowiedzi: pokazać co, kiedy i jak było testowane. Na pierwszy rzut oka nie do końca wygląda to lekko i zwinnie. Należy uczciwie przyznać, iż specyfika obszaru biznesowego (bankowości w tym przypadku) może wymagać wysiłku wynikającego z konieczności zapewnienia dodatkowych procedur po stronie obszaru zapewniania jakości czy potrzeby zbierania danych historycznych. Jest to bardzo istotne, powtórzmy więc: zapewnianie jakości w projektach zwinnych jest odpowiedzialnością całego zespołu bez wyjątków.

Planowanie czynności zapewniania jakości i testowania

W tradycyjnym podejściu zarządzania jakością pierwsze skrzypce grały dokumenty polityk, strategii jakości oraz plany testów. To wokół grupy tych dokumentów kręciło się życie testerów, kierownika testów oraz pośrednio deweloperów. One definiowały wysokopoziomowe style pracy, podejścia i strategie jakości, mając przełożenie na cele kampanii testowych w ramach poszczególnych planów testów. Opisywały ze szczegółami proces oraz podejście do testów, zakres prac, zasoby oraz wysiłek, jaki będzie potrzebny, aby wykonać plan, definicje środowisk testowych oraz narzędzi wspierających. Uogólniając, były wśród tych dokumentów zawarte informacje, które pozwalały zrozumieć biznesowym interesariuszom projektu, co właściwie będzie się działo podczas etapu kontroli jakości i testowania oraz w jaki sposób kierownik testów zaplanował w harmonogramie przeprowadzić poszczególne prace. Wartością planu testów była identyfikacja potencjalnego momentu rozpoczęcia prac przez kryteria wejścia, zakresu prac ustanawiającego z góry kolejność zadań czy potencjalnych ryzyk i problemów mogących stanąć zespołowi w drodze.

Podejście zwinne w kontekście zarządzania jakością również definiuje potrzebę uprzedniego zaplanowania prac, zanim zespoły rzucą się w wir pracy operacyjnej. Jednakże na początku członkowie zespołu muszą zrozumieć kontekst projektu i ogół zadań zarządzania jakością stojących przed nimi. Należy określić i oszacować ryzyka, zależności techniczne, funkcjonalne, wybrać narzędzia, metody pracy, zaplanować strategię automatyzacji itd. Jak podejść do tego tematu?

Odwołując się do podejścia Scrum jako najczęściej wykorzystywanego podejścia zwinnego oraz definiującego go dokumentu „Scrum guide” (przewodnika opisującego szkielet Scrum), przekonamy się, że nie ma w nim wytycznych na temat zbierania wymagań, standardów deweloperskich czy metod zapewniania jakości. Autorzy celowo ukazują szkielet podejścia, pomijając pozostałe obszary, nie ingerując bezpośrednio w metody pracy. Sam dokument przeszedł kilka aktualizacji i możemy mieć pewność, że twórcy Scrum doskonale zdają sobie sprawę z faktu, że każdy zespół zorganizuje się na swój sposób. Nie chcą zabijać kreatywności i elastyczności określaniem sztywnych reguł, sprowadzając wytyczne do absolutnie potrzebnego minimium. To poniekąd argument przemawiający za tym, dlaczego Scrum rośnie w siłę. Dzięki takiemu podejściu członkowie zespołów mają pełną dowolność w doborze oraz modyfikacji metod pracy. Jeśli przygotowanie miniplanu testów ma pomóc konkretnemu zespołowi ustrukturyzować kontekst prac zapewniania jakości, nie będzie ku temu przeszkód. Istotne jest, aby wszyscy członkowie zespołu przystąpili do pracy, wiedząc, co powinni zrobić, to zmniejsza ryzyko pominięcia istotnego aspektu pracy. O sposobie realizacji pracy operacyjnej zespół powinien zdecydować sam w odpowiednim czasie.

Przypisy

[1] https://centrum.jakosci.pl/podstawy-jakosci,rys-historyczny.html (dostęp: 10.04.2017).

[2] http://www.sages.com.pl/blog/w-poszukiwaniu-straconej-jakosci/ (dostęp: 18.08.2017).

[3] https://www.governica.com/S.M.A.R.T (dostęp: 10.05.2017).