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ą
Zarządzanie jakością
1.2. Ustalenie procesu zarządzania jakością
Proces zgłaszania i
1.4. Modele funkcjonowania zespołów – podejście
Pojedyńczy zespół pracujący nad jednym produktem
Wiele zespołów pracujących nad jednym produktem
Inżynieria wymagań w projektach
2.1. Wprowadzenie do inżynierii wymagań
Zadania i czynności inżynierii wymagań
powiązań
2.2. Interesariusze – z kim i dla kogo?
Wizja produktu
2.3. Metody oraz formy pozyskiwania i dokumentacji wymagań
Historyjki użytkownika
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
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
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
8.1. Koncepcja łańcucha bramek jakości
8.2. Zapobieganie występowaniu problemów
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
• Walidacja produktu pod kątem dostosowania do określonych potrzeb i oczekiwań odbiorców.
Uszczegółowieniem polityki testów jest strategia testów. Strategia testów opisuje ogólne podejście do testów w organizacji i zwykle zawiera opis realizowanych zwyczajowo poziomów testów wraz z kryteriami przejścia między poziomami, typowe techniki i narzędzia oraz procedury wykorzystywane w procesie testowym, ze szczególnym uwzględnieniem wskazania sposobu, w jaki środki te mają łagodzić typowe ryzyka produktowe.
Polityka i strategia testów wyznaczają ogólne cele i ramy procesów testowych, są więc pomocne przy opracowywaniu koncepcji ogólnego procesu testowego, realizowanego na poziomie całej organizacji.
Przyjrzyjmy się zatem poszczególnym elementom strategii testowej.
3.3. Poziomy testów
Pojęcie weryfikacji i walidacji
Tematu poziomów testów nie sposób wyjaśnić bez przypomnienia koncepcji jednych z podstawowych elementów zarządzania jakością oprogramowania: weryfikacji i walidacji (V&V, verification and validation). Zgodnie z CMMI® walidacja sprawdza, czy produkt lub jego elementy (w tym specyfikacja) spełnia zamierzone zastosowanie produktu, jeśli umieści się go w docelowym środowisku, weryfikacja zaś „dostarcza punktów kontrolnych, w których wybrane produkty końcowe lub pośrednie (np. specyfikacje) są sprawdzane pod kątem spełnienia wymagań odnośnie do owych produktów” [CMMI].
Na pierwszy rzut oka pojęcia walidacji i weryfikacji wydają się identyczne, różnicę stanowi kilka istotnych słów:
• Walidacja sprawdza, czy produkt spełnia wymagania konieczne do określonego użycia. Odnosi się do oceny spełnienia oczekiwań interesariuszy, w szczególności docelowych użytkowników w realnych warunkach użycia produktu.
• Weryfikacja natomiast polega na sprawdzeniu, czy w produkcie zaimplementowano określone, zdefiniowane uprzednio wymagania.
Cele weryfikacji i walidacji są w różny sposób realizowane przez określone poziomy testów.
Poziomy testów
Testowaniu można poddawać nie tylko produkt końcowy, lecz także produkty cząstkowe na różnym etapie rozwoju. Przykładem „półproduktu” może być kod źródłowy
czy poszczególne interfejsy, weryfikowane jednostkowo przed pełną integracją systemu. To swoiste zróżnicowanie zakresu testów odzwierciedla koncepcja poziomów testów. Przykładem zastosowania koncepcji poziomów testów jest wykonane czynności weryfikacji dla poszczególnych komponentów rozwiązania (testy jednostkowe) czy też ocena działania produktu jako całości (testy systemowe). Organizacja testów w formie poziomów umożliwia zróżnicowanie celów testowania i systematyczną kontrolę jakości na każdym etapie wytwarzania produktu.
Liczba i definicja poziomów testów różnią się w zależności od źródła, np. SWEBOK© wyróżnia trzy główne poziomy testów – jednostkowe, integracyjne i systemowe – podczas gdy inne modele (np. model V) wyróżniają jeszcze jeden niezbędny poziom –testy akceptacyjne (akceptacji) [SWEBOK].
Przyjrzyjmy się zatem typowym poziomom testów.
Testy jednostkowe (modułowe)
Testy jednostkowe (unit test), inaczej testy programistyczne, skupiają się na weryfikacji działania indywidualnych elementów oprogramowania. Takimi elementami mogą być metody czy klasy, poddawane testom w izolacji od pozostałych elementów produktu. Celem testów modułowych jest sprawdzenie działania poszczególnych składników systemu bez „szumów komunikacyjnych”, czyli niezależnie od innych składników produktu. Ten poziom testów zwykle wymaga dostępu do kodu źródłowego, co powoduje, iż najczęściej wykonywany jest przez osoby znające języki programowania. Te testy są zwykle w pełni zautomatyzowane oraz ich realizacja jest wspierana przez narzędzia.
Testy integracji
Testy integracji/integracyjne (integration test) weryfikują komunikację między komponentami oprogramowania, np. poszczególnymi funkcjami, modułami czy nawet systemami. Zazwyczaj testy te są wykonywane po testach jednostkowych indywidualnych modułów lub po testach systemowych – jeśli integracja dotyczy systemów.
Sama integracja poszczególnych elementów może przebiegać według kilku podejść. Klasyczne podejścia do testowania integracyjnego zawierają m.in. podejście zstępujące (top-down) oraz wstępujące (bottom-up), podczas gdy nowoczesne strategie integracji opierają się na architekturze (technicznej lub biznesowej) – co przekłada się na integrację komponentów lub podsystemów na podstawie uprzednio zidentyfikowanych wątków (czy procesów) funkcjonalnych. Niemal w każdym przypadku rekomendowaną strategią integracji jest podejście przyrostowe umożliwiające minimalizację ryzyka i łatwiejszą identyfikacji źródeł potencjalnych usterek.
Testy systemowe
Testowanie systemowe (system test) można określić jako weryfikację zachowania całego systemu. Testy te realizowane są zwykle wtedy, gdy dostępny jest już cały produkt
Jeśli do poprawnego wyświetlania strony na wielu przeglądarkach dochodzi równoległa potrzeba wsparcia wielu urządzeń dostępowych (np. tabletów i smartfonów), wówczas rozwiązaniem może okazać się konieczność zastosowania responsywnego podejścia do projektowania stron www (RWD, responsive web design), przy którym układ i wygląd strony sam dostosowuje się do ekranów o różnych rozdzielczościach, jednocześnie ciągle zachowując spójność serwisu.
6.1. Retrospekcja postępu prac
Każdy, nawet dobrze zgrany i wyśmienicie współpracujący zespół zwinny powinien nieustannie dążyć do usprawnień – na tym m.in. polega zwinność. Oczywiście jest to proces i opiera się na wielokrotnym ulepszaniu metod wytwórczych, narzędzi, stosowanych praktyk i technik: tworzenia produktu, współpracy, komunikacji, zapewniania jakości czy również samych siebie.
Czym jest retrospekcja?
W iteracyjno-inkrementalnym modelu rozwoju oprogramowania retrospekcja spełnia istotną rolę. To spotkanie w regularnych odstępach czasu, gromadzące wszystkie osoby zaangażowane w projekt celem dokonania przeglądu wydarzeń i nauki z doświadczeń zebranych podczas tego czasu. Przykładowy czas trwania iteracji w Scrum wynosi od 1 tygodnia do 1 miesiąca kalendarzowego. Spotykanie się całym zespołem w regularnych odstępach czasu i rozmowa na temat usprawnień jest ważne, ponieważ nikt z zespołu nie zna całej historii przebiegu iteracji. Każdy członek zespołu przynosi na spotkanie swój fragment. Zestawione razem dają obraz całości i pozwalają zespołowi rozpocząć konstruktywną dyskusję w celu poszukiwania nauki na przyszłość.
Spotkanie najczęściej odbywa się zaraz po przeglądzie funkcjonalnym i zebraniu informacji zwrotnej od właściciela biznesowego produktu oraz innych interesariuszy biznesowych (w tym klientów oraz użytkowników) na temat rezultatów iteracji. Jest to właściwy moment, ponieważ zespół posiada w tym momencie wiedzę o wszystkich aspektach zakończonej iteracji, włączając w to proces wytwórczy, współpracę zespołu oraz, co najważniejsze, stopień zadowolenia klienta. Mając te informacje, zespół powinien wspólnie wskazać miejsca w procesie wytwórczym, w których można zastosować usprawnienia lub pokusić się o eksperymenty.
Co równie istotne, zespół powinien także wskazać praktyki, które powinny być kontynuowane. To forma dowartościowania zespołu i pokazania, że była również pozytywna strona pracy i nie wszystko trzeba poprawiać.
Proces udanej retrospekcji
Retrospekcja jest spotkaniem wewnętrznym, gdzie za każdym razem diagnozy dokonuje cały zespół, w Scrum włączając w to właściciela produktu i scrum mastera. Aby
Rysunek 6.17. 8 kroków udanej retrospekcji
Źródło: [Derby, Larsen].
spotkanie było efektywne warto zamknąć je w ograniczone ramy czasowe (timebox). Z psychologicznego punktu widzenia to ważne, ponieważ sprawia, że zespół od początku spotkania naturalnie będzie poruszał najważniejsze i najistotniejsze rzeczy, podążając ku tym mniej istotnym w dalszym czasie.
Spotkanie powinno się rozpocząć od krótkiej rozgrzewki intelektualnej, która pobudzi wszystkich do kreatywnego myślenia. Może to mieć formę krótkiej zabawy lub gry. Po takim krótkim wstępie zespół od razu przechodzi do konkretnych, istotnych dla wszystkich punktów oraz zbierania informacji. Każda osoba ma prawo się wypowiedzieć, dokładnie opisując swój punkt widzenia. Zespół ma ponadto możliwość wyboru sposobu przekazywania informacji zwrotnej. W zależności od zastosowanej techniki spotkanie może przyjąć formę anonimowego zbierania informacji, wzajemnej dyskusji, pracy wspólnej wykorzystującej materiały biurowe czy narzędzia. Zebrane informacje należy pogrupować, podzielić na kategorie i zdecydować, co zespół chce dalej z danym zagadnieniem zrobić. Na koniec spotkania zespół wspólnie dokonuje wyboru kilku (najczęściej 1–3) najważniejszych usprawnień do zrealizowania w trakcie kolejnej iteracji. Decyzje o wyborze usprawnień podejmowane są przykładowo podczas wspólnego głosowania (np. głosowanie kropkami).
Techniki atrakcyjnej retrospekcji
Aby spotkanie dobrze wypełniało swoje zadanie, powinno się odbywać regularnie. Niemniej jednak po pewnym czasie może się zakraść rutyna, która zniechęci zespół do aktywnego udziału w spotkaniu. Osoby organizujące spotkanie powinny dbać o to, aby za każdym razem było ono atrakcyjne i efektywne, cały czas interesujące. Warto zwrócić uwagę również na to, że spotkanie w nowym zespole będzie wyglądało inaczej niż to realizowane w zespole pracującym wspólnie od wielu iteracji. Są to istotne aspekty, które trzeba wziąć pod uwagę, podejmując się organizacji retrospekcji. Chcielibyśmy
będzie charyzma inspirowania i właściwa postawa. Taka osoba musi się stale doskonalić, aby na bieżąco nadążać za rynkiem oraz oczekiwaniami organizacji. Nie będzie bezzasadna tu teza: jeśli się nie rozwijasz, to stoisz w miejscu, a rynek nigdy nie stoi. Ponadto ewangelista jest kimś, kto może wręcz wyprzedzać trendy i dzięki temu zasilać organizację nowymi ideami. Aktualnie coraz więcej osób, również na polskim rynku, mieni się tytułami ewangelistów, jest to nowy trend, który niewątpliwie wypada zauważyć. Według nas, jest również miejsce dla ewangelistów zapewniania jakości.
Zwinne gildie.
Model Spotify
Historycznie termin gildii kojarzy się ze średniowiecznymi stowarzyszeniami rzemieślników i kupców, którzy tworzyli tego typu organizacje w celu efektywnej walki o własne prawa czy wypracowanie jednego mocnego przekazu w walce o rozwiązania spełniające potrzeby członków gildii. W ostatnich latach termin ponownie zyskuje na znaczeniu za sprawą kilku dużych firm i ich unikatowego podejścia do modelu transformacji Agile. Za jednego z pionierów tego typu rozwiązania uznaje się szwedzką firmę Spotify.
Zdefiniujmy na nowo pojęcie gildii. Jest to grupa osób o podobnych profilach zawodowych w ramach jednej organizacji. Osoby te są zdecentralizowane, na co dzień pracują we własnych zespołach, a spotykają się razem z pewną częstotliwością w celu omówienia konkretnych tematów, problemów, podejść, praktyk oraz wypracowania wspólnych rozwiązań. Różnica między gildią a zespołem polega na tym, że gildie to zespoły całkowicie wirtualne. Ich członkowie na co dzień pracują w ramach własnych zespołów i realizują ich cele, natomiast od czasu do czasu spotykają się celem poprawy warunków czy skuteczności pracy. Model decentralizacji sprawia, że położenie geograficzne nie odgrywa tutaj prawie żadnej roli.
Większość zwinnych organizacji (zwłaszcza tych dużych, które posiadają wiele zespołów i praktykują już skalowanie Agile, np. Apple, Netflix, Spotify) posiada gildie zajmujące się określonymi dziedzinami czy kompetencjami. Dzięki takiej organizacji pracy można powołać do istnienia nawet kilka gildii kompetencyjnych – gildie mogą być przykładowo odpowiedzialne za następujące obszary:
• architekturę produktów;
• standardy deweloperskie;
• zapewnianie jakości;
• ogólnie pojęte narzędzia;
• doświadczenia użytkownika itd.
Pomysł gildii można wcielać w życie już w obrębie kilku zespołów, w których występują te same role. W tak wydzielonych grupach pojawią się szybko konkretne potrzeby, m.in. dzielenia się wiedzą, pytania o sposoby użycia pewnych narzędzi i praktycznych rozwiązań problemów, sugestie oparte na doświadczeniu, propozycje eksperymentów.
Rysunek 9.2. Podział organizacji na wirtualne zespoły kompetencyjne Źródło: http://www.full-stackAgile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/ (dostęp: 12.08.2017).
Gildie dzięki swojej unikatowej budowie zyskują przewagę nad standardowym zespołem. Zebranie ludzi o tych samych lub zbliżonych do siebie kompetencjach pomoże w szybkim uzyskaniu efektu synergii. Poza celami osobistymi, realizowanymi przez poszczególnych członków gildii, te same osoby w ramach wirtualnych zespołów specjalistów zyskują szerszą perspektywę. Widzą, jak misja danej gildii (np. zapewnianie jakości) i cele wyznaczone przez gildie są realizowane oraz jak wpływa to na zespoły operacyjnie. Formując gildie, nie należy zapominać o określeniu wspólnej misji działania, swoistego motta, które powinno przyświecać wszystkim jej członkom i przypominać przy okazji każdego spotkania, po co to robią. Dodatkowo, aby układ wirtualnego zespołu spotykającego się regularnie był wydajny, potrzebna jest jedna osoba, która będzie pełniła funkcję nadrzędną w stosunku do pozostałych – taką osobę możemy nazwać liderem lub mistrzem gildii. Lider będzie odpowiedzialny za organizację prac oraz śledzenie postępów. Gilde dzięki zebraniu w swoich szeregach osób odpowiedzialnych za te same obszary zapewniają spójność wizji określonych prac i działań – każdy pomysł jest poddawany ocenie członków gildii celem wypracowania wspólnej decyzji. W ten sposób można budować, weryfikować i ulepszać przyjęte strategie organizacji. Organizacja gildii znacznie ułatwia pracę nad projektami centralnymi, infrastrukturą czy narzędziami wykorzystywanymi szeroko w organizacji.