Reqmagazyn wydanie 5 by Monika Perendyk

N r 5 (2/2016)

REQ

m a g a z y n

Zmiany

na rynku pracy

a nowe umowy

Weryfikacja Wymagań

Na Styku Biznesu

D os t ę p n o ś ć -

nie tylko

d l a n i e p e ł n os p r a w n y c h

zwinnym zbieraniu wymagań przy użyciu języka

inżynieria wymagań

inżynieria oprogramowania

Gherkin

user experience

zarządzanie projektami

prawo w

procesy biznesowe

Szanowni Państwo To już kolejny numer magazynu, na łamach którego poszukujemy wspólnie z ekspertami odpowiedzi na nurtujące pytania z pogranicza biznesu i IT. Bo czy choć raz nie zastanawialiśmy się w jaki sposób opisywać wymagania, aby były one czytelne i zrozumiałe dla odbiorcy? Jakich narzędzi użyć aby było to efektywne? O swoich doświadczeniach w tym temacie opowiada Łukasz Nowacki, który przybliża nam język Gherkin. W momencie, gdy etap identyfikacji wymagań mamy już za sobą stoimy przed dylematem ważności wymagań. Metody umożliwiające ustawienie priorytetów wymagań i funkcji opisane zostały przez Ewę Brzeską w cyklu artykułów: „Na styku biznesu i IT”. W tym numerze nie zabrakło również artykułów związanych z tworzeniem intuicyjnych rozwiązań dla Klientów, czy też case study rozwiązania dla rejestrowania czasu pracy w notacji EBNF. Serdecznie polecamy również artykuł Radosława Smilgina, który porusza ważny temat umowy w IT.

Miłego czytania

Monika Perendyk Prezes Stowarzyszenia Inżynierii Wymagań Redaktor Naczelna

REDAKCJA Opracowanie i redakcja: Redaktor naczelna: Monika Perendyk Zespół redakcyjny: Włodzimierz Dąbrowski Artur Kiełbowicz Rafał Stańczak Marek Zawadzki Korekta: Ewa Brzeska Projekt graficzny i skład: Dagmara Zawada-Żark

Prawa autorskie

Wszystkie opublikowane artykuły są objęte prawem autorskim autora lub przedsiębiorstwa. Wykorzystywanie w innych publikacjach, kopiowanie lub modyfikowanie zawartości artykułu bez pisemnego upoważnienia autora jest zabronione.

Facebook

http://www.facebook.com/reqmagazyn

Reklama

kontakt@reqmagazyn.pl

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl

Zdjęcia

siw.org.pl

między

a IT

warsztaty seminarium spotkania

biznesem

analiza systemowa zarządzanie projektami BPMN UML analiza biznesowa testy akceptacyjne BDD

architektura korporacyjna

zarządzanie procesami biznesowymi FDD modelowanie

ATDD

Treści

Spis

Słowo wstępu

Inżynieria Wymagań Jarosław Wilk Weryfikacja wymagań

Inżynieria Oprogramowania Ewa Brzeska Na styku biznesu i IT: Priorytetyzowanie wymagań i funkcji

User Experience Dorota Orzeszek Dostępność - nie tylko dla niepełnosprawnych

Prawo w IT Radosław Smilgin Zmiany na rynku pracy a nowe umowy IT

Wywiad

Łukasz Nowacki O zwinnym zbieraniu wymagań przy użyciu języka Gherkin

Jarosław Wilk

Inżynieria Wymagań

Wprowadzanie danych o czasie pracy

Wstęp

spółczesne wymagania prawne w zakresie planowania i rejestrowania czasu pracy pracowników narzucają na pracodawcę obowiązek:

• tworzenia rozkładu czasu pracy (planowanie) Pracodawcy mają obowiązek układania i publiw formie grafików czasu pracy, kowania grafików czasu pracy • prowadzenia ewidencji czasu pracy (rejestrowa- Grafiki imienne dla każdego pracownika muszą nie) w formie imiennych kart czasu pracy. przygotowywać i z wyprzedzeniem publikować pracodawcy, u których pracę świadczy się w nieCzas pracy to czas, w którym pracownik pozostaje dziele i święta oraz terminy dni wolnych nie pokryw dyspozycji pracodawcy w miejscu wyznaczonym wają się z dniami wolnymi wynikającymi z kalendado wykonywania pracy. rza. Wiąże się to ze stosowaniem pracy zmianowej oraz równoważnych systemów czasu pracy.

Planowanie czasu pracy

Jeżeli soboty i niedziele są dniami wolnymi, a w pozostałe dni pracuje się od poniedziałku do piątku w stałych godzinach, to nie ma obowiązku układania imiennych grafików czasu pracy. Mówiąc bardziej precyzyjnie u pracodawców stosujących stały rozkład czasu pracy wystarczą odpowiednie postanowienia zapisane w regulaminie pracy dotyczące jej organizacji (grafik czasu pracy zapisany na stałe). W zasadzie wszyscy pracodawcy mają obowiązek z wyprzedzeniem zaplanować czas pracy pracownikom.

Zalecaną praktyką jest rozpisywanie imiennych grafików czasu pracy na przyjęty okres rozliczeniowy dla wszystkich pracowników. Jeżeli takie mamy to sytuacje wyjątkowe wynikające na przykład z przewidywanego zwiększonego obciążenia pracą obsługiwane są w sposób przejrzysty dla pracodawcy, pracownika i służb kontrolnych.

Ewidencja czasu pracy Ewidencję czasu pracy należy tak wypełnić, aby prawidłowo wyliczyć i wypłacić wynagrodzenie za pracę oraz wyznaczyć inne świadczenia związane z pracą. Szczególnie istotne jest wyróżnienie godzin, których przepracowanie daje pracownikowi

prawo do dodatkowego wynagrodzenia i innych Konsekwencje nieprawidłowego świadczeń związanych z pracą lub czasem wolnym. Prawo do czasu wolnego to rekompensata planowania i ewidencjonowania polegająca na konieczności oddania dnia wolneczasu pracy go od pracy za pracę w niedzielę, święta oraz za pracę w „sobotę” (dni wolne wynikające z prze- Prawidłowe gospodarowanie czasem pracy pracownika polega na właściwym ustalaniu wynaciętnie pięciodniowego tygodnia pracy). grodzenia za pracę, udzieleniu prawidłowej liczby Obowiązek ewidencjonowania czasu pracy pra- dni wolnych oraz wyznaczeniu odpowiedniej ilości cowników nakłada na pracodawców art. 149 par. godzin odpoczynku. Ewentualne roszczenia o na1 kodeksu pracy. Z treści par. 2 tego artykułu wy- leżne wynagrodzenie za pracę może być dochonika, iż w stosunku do pracowników objętych sys- dzone: temem zadaniowego czasu pracy, pracowników zarządzających w imieniu pracodawcy zakładem • przez pracowników przed sądem pracy w wyniku pracy oraz pracowników otrzymujących ryczałt za złożenia pozwu pracownika do sądu pracy, pracę w godzinach nadliczbowych lub w porze • w wyniku działania inspektora pracy w wyniku nocnej, pracodawca nie ma obowiązku ewidenwydania decyzji administracyjnej – nakazu płacocjonowania godzin pracy. wego w zakresie wypłaty należnego wynagrodzenia za pracę. Liczba dni wolnych weryfikowana jest przez inspektora pracy w czasie dokonywania przez niego czynności kontrolnych. Udzielenie zbyt małej liczby dni wolnych oraz zbyt małej ilości godzin odpoczynku jest wykroczeniem przeciwko prawom pracownika zagrożonym karą grzywny.

Dla pracowników należy prowadzić imienną ewidencję czasu pracy. Zgodnie z art. 281 kodeksu pracy, naruszanie przepisów o czasie pracy lub nieprowadzenie ewidenEwidencjonowanie czasu pracy ma cel prawny, cji czasu pracy jest wykroczeniem przeciwko praokreślony art. 149 kodeksu pracy oraz precyzyjnie wom pracownika, co grozi karą grzywny w ramach ustaloną przez przepisy treść. postępowania mandatowego. Jeżeli ewidencja Jeżeli w przepisach wewnątrzzakładowych (ukła- czasu pracy mogła zostać sfałszowana, inspektor dzie zbiorowym pracy i regulaminie wynagradza- pracy może wystąpić do prokuratora z wnioskiem nia) przewidziane są specjalne dodatki uzależnio- o podejrzenie popełniania przestępstwa. ne od czasu, w którym praca jest przewidziana, ewidencja powinna zawierać także dodatkowe informacje. W trakcie trwania okresu rozliczeniowego weryfikacji podlegać mogą godziny nadliczbowe z powodu przekroczenia dobowej normy czasu pracy, praca w porze nocnej, dyżury, urlopy oraz usprawiedliwione i nieusprawiedliwione nieobecności, dlatego wszystkie takie informacje powinny być przez pracodawców rejestrowane na bieżąco.

Idea szybkiego wprowadzania danych o czasie pracy Obowiązek prowadzenia ewidencji czasu pracy spoczywa na pracodawcy oraz osobach działających w jego imieniu. Ewidencja czasu pracy powinna być prowadzona w formie imiennej karty pracownika. Do prawidłowego wyliczenia wynagrodzenia za pracę oraz wyznaczenia innych świadczeń wymagane są prawidłowo wprowadzone: rozkład czasu, ewidencja czasu pracy.

Idea elektronicznego zarządzania danymi o czasie pracy Reguły logiczne zastosowane w przepisach dotyczących czasu pracy są skomplikowane. Dodatkową trudnością w efektywnym tworzeniu narzędzi komputerowych jest częsta zmiana przepisów prawa pracy oraz duże konsekwencje prawne nieprawidłowego wprowadzenia danych o czasie pracy. Opracowano metodę szybkiego wprowadzania danych i wprowadzania aktualizacji oprogramowania. Rysunek 1 przedstawia ideę wprowadzania danych o czasie pracy w następujących krokach:

Przepisy nie regulują formy, w jakiej mają być prowadzone dane, więc prowadzenie jej w formie elektronicznej jest dopuszczalne. Dane wprowadzane przez pracowników mogą mieć charakter pomocniczy dla pracodawcy i stanowić podstawę do prowadzenia przez pracodawcę zsynchronizo- 1. Metoda wprowadzania. W pierwszym etapie użytkownik wybiera, metodę wprowadzania dawanej z takimi systemami ewidencji czasu pracy. nych.

2. Użytkownicy podstawowi. Użytkownicy o podstawowych umiejętnościach wprowadzają dane za pomocą okienkowego interfejsu graficznego. Prowadzenie ewidencji czasu pracy w formie elektronicznej jest dopuszczalne

a. Interfejs okienkowy. Działanie użytkownika będzie w następnym kroku automatycznie „tłumaczone” na instrukcje języka.

Ewidencja czasu pracy ma charakter jawny. Należy udostępniać karty ewidencji czasu pracy na każde żądanie pracownika oraz upoważnionego do kontroli organu (np. inspektora pracy).

b. Generator instrukcji języka. Użytkownik widzi rezultat swojego działania w postaci wygenerowanych instrukcji języka.

Zgodnie z art. 149 kodeksu pracy, § 8 pkt 1 rozporządzenia Ministra Pracy i Polityki Socjalnej z 28 maja 1996 r. w sprawie zakresu prowadzenia przez pracodawców dokumentacji w sprawach związanych ze stosunkiem pracy oraz sposobu prowadzenia akt osobowych pracownika (Dz.U. z 1996 r. nr 62, poz. 286), forma elektroniczna prowadzenia ewidencji czasu pracy nie zwalnia z obowiązku przechowywania wniosków pracownika o udzielenie mu czasu wolnego w zamian za czas przepracowany w godzinach nadliczbowych. Takie wnioski są zawsze pisemne i w takiej właśnie formie ma obowiązek przechowywać je pracodawca.

3. Użytkownicy zaawansowani. Użytkownicy znający składnię języka wprowadzają dane wykorzystując kompletną składnię języka. a. Wprowadzanie nowych instrukcji. Pisząc kolejne instrukcje samodzielnie, użytkownik nie korzysta ze wsparcia generatora, wprowadza instrukcje bezpośrednio w dedykowanym języku. 4. Zestaw instrukcji do wykonania. Niezależnie od metody utworzenia instrukcji języka, kolejne polecenia są kompletowane, zapamiętywane w historii oraz przygotowane do interpretacji. 5. Parser instrukcji. Instrukcje przygotowane do interpretacji są analizowane składniowo oraz semantycznie.

a. Modyfikacja danych modelu. Jeżeli instrukSkładnia języka cje języka zostały poprawnie zinterpretowane, następuje modyfikacja danych w modelu lub Do opisu składni języka wykorzystano notację nawet bezpośrednio w bazie danych. EBNF (ang. Extended Backus-Naur Form). Notacja EBNF jest standardem ISO/IEC 14977 przyb. Informacja o błędach. W przypadku wykryjętym przez Międzynarodową Organizację Norcia błędów w instrukcjach języka, niemożliwa malizacyjną (ISO) do opisu języków formalnych, jest modyfikacja modelu danych, użytkownik czyli wyrażenia gramatyki bezkontekstowej. Wiele otrzymuje informację o błędach. współczesnych języków programowania opisuje się za pomocą notacji EBNF. Poniżej podano 1. Metoda wprowadzania przykład opisu wybranego fragmentu języka oraz przykłady jego użycia. W przykładach składni języka użyto znaków:

2. Użytkownicy podstawowi

3. Użytkownicy zaawansowani

2a. Interfejs okienkowy

3a. Wprowadzanie nowych instrukcji

•„ ” do pokazania równoważnego i bardziej zrozumiałego zapisu składni. • „ … ” do pokazania pominiętego nieistotnego fragmentu zapisu składni.

2b. Generator Instrukcji języka

Kolorem czerwonym oznaczono opisywane elementy języka.

4. Zestaw instrukcji do wykonania

Składnia wyrażenia

5. Parser instrukcji 5b. Informacja o błędach 5a. Modyfikacja danych modelu

<expression> <source>;

::=

„=”

<destination> ::= <target> {„,” <target>};

Rys. 1 Idea wprowadzania danych o czasie pracy

Interfejs użytkownika

<source> ::= <multisource> {„,” <multisource>}; <target> ::= „(„ <target> „)” | <cells>;

<multisource> ::= <simplesource> {„*” Rysunek 2 prezentuje implementację opisanej idei <number>}; wprowadzania danych o czasie pracy. Użytkownik <simplesource> ::= „(„ <source> „)” | wykonywał akcje w następującej kolejności: <timeperiod> | <empty>; 1. Wybór dnia 5 (poniedziałek).

<empty> ::= ;

2. Wybór dnia 6 (wtorek).

<number> ::= <digit> {<digit>};

3. Wybór stempla godzin pracy 9:00-17:00.

<digit> ::= „0”|”1”|”2”|”3”|”4”|”5”|” 6”|”7”|”8”|”9”;

4. Automatycznie wygenerowana instrukcja języka 5,6=9-17.

Rys. 2 Interfejs użytkownika do wprowadzania danych o czasie pracy

Zakres dni miesiąca

Wyrażenie

Przykłady

1, 3-5 = … Zbiór „1, 3-5” po 1, 3, 4, lewej stronie jest 5=… docelowym zbiorem zakresów dni.

<cells> ::= <cellrange> | <cellplus> | <cell>;

… = 8-16 Zbiór „8-16” po …= prawej stronie jest 8:00-16:00 źródłowym zbiorem zakresów godzin i zakresów dni.

<cellplus> ::= <cell> „+” <number>;

Wyrażenie

Przykłady

1 = 8:0016:00

<cell>

088 08

Podany jest numer dnia w miesiącu, jako liczba naturalna bez znaku.

8-11 08-11 08, 09, 10, 11

Podany jest numer pierwszego i ostatniego dnia miesiąca. Musi być podany znak separatora „-”.

8+2 08-10 08, 09, 10

Podany jest numer pierwszego dnia miesiąca oraz ilość dni. Musi być podany znak separatora „+”.

Wyrażenie jest przypisaniem źródłowego zakresu dni i godzin do docelowego zakresu dni. Zakresy źródłowy i docelowy rozdziela znak „=”.

<cell> ::= <number>; <cellrange> ::= <cell> „-” <cell>;

Wyrażenie

Przykłady

10:30 08:30 8:30 1:15 01:15

Podana jest godzina oraz minuta, rozdzielone znakiem „ : ”.

08:00 08 8 08:00 8: 08:00

Podana jest tylko godzina, przyjmuje się zerową ilość minut.

:30

00:30

Podana jest tylko ilość minut, przyjmuje się, zerową ilość godzin.

+01:00 +1:00 +1: +01:00 +1 +01:00 +:30 +00:30 -0:30 -00:30

Przed wartością godzin może być podany znak „+” lub „-”, oznacza to, że modyfikujemy czas zwiększając lub zmniejszając go o podaną wartość.

08:30-14:00 8:30-14:00 8-14 08:00-14:00 +8-+8 +08:00-+08:00 -:30--6 -00:30--06:00

Podany jest godzina rozpoczęcia oraz zakończenia. Godzina rozpoczęcia i zakończenia rozdziela znak „-”. Zarówno godzina rozpoczęcia jak i zakończenia może być poprzedzona znakiem „+” lub „-”.

08:308:30808:00+8+08:00-:30-00:30-

Podana jest tylko godzina rozpoczęcia, nie jest podana godzina zakończenia. Po godzinie rozpoczęcia, musi być podany separator „-”. Godzina rozpoczęcia może być poprzedzony znakiem „+” lub „-”

-14:30 -14:30 -11 -11:00 -+6 -+06:00 --:30 --00:30

Podana jest tylko godzina zakończenia, nie jest podana godzina rozpoczęcia. Przed godziną zakończenia, musi być podany znak separatora „-” albo „-”. Godzina zakończenia może być poprzedzona znakiem „+” lub „-”

Nie jest podana ani godzina rozpoczęcia, ani godzina zakończenia. Jest tylko podany znak separatora „-”.

Podawanie czasu <timeperiod> ::= <timerange> | <timefrom> | <timeto> | <timeempty>;

Objaśnienia Instrukcja

Objaśnienia

1-3,6 = (7:15-16)*4

1-3 oznacza dni od 1 do 3, czyli 1, 2, 3

1-3,6 = (7:15-16)*4

<timerange> ::= <timevalue> „-” <timevalue>;

6 oznacza dzień 6 w zestawie dni docelowych

1-3,6 = (7:15-16)*4

<timevalue> ::= {„+” | „-”;} <time>;

1-3,6 oznacza dni 1, 2, 3, 6.

1-3,6 = (7:15-16)*4

7:15-16 oznacza zakres godzin od 7:15 do 16:00

1-3,6 = (7:15-16)*4

*4 oznacza 4-krotne zwielokrotnienie zakresu godzin. Nawias okrągły nie jest konieczny, można zapisać 7:15-16*4.

<timeempty> ::= „-”; <timefrom> ::= <timevalue> „-”; <timeto> ::= „-” <timevalue>;

<time> ::= <timeHHMM> | <timeMM> | <timeHH>; <timeHHMM> ::= <number> „:” <number>; <timeHH> ::= <number> [„:”]; <timeMM> ::= „:” <number>;

Przykłady zastosowania Poniżej zaprezentowano przykłady kompletnych instrukcji oraz wynik ich działania. Dzień Od Do

1 2 3 4 5 6 7 8 9 10

Instrukcja 1-3,6 = (7:15-16)*4

Wynik działania

Podsumowanie Warto zwrócić uwagę, że opisana technika jest wykorzystywana przez twórców systemów operacyjnych. W systemach operacyjnych działania użytkownika tłumaczone są na instrukcje powłoki (ang. shell). Język powłoki jest bardzo silnym językiem, który wyznacza możliwości interakcji systemu z użytkownikiem. Przeniesienie pomysłu wykorzystania poleceń linii komend do tworzenia programów użytkowych jest rzadko stosowane.

Dzień 1 2 3 4 5 6 7 8 9 10 Wady opracowania dedykowanego języka Od 07:15 07:15 07:15 07:15 Do 16:00 16:00 16:00 16:00 Dla wykorzystania zaproponowanej metody wymagane jest, aby parser był kompletny i „pokrył” cały zakres działania użytkownika. Opracowanie dedykowanego języka i zaimplementowanie parsera jest czasochłonne, co przekłada się na większy koszt wytworzenia oprogramowania. Jest to największa niedogodność zaproponowanej metody. Dodatkowa wadą jest „łamanie” wstecznej zgodności przy większych zmianach składni parsera. Wprowadzenie modyfikacji oprogramowania czasami wymaga istotnej przebudowy składni, 12

co może uniemożliwiać uruchomienie poprzednio przez użytkowników. Ilość użytkowników, którzy napisanych i przechowywanych historycznie in- wprowadzali instrukcje za pomocą dedykowanego języka z pominięciem graficznego interfejsu strukcji. okienkowego wynosiła około 20%. Oznacza to, Zalety opracowania dedykowanego języka że część użytkowników opanowała posługiwanie się językiem i stosowała te umiejętności w praktyOpracowanie i zaimplementowanie dedykowanece. Największą wydajność użytkownicy uzyskiwali go języka jest znacznie mniej kosztowne, a przez stosując mieszaną metodę wprowadzania danych. to zabiera mniej czasu niż opracowanie kompletNajtrudniejsze operacje były wykonywane stosunego graficznego interfejsu okienkowego. Dlatejąc komendy języka, a pozostałe (łatwiejsze) opego można rozważyć ograniczenie funkcjonalności racje wykonywane były z wykorzystaniem graficzgraficznego interfejsu okienkowego do najczęnego interfejsu okienkowego. ściej wykonywanych operacji. Działania użytkownika wykonywane rzadziej mogą być wykonywane tylko za pomocą komend języka. Takie podejście może nawet zmniejszyć koszt wytworzenia oprogramowania. Oczywiście użytkownicy powinni zostać przeszkoleni i nabyć umiejętność posługiwania się komendami języka. Stosowanie języka umożliwia bardzo szybkie wykonanie skomplikowanych operacji, które przy użyciu interfejsu okienkowego są pracochłonne. Istotną zaletą jest możliwość wykonywania wcześniej napisanych gotowych „skryptów”, które wykonywanie operacji użytkownika na zasadzie przetwarzania wsadowego. Inną ciekawą zaletą jest możliwość łatwego zaimplementowania „cofania” ostatnio wykonanych operacji. Odbywa się to poprzez usuwanie komend z zapamiętanej historii oraz wykonania zmodyfikowanej listy historii komend od ostatnio zapamiętanego stanu danych programu (zdjęcie migawkowe).

Wnioski z wdrożenia dedykowanego języka Opisaną metodę zastosowano z powodzeniem w oprogramowaniu do wprowadzania danych o czasie pracy. Monitorowano wszystkie instrukcje języka, które zostały wprowadzane manualnie

Jarosław Wilk, Partner Zarządzający w firmie Business Data Process, wykładowca Politechniki Warszawskiej Od wielu lat prowadzi międzynarodowe projekty informatyczne udostępniane w modelu SaaS. Obecnie projektuje i nadzoruje wytwarzanie oprogramowania: - optymalizacji procesu przetwarzania kontraktów i faktur kosztowych, - planowania, rejestrowania i rozliczania czasu pracy. 13

Ewa Brzeska

Inżynieria

Oprogramowania

Na styku biznesu i IT

Priorytetyzowanie wymagań i funkcji koszty badania rynku często na początku tworzony jest funkcjonalny prototyp rozwiązania. Jeśli jedrojektowa codzienność to zwykle niewy- nak zakres prototypu nie będzie reprezentatywny starczające zasoby, zbyt krótkie terminy dla planowanego produktu – odpowiedź rynku oraz silne przekonanie klienta, że tylko może być niemiarodajna. Najlepszy prototyp to „wszystko mający” produkt spełni jego tzw. MVP (ang. Minimum Viable Product) – produkt o minimalnej satysfakcjonującej funkcjonalwysokie wymagania. ności, posiadający jednocześnie reprezentatywne Tymczasem nadmierne dodawanie kolejnych cechy produktu docelowego oraz zawierający zefunkcji i tym samym rozbudowa zakresu oprogra- staw kluczowych funkcjonalności (o MVP pisałam mowania wcale nie generuje oczekiwanego efek- szerzej w 3 i 4 numerze REQ Magazyn1 – zaintu „wow”. Co więcej system zbyt przeładowany teresowanych zapraszam serdecznie do lektury). funkcjonalnie staje się często bardziej zawodny, Jak jednak określić zarówno tę początkową klutrudniejszy w użytkowaniu oraz droższy zarówno czową funkcjonalność oprogramowania, jak i zena etapie wytwarzania, jak i późniejszej obsługi. staw funkcji, które powinny być realizowane w koKluczem do powodzenia projektu nie jest bowiem lejnych iteracjach? Jak nadmiernie rozbudowapowiązać wymaganie na funkcjonalność, lecz ak powiązać z wartością, jaką może realizacja kluczowych w y m a g a n i e dostarczyć jego realizawymagań. To dzięki nim z wartością, jaką cja? Z pomocą przychoefekt biznesowy przeddzą nam metody priorysięwzięcia będzie jak naj- może dostarczyć jego realizacja? tetyzowania wymagań. Z pomocą przychodzą nam Pokrótce przedstawię większy. najczęściej stosowane: metody priorytetyzowania… Obecnie to rynek często metodę MoSCoW i modecyduje o ostatecznym del Kano. kształcie produktu i jego zakresie. Zwinne i przyrostowe metodyki tworzenia oprogramowania opierają się na założeniu, że kolejne funkcje oprogra- 1 „Na styku biznesu i IT: Minimum Viable Product” – artymowania są implementowane w odpowiedzi na kuł opublikowany w REQ Magazyn nr 3 konkretne zapotrzebowanie klientów czy użytkow- „Na styku biznesu i IT: MVP a wytwarzanie oprogramowaników oprogramowania. Aby zbadać zapotrze- nia – Case Study” – artykuł opublikowany w REQ Magazyn bowanie, zminimalizować ryzyko oraz ograniczyć nr 4

Wstęp

Rys. 1 Metoda MoSCoW – nadawanie priorytetów wymaganiom

S (Should have – powinno być) – wymaganie, które powinno być zrealizowane w nowej wersji Metoda MoSCoW wywodzi się z DSDM (Dynamic oprogramowania – jest ważne z punktu widzenia System Development Method), jednej ze zwin- interesariuszy, a jego implementacja może przynych metodyk oprogramowania. W metodyce nieść wymierne korzyści, DSDM oprogramowanie tworzone jest w sposób • C (Could have – może być) – wymaganie, które iteracyjny. Przed realizacją każdej pętli iteracji po- może być zrealizowane, jeśli czas i zasoby okażą wstaje lista wymagań, które mają być zrealizowa- się wystarczające. Jest pożądane, ale niekonieczne w tej iteracji wraz z ich priorytetami. Priorytety ne. określane są przy pomocy metody MoSCoW, któ• W (Won’t have – nie będzie) – wymaganie, która wyróżnia następujące kategorie wymagań: re nie będzie realizowane w nowej wersji oprogra• M ( Must have – musi być) – wymaganie musi mowania, ale może być powtórnie rozpatrywane być zrealizowane w nowej wersji oprogramowa- w przyszłości do dostarczenia w kolejnej wernia. Nie zrealizowanie choćby jednej z funkcji sji produktu. przypisanej do tej kategorii powoduje, że oprogramowanie zrealizowane w tej iteracji nie speł- Metoda MoSCoW, nie negując ważności wszystnia założonych kryteriów, albo priorytety zostały kich wymagań, pozwala jednocześnie tak uszeregować wymagania poprzez nadanie im odpoźle oszacowane, wiednich priorytetów, aby jak największy efekt biznesowy został osiągnięty w jak najkrótszym czasie.

Metoda MoSCoW

•

Niezależnie od tego jaką metodyką wytwarzamy oprogramowanie, mamy najczęściej przygotowaną listę zadań, które chcemy wykonać. Nie ma znaczenia, czy będzie to specyfikacja wymagań, czy rejestr produktu - ważne jest, aby znany był zakres prac. Stosowanie metody MoSCoW w praktyce polega na tym, że każdemu wymaganiu, które widnieje na naszej liście przypisujemy jego priorytet realizacyjny w następnej wersji produktu zgodnie z kategoriami M – S – C – W (Rys. 1). Rys. 2 Metoda MoSCoW – idealny rozkład zasobów dla

Wymaganiami, które dla najbliższej iteracji uzy-

realizacji poszczególnych kategorii wymagań

skały status Won’t have w ogóle się nie zajmujemy w bieżącej iteracji produktu – nie angażują one naszych zasobów. Optymalny rozkład zasobów dla realizacji wymagań z pozostałych trzech kategorii M : S : C powinien pozostawać w relacji 60% : 20% : 20 % (Rys. 2). Metoda MoSCoW jest prosta, a jednocześnie wszechstronna. Możemy się nią posługiwać podczas tworzenia nowego produktu czy usługi, dostarczania nowych funkcjonalności do istniejącego rozwiązania, a także podczas realizacji zmian w istniejącym rozwiązaniu. Istotnym jest jednak, aby na etapie określania priorytetów zapewnić sobie ścisłą współpracę z interesariuszami – to klient decyduje, które wymagania mają dla niego wyższy priorytet i z realizacji których funkcji oprogramowania będzie miał większą korzyść biznesową.

ta i eksperta w dziedzinie zarządzania jakością. Podstawowe założenie tego modelu opiera się na twierdzeniu, że nie wszystkie cechy produktu są jednakowo istotne z punktu widzenia klienta. W swoim modelu Kano wyróżnił 5 kategorii funkcji (Rys. 3): 1. Funkcje podstawowe (Must be) – bazowa funkcjonalność produktu, która jest absolutnie obowiązkowa do realizacji; są to funkcje oczywiste, zwykle nie specyfikowane (np. funkcją podstawową telefonu jest to, że można z niego wykonać połączenie telefoniczne). Brak implementacji jakiejkolwiek funkcji podstawowej będzie skutkowało niezadowoleniem klienta.

2. Funkcje jednowymiarowe (One dimensional) – wyspecyfikowane, mierzalne, techniczne. Im wyższy jest stopień ich realizacji, tym większy jest poModel Kano ziom satysfakcji klienta - satysfakcja rośnie wprost Model Kano został opracowany w 1980 roku przez proporcjonalnie do stopnia realizacji tych funkcji. japońskiego profesora Noriaki Kano – konsultan-

Rys. 3 Model Kano – zależność poziomu satysfakcji klienta od funkcjonalności produktu

3. Funkcje atrakcyjne (Attractive) - innowacyjne Model Kano w praktyce i nieoczekiwane, zwiększające atrakcyjność produktu i poziom pozytywnych emocji klienta. Funk- Zastosowanie modelu Kano w praktyce polega na cje tej grupy mogą zadecydować np. o powo- określeniu stosunku interesariuszy do każdej funkdzeniu produktu na rynku i przyciągnąć do niego cji produktu, przy czym ocenie podlega zarówno

Funkcjonalność zaimplementowana

Wymaganie nr x.x

Brak funkcjonalności Podoba mi się

Musi być

Obojętne

Toleruję

Nie lubię

Podoba mi

Funkcja niejedno-

Funkcja atrakcyjna

Funkcja jednowymia-

się

znaczna

rowa

Q Musi być Obojętne Toleruję Nie lubię

Funkcja przeciwna

Funkcja obojętna

Funkcja podstawowa

Funkcja przeciwna

Funkcja obojętna

Funkcja podstawowa

Funkcja przeciwna

Funkcja obojętna

Funkcja podstawowa

Funkcja przeciwna

Funkcja niejedno-

znaczna Q

Tabela 1 Model Kano – interpretacja odpowiedzi jednego badanego na pytania dotyczące jednej badanej funkcji

klientów. Jednak powodzenie to może być krótkookresowe – funkcje z tej grupy z czasem mogą wejść do grupy funkcji obowiązkowych lub jednowymiarowych. Przykładem atraktora, który z czasem stał się funkcją podstawową może być ekran dotykowy w telefonie – jeszcze kilka lat temu był innowacyjny, obecnie praktycznie nie produkuje się telefonów, które są go pozbawione.

implementacja tego wymagania, jak i jego brak. W obu przypadkach możliwa jest jedna z pięciu poniższych odpowiedzi: •

podoba mi się to, lubię to,

•

musi być,

•

jest mi to obojętne,

4. Funkcje obojętne (Indifferent) , których istnie• nie odpowiada mi to, ale toleruję, nie nie wpływa na wzrost satysfakcji klienta, a ich brak nie ma wpływu na poziom ich niezadowole- • nie odpowiada mi to, nie lubię. nia. Odpowiedzi zwykle udzielane są na przygotowa5. Funkcje przeciwne (Reverse) – zestaw funk- nym wcześniej kwestionariuszu ankietowym, gdzie cji, których realizacja spowoduje niezadowolenie każdy z badanych wypowiada się w wyżej podanej klienta, a brak wpłynie na zwiększenie poziomu pięciostopniowej skali jakie odczucia przyniesie jego satysfakcji. Funkcje przeciwne często są nie- mu istnienie danej funkcji w produkcie. Następjednoznaczne, np. dla jednego użytkownika pro- nie badany odpowiada na pytanie, co będzie czuł, duktu jego rozbudowany zakres będzie zaletą, zaś kiedy produkt nie będzie zawierał tej cechy. Możdla innego – wadą, gdyż wraz ze wzrostem funk- liwe przypadki odpowiedzi dla danej funkcji przez cjonalności wzrasta także stopień komplikacji ob- pojedynczego badanego oraz ich interpretację sługi, co może zniechęcać do użytkowania. prezentuje poniższa tabela (Tab. 1): Funkcję uznajemy za: 17

Wymaganie, cecha, funkcjonalność

Liczba głosów w danej kategorii M

Wymaganie 1.1

Wymaganie 1.2

Wymaganie 1.3

Wymaganie 1.4

6 7

Suma głosów

Kategoria wymagania

Tabela 2 Model Kano – zbiorcza interpretacja badań

• podstawową (M), jeśli interesariusz nie lubi jej braku w produkcie i jednocześnie uznaje jej implementację za tolerowaną, obojętną, lub odczuwa, że tak musi być,

Model Kano a zakres funkcjonalny produktu

O poziomie satysfakcji interesariuszy (klienta, użyt• atrakcyjną (A), jeśli interesariuszowi podo- kowników,…) decyduje przede wszystkim impleba się, że funkcja jest w produkcie i jednocześnie mentacja w produkcie funkcji z pierwszych trzech brak tej funkcji toleruje, jest mu to obojętne lub kategorii modelu Kano. Optymalny docelowy zestaw funkcjonalny produktu (w tym oprogramowauznał, że tak musi być, nia) to taki, w którym zostaną zrealizowane: • jednowymiarową (O), jeśli interesariuszowszystkie funkcje podstawowe, wi podoba się istnienie danej funkcjonalności, • a jednocześnie nie lubi jej braku, • taki zestaw funkcji jednowymiarowych, któ• obojętną (I), jeśli fakt zarówno istnienia tej ry implementacja wiąże się z najlepszym stosunfunkcji w produkcie, jak i jej braku interesariusz kiem poziomu satysfakcji do nakładów poniesiouważa za tolerowany, obojętny, lub uzna, że tak nych na ich realizację, musi być,

• kilka funkcji atrakcyjnych, które swoją in• przeciwną (R), jeśli brak funkcjonalności nowacyjnością mają dostarczyć ponadprzeciętpodoba się interesariuszowi, a jednocześnie nie nej satysfakcji. lubi, toleruje, jest mu obojętne, lub uznaje, że tak Jeśli jednak budujemy prototyp funkcjonalny, czy może być gdy funkcjonalność jest zaimplemenMVP (Minimum Viable Product) – klucz do okretowana. Podobnie, gdy interesariusz uzna, że nie ślania jego funkcjonalności może być nieco inny. lubi, gdy funkcja zostanie zaimplementowana, ale Na pewno konieczne jest zaimplementowanie jednocześnie toleruje, jest mu to obojętne lub w pierwszej kolejności zestawu funkcji podstawouważa, że tak musi być, gdy funkcji tej w produkwych. I tu teoretycznie moglibyśmy się zatrzymać cie nie ma, w implementacji, przekazać produkt interesariu• wątpliwą (Q), kiedy interesariusz uznał, że szom (np. pierwszym użytkownikom) i poczekać jednakowo podoba mu się zarówno implementa- na ich ocenę naszego rozwiązania. Jednak, czy cja tej funkcji w produkcie, jak i jej brak. Podobnie, tak zbudowane MVP będzie reprezentatywne dla jeśli interesariusz nie lubi występowania tej funkcji pełnego, planowanego produktu? To zależy, jaki produkt planujemy. Jeśli chcielibyśmy np. podbić w produkcie, ale tak samo nie lubi jej braku. rynek odpowiednikiem iPhone dziesięć lat temu Pełne wyniki badania dla badanej grupy interesa- (czyli zanim iPhone ukazał się na rynku), nie byłoby riuszy są następnie opracowywane na kwestiona- wystarczające, gdybyśmy jako MVP stworzyli jedyriuszu zbiorczym. Przykład takiego kwestionariu- nie zwykły telefon. Takie MVP nie było reprezentatywne dla planowanego produktu docelowego. sza prezentuje tabela Tab. 2. Aby MVP było reprezentatywne, konieczne jest 18

czasami zaimplementowanie oprócz funkcji podstawowych, jednej czy kliku funkcji atrakcyjnych, jeśli w atrakcyjności i innowacyjności upatrujemy później siły naszego produktu.

Zakończenie Bez względu na przyjętą metodykę prowadzenia projektu informatycznego, czy metodykę wytwarzania oprogramowania - niemożliwym jest wytworzenie produktu o pełnym przyjętym zakresie w jednej chwili lub w pomijalnie krótkim czasie. Każdy Project oraz Product Manager staje wcześniej czy później przed problemem nadania koniecznych priorytetów prowadzonym pracom oraz określenia, jaka powinna być kolejność realizacji poszczególnych funkcji oprogramowania. Ważne jest także wyznaczenie tych funkcji, których implementację można i należy pominąć, gdyż nie wpłyną one w znaczący sposób na zwiększenie poziomu satysfakcji interesariuszy projektu.

postępowania gwarantuje realizację w pierwszej kolejności tych funkcji oprogramowania, które mają największą wartość biznesową i tym samym pozwala na uzyskanie efektu biznesowego w jak najkrótszym czasie.

Bibliografia Strony internetowe: https://pl.wikipedia.org/wiki/Metoda_MoSCoW [dostęp: 30.09.2016] https://pl.wikipedia.org/wiki/Dynamic_Systems_ Development_Method [dostęp 30.09.2016] https://en.wikipedia.org/wiki/Kano_model stęp: 30.09.2016].

[do-

https://www.interaction-design.org/literature/ article/the-kano-model-a-tool-to-prioritize-the-uZ doświadczenia wiem, że zarówno odpowiednio sers-wants-and-desires [dostęp: 10.10.2016] ustalony zakres produktu, jak i właściwe priorytetyzowanie zadań realizowanych w ramach projektu, to jedne z kluczowych czynników powodzenia projektu informatycznego. Priorytety często zmieniają się podczas prac nad projektem. Funkcjonalność, która jeszcze niedawno została odrzucona w procesie priorytetyzowania, dziś staje się wymaganiem, które musi lub powinno znaleźć się w kolejnej iteracji produktu. Dlatego tak istotny jest ciągły przegląd jeszcze nie zrealizowanych wymagań i ciągła korekta ich priorytetów dokonywana we ścisłej współpracy z biznesem. Taki tryb

Ewa Brzeska, Doświadczony Manager i Konsultant IT. Od 25 lat związana czynnie z branżą informatyczną. W tym czasie uczestniczyła w realizacji wielu projektów, pełniąc rolę analityka, projektanta, architekta i programisty oraz kierownika projektu. Wśród zrealizowanych przez nią projektów są rozwiązania wspomagające zarządzanie różnymi sferami biznesu i produkcji. Ma ponad 15 lat doświadczenia w tworzeniu systemów klasy MES (ang. Manufacturing Execution System) dla energetyki i przemysłu. Zarządza projektami i produktami informatycznymi oraz wytwarzaniem oprogramowania. Zajmuje się konsultingiem i doradztwem IT, wykorzystując przy tym bogate doświadczenie praktyczne oraz wiedzę teoretyczną, zdobytą m.in. w Szkole Głównej Handlowej w Warszawie. W 2009 roku wraz ze wspólnikiem założyła firmę Ebitech, która zajmuje się głównie tworzeniem oprogramowania biznesowego na platformy systemowe Apple: iOS i Mac OS X. Współzałożycielka oraz Członek Zarządu Stowarzyszenia Inżynierii Wymagań. 19

Dorota Orzeszek

UX user experience

Dostępność - nie tylko dla niepełnosprawnych Czym jest dostępność?

ostępność (ang. accessibility) to sposób tworzenia produktów, których mogą używać wszyscy potencjalni użytkownicy - zarówno ci w pełni sprawni jak i osoby o szczególnych potrzebach (np. osoby starsze, niepełnosprawne lub dzieci). Jest to pojęcie podobne do bardziej znanej użyteczności (ang. usability), lecz odnoszące się nie do możliwości wygodnej obsługi założonych funkcjonalności produktu, ale do samej możliwości jego użycia przez wszystkich zainteresowanych.

centruje się raczej na dostosowaniu istniejących rozwiązań do potrzeb użytkowników o specjalnych potrzebach, podczas gdy drugie jest relatywnie nową filozofią projektowania, której celem jest zapewnienie równego dostępu do technologii wszystkim użytkownikom.

Komu to służy?

Powszechnie uważa się, że zapewnienie dostępności produktów i usług informatycznych jest działaniem skierowanym przede wszystkim do osób niepełnosprawnych. Okazuje się jednak, że w rzeczywistości działania te mają także pozytywChoć dostępność jest kluczowa dla użytkowników ny wpływ na dostępność technologii dla dzieci czy o ograniczonej sprawności, warto pamiętać, że osób starszych a często poprawiają też jakość inskutkuje też wygodniejszą i bardziej intuicyjną obsługą produktu dla wszystkich. Innym pojęciem stosowanym w kontekście dostępności jest tzw. projektowanie uniwersalne (ang. universal design). Choć istota dostępności i projektowania uniwersalnego jest taka sama, pierwsze z tych pojęć powstało znacznie wcześniej i kon20

czy niepełnosprawne, które w innym wypadku nie byłyby w stanie skorzystać z naszej oferty są kolejnymi potencjalnymi - i często bardzo wiernymi! - klientami. Choć niepełnosprawni stanowią zwykle niewielki odsetek klienteli, to szybko rosnąca liczba osób starszych jest już znacznie silniejszym argumentem biznesowym. Projektowanie dostępnych produktów pozwala zawczasu przygotować się na nieubłaganie zachodzące zmiany demograficzne, które wcześniej czy później zmuszą wszystkich producentów do podjęcia podobnych działań.

terakcji z produktem dla wszystkich.

Zapewnienie dostępności jest też korzystne dla niedoświadczonych użytkowników, dopiero rozpoczynających korzystanie z danej technologii (np. osób po raz pierwszy sięgających po telefon z ekranem dotykowym). Ponadto, dostosowanie produktu do potrzeb osób niepełnosprawnych może być też korzystne dla użytkowników starszych urządzeń i posiadaczy wolnych łącz internetowych, którzy ze względu na ograniczenia techniczne nie chcą lub nie są w stanie obsługiwać standardowej, przepełnionej multimediami, wersji Już dziś w niektórych przypadkach dostępność aplikacji czy strony internetowej. może być wymagana przepisami prawa lub waRzadko mówi się o tym, że według danych Świa- runkami przetargu. Zarówno w Stanach Zjednotowej Organizacji Zdrowia (WHO) już dziś ok. czonych jak i Unii Europejskiej powstały regulacje 15% ludności świata to osoby niepełnosprawne - dotyczące dostępności produktów i usług infora liczba ta będzie w najbliższych dziesięcioleciach matycznych. Obecnie przepisy te dotyczą wyłączsystematycznie wzrastać wraz ze wzrostem udzia- nie instytucji państwowych, ale należy liczyć się łu osób starszych w globalnej populacji. Z pro- z możliwością stopniowego rozszerzania ich zasięgnoz demograficznych WHO wynika, że do 2050 gu także na sektor prywatny. roku liczba osób powyżej 60 roku życia wzrośnie dwukrotnie. Warto zauważyć, że ci sześćdziesię- Inną korzyścią tworzenia dostępnych produktów ciolatkowie będą osobami urodzonymi w latach jest pozytywny wpływ ogłoszenia takiej decyzji na osiemdziesiątych i dziewięćdziesiątych XX wie- wizerunek firmy. Pozwala to wyróżnić się spośród ku, przyzwyczajonymi do obecności komputerów konkurencji i pokazuje, że nasze przedsiębiorstwo w codziennym życiu i oczekującymi satysfakcjonu- dotrzymuje kroku najlepszym na rynku. jących rozwiązań, które pozwolą im dalej korzystać z nowych technologii. Koszty Trzeba też pamiętać, że u osób starszych często współistnieje kilka różnych niepełnosprawności, co powoduje, że prowizoryczne przystosowanie gotowego produktu do potrzeb tylko jednej, najczęściej występującej w naszej grupie docelowej, niesprawności nie będzie wystarczającym rozwiązaniem.

Inwestowanie w dostępność często postrzegane jest jako drogi luksus, na który mogą sobie pozwolić jedynie największe marki. Rzeczywiście, dostosowanie istniejących już na rynku produktów do potrzeb osób niepełnosprawnych może wymagać znacznych nakładów. Jednak projektowanie nowych produktów z myślą o ich dostępności nie wiąże się z dużymi kosztami ani zmianami procedur organizacji. W praktyce sproKorzyści wadza się do ujęcia dostępności jako dodatkowePierwszą, podstawową korzyścią tworzenia do- go wymagania dla projektu i określenia sposobu stępnych produktów jest zwiększenie grona na- jej ewaluacji (np. jako zgodność produktu z wymoszych potencjalnych użytkowników. Osoby starsze

o s t ę p n o ś ć postrzegana jest jako drogi luksus, ale projektowanie nowych produktów z myślą o dostępności nie wiąże się z dużymi kosztami ani zmianami procedur organizacji.

gami standardu WCAG lub Section 508). Jedyną trudnością w zaprojektowaniu dostępnego produktu lub usługi jest brak wiedzy dotyczącej samej dostępności. Niestety, metody projektowania uniwersalnego nie są powszechnie znane, często nawet wśród projektantów, grafików czy architektów systemów. Zdobycie podstawowej wiedzy na ten temat nie powinno zająć zbyt wiele czasu i nie wymaga uczestnictwa w długotrwałych szkoleniach. Aby znacznie zwiększyć dostępność produktu wystarczy przestrzegać zaledwie kilku podstawowych zasad.

Dobre praktyki Najważniejszą zasadą dostępności jest przewidywalność interfejsu produktu i zapewnienie użytkownikom możliwości łatwego i wygodnego poruszania się po nim. Podstawą do osiągnięcia tego rezultatu jest stworzenie przemyślanej, logicznej architektury informacji, umożliwiającej łatwe zna- lety barw o wymaganym standardem poziomie lezienie poszukiwanej informacji a także jasnego kontrastu). Nie mniej ważne jest unikanie zbyt inschematu nawigacji. tensywnych i rzucających się w oczy wzorów czy obrazów w tle. Graficzny interfejs użytkownika musi być przejrzysty i czytelny, z odpowiednio dużymi elementami Warto wiedzieć, że sam rozmiar czcionki nie jest sterującymi i przestrzeniami między nimi ograni- w przypadku oprogramowania kluczowy, ponieczającymi możliwość przypadkowego wyboru nie- waż osoby niedowidzące zwykle korzystają z odchcianej opcji. Zwiększa to dostępność produktu powiednich rozwiązań umożliwiających powiękdla wszystkich użytkowników, ale jest szczególnie szanie tekstu. ważne dla osób starszych oraz niesprawnych ruTrzecią zasadą pozwalającą na znaczne zwiększechowo. nie dostępności produktu jest użycie tekstów alDrugą ważną kwestią jest widoczność elementów ternatywnych. Ilustracje czy wykresy uzupełnia się interfejsu użytkownika. Podstawowym parame- o takie teksty, aby użytkownicy korzystający z czyttrem jest kontrast pomiędzy tekstem a tłem. Stan- ników ekranowych (np. niewidomi) oraz osoby kodardy dostępności takie jak WCAG 2.0 zalecają rzystające ze starszych technologii (np. tekstowe stosowanie kolorów o współczynniku kontrastu przeglądarki internetowe) lub łącz internetowych na poziomie co najmniej 4.5, ale wartość tę nale- o ograniczonej przepustowości miały dostęp do ży traktować jako absolutne minimum. Mimo to, opisu zawartości grafiki w przypadku, gdy niemożwiele współczesnych interfejsów nie spełnia tego liwe jest jej wyświetlenie. wymagania, np. modne w ostatnich latach biało-błękitne tematy kolorystyczne osiągają wartości Istnieje oczywiście też wiele innych zasad dostępdo ok. 4. W celu obliczenia wartości kontrastu dla ności takich jak rozdzielanie treści od formatowybranych barw projektant lub grafik może posłu- wania, zapewnienie kompatybilności wstecznej żyć się którymś z licznych kalkulatorów kontrastu czy wspomaganie użytkowników podczas obsługi dostępnych online (lub wykorzystać gotowe pa- formularzy, ale podstawową dostępność produk22

cją miejską. Brak tekstów alternatywnych jest dużym problemem dla niewidomych, ale obecność nieprawidłowych lub mylących tekstów jest dla tej grupy równie dezorientująca. Na koniec, warto wspomnieć o tym, że aby interfejs użytkownika był dostępny dla wszystkich musi być napisany prostym językiem. Nie należy więc stosować w komunikatach systemowych zbyt formalnego lub skomplikowanego języka, który może okazać się trudny do zrozumienia dla części odbiorców i tym samym zniechęcić ich do naszego produktu. Nawet w przypadku bardzo zaawansowanych produktów dla specjalistów czy produktów klasy premium, prosty i krótki przekaz zwiększa użyteczność i zadowolenie użytkownika.

tu można osiągnąć stosując trzy omówione powyżej zasady.

Najczęstsze błędy Do najczęściej popełnianych błędów w projektowaniu dostępności oprogramowania należy nieprzemyślana architektura informacji oraz zbyt niski kontrast. Często pojawiają się także inne błędy. Zbyt małe lub zbyt ciasno rozmieszczone elementy interfejsu nie stanowią obecnie dużego problemu w przypadku stron internetowych czy oprogramowania na komputery osobiste, ale dają się we znaki użytkownikom urządzeń mobilnych szczególnie obsługującym telefon jedną ręką, np. w samochodzie lub w trakcie podróży komunika-

Dorota Orzeszek – Researcherka, programistka oraz UX designerka specjalizująca się w dostępności (accessibility) i prototypowaniu innowacyjnych interfejsów użytkownika. Na co dzień zajmuje się badaniem i analizą potrzeb użytkowników, projektowaniem nowoczesnych interfejsów i interakcji (np. interfejsy głosowe, haptyczne czy gestowe) na różne platformy (m.in. urządzenia mobilne, inteligentne telewizory czy rozwiązania IoT), opracowywaniem nowych funkcji i produktów oraz rozwiązań technologicznych wspomagających dostępność systemów. Weryfikuje też użyteczność i dostępnośćistniejących produktów, interakcji i interfejsów oraz prowadzi szkolenia z dostępności. Autorka bloga Inside Accessibility: http://insideaccessibility.blogspot.com. 23

Radosław Smilgin

Prawo w

Zmiany na rynku pracy a umowy IT

becna sytuacja na rynku pracy pokazuje, że umowy cywilnoprawne jak i umowy o pracę są niedostosowane do naszych czasów. Szczególnie dotyka to branże w których wzrost jest największy, najszybszy i te o najlepszych zarobkach do których zaliczam również IT. Czy potrzebna jest zmiana i jakie mogą wyniknąć z tego korzyści?

Zmiany na rynku pracy

dzielnie jeżdżących samochodach już w perspektywie kilku lat, a najbardziej pesymistyczne opinie mówią o 2030 roku. Bez względu na czas wdrożenia technologia ta spowoduje redukcję kierowców ciężarówek, autobusów miejskich, taksówek i wielu innych. W skali samej Polski jest to kilkaset tysięcy ludzi, którzy mogą stracić pracę. Warto podkreślić, że pracodawcy z radością przywitają taką zmianę z przekonaniem, że maszyna, która zastąpi człowieka będzie:

• bardziej niezawodna Maszyny zmieniają rynek pracy już od czasów re• zredukuje liczbę wypadków na drodze i ich wolucji przemysłowej. Istnienie robotów zabieraofiar jących kolejne miejsca pracy jest faktem, a nie śpiewką przyszłości. W Niemczech dzięki technologii na roli pracuje już tylko 2% ludzi, gdzie w Polsce ciągle w tym sektorze pracę znajduje 13 % siły roboczej. Maszyny etapami eliminują lub znacząco ograniczają zatrudnienie w kolejnych zawodach. W publikacji „THE FUTURE OF EMPLOYMENT: HOW SUSCEPTIBLE ARE JOBS TO COMPUTERISATION?” autorzy pokazują jak wiele stanowisk i jak szybko może zostać zastąpionych automatami. Najbliżej nam do rewolucji jaką przyniosą autonomiczne samochody, które mogą wyeliminować praktycznie zawód kierowcy. W technologie te inwestują już wszyscy najwięksi, od uznanych producentów aut takich jak Ford, przez młode gwiazdy takie jak Tesla czy Uber, po giganta internetowego Google. Deklaracje mówią o samo24

• pracować 24h na dobę, 365 dni w tygodniu • łatwiejsza i tańsza do pozyskania (aktualnie na rynku jest deficyt kierowców i trudno ich znaleźć) • łatwiejsza do kontroli i zarządzania • itp.

Nowe modele współpracy z pracownikami

Dziś widmo zastąpienia całej ludzkiej pracy przez roboty nie jest jeszcze namacalne. Jest to przyszłość o jakiej nie chcemy myśleć, albo nie jesteWiele firm spedycyjnych, taksówkarskich czy ko- śmy się w stanie z nią pogodzić. Musimy za to już munikacji miejskiej deklaruje, że z radością kupią teraz próbować adaptować prawo do zmian na autonomiczne pojazdy. Docelowo możemy się rynku pracy jakie przynosi Internet. spodziewać, że duża część prac wykonywanych Polskie prawo nie próbuje nadążyć za zmianami dziś przez ludzi zostanie przejęta przez roboty zachodzącymi na świecie, w tym w dynamicznie albo przez algorytmy. ewoluujących branżach. Przykładów jest wiele poczynając od bezpieczeńW tych okolicznościach ie ma możliwości stwa danych osobostracą oczywiście pracownicy wykonujący aby Ci ludzie, wych, a na e – usługach kończąc. Możemy wziąć prace jakie można zauktórzy znają jednak na warsztat bartomatyzować, ale zyskai akceptują zasady dzo prosty i dotykający ją konstruktorzy maszyn, ich programiści, czy te- podjęli się darmowego wysiłku na wielu przedsiębiorców sterzy, czyli szeroko po- rzecz „pracodawcy” i nie otrzymali problem pracowników z globalnej sieci. Prawo jęta branża nowych tech- umowy i później płatności. pracy w tym temacie nologii i IT. Branża staje jest tak oderwane od więc w bardzo uprzywilejowanej pozycji, ale dodatkowo bardzo odpo- rzeczywistości, że aż zahacza o śmieszność. Przyjwiedzialnej społecznie roli. Ta ewolucja wymaga rzyjmy się temu na prostym przykładzie crowdsozmian prawa, które uwzględni nową sytuację na urcingu czyli pracy wykonywanej przez tzw. osoby z tłumu. W dużym uproszczeniu jest to praca ludzi rynku pracy. wykonywana zdalnie za pośrednictwem komputera. Pracodawca mając proste zadanie do wykonania i chcąc, aby zostało wykonane za możliwie najniższą kwotę może zlecić je tłumowi. Załóżmy, że to zadanie to np. redakcja tekstu czy szybkie tłumaczenie. Do pracodawcy zgłasza się osoba, która wycenia to na 15 minut pracy i chce za to dostać 15 PLN. Aby legalnie zlecić takie zadanie potencjalny „pracodawca” musi poprosić pracownika o wszystkie dane osobowe, podatkowe i wystawić mu umowę o dzieło, aby umowę oficjalnie zgłosić do urzędu. Problem w tym, że oprócz opłat narzuconych na umowę przez rząd, standardowa opłata księgowa za przygotowanie i obsłużenie takiej umowy wynosi… 15 PLN. Nagle więc okazuje się, że „pracodawca” musi pogrążyć się w umowach i zapłacić za pracę więcej niż warta jest sama usługa.

Idąc dalej możemy przyjrzeć się ciekawemu modelowi pay-per-bug, którego celem jest do25

starczanie informacji o jakości oprogramowania, a które realizowane jest jako crowdsourcing. Polega to na tym, że bliżej niesprecyzowanej ilościowo grupie ludzi siedzących przy komputerach i podpiętych do Internetu (nasz tłum) proponujemy wynagrodzenie w wysokości 10 PLN za każdy znaleziony defekt w naszym oprogramowaniu. Wszyscy „pracownicy” wykonują pewną pracę, a zarabiają Ci, którzy naprawdę znajdą defekty. W teorii polskiego prawa pracy z każdą taką osobą należałoby podpisać umowę i każdemu zapłacić. Nie ma możliwości aby Ci ludzie, którzy znają i akceptują zasady podjęli się darmowego wysiłku na rzecz „pracodawcy” i nie otrzymali umowy i później płatności. Sytuacja, w której część osób znajdzie po jednym defekcie jest również trudna, bo przed płatnością każdemu należałoby wystawić umowę o dzieło (jak pisaliśmy księgowa bierze za nią 15 PLN). Te zasady praktycznie zabijają w Polsce niskopłatny crowdsourcing realnie zabierając Polakom pracę. Należy podkreślić, że beneficjentami usankcjonowania takiego stanu rzeczy byliby np. niepełnosprawni ruchowo, którzy mogliby wykonywać pracę bez wychodzenia z domu. Dla wielu osób praca w crowdsourcingu to również szansa na zdobycie wiedzy i doświadczenia. Konieczność zawierania umów o dzieło i koszty to nie jest największy problem polskich pracodawców. Prawdziwym problemem są umowy oskładkowane.

Umowy o pracę i zlecenie Umowy z pracownikiem od 25 lat wolnej Polski są nieustannym polem walki między pracodawcami, a kolejnymi rządami. Państwo swego czasu przerzuciło na pracodawców i pracowników olbrzymie koszty związane z umowami o pracę i nie widać, aby to miało się zmienić w najbliższym czasie. Koszty pracy na umowie o pracę odprowadzone do państwa wynoszą około 1/3 kosztów umowy. Są to: • ubezpieczenia zdrowotne - przy całej świadomości jak działa system opieki zdrowotnej żaden szanujący swój czas pracownik nie będzie z takiej pseudo opieki korzystał

i Sprawiedliwości doskonale pokazują nam jak odkładane przez nas środki mogą nagle zostać „przesunięte do innego obszaru”. Mamy więc na nie zerowy wpływ, a działania rządzących mogą doprowadzić do szybkiego zmarnowania odkładanych przez nas środków. Nie bez przyczyny mówi się o polskim systemie emerytalnym jak o piramidzie finansowej. • i inne, których większość pracodawców i pracowników nie rozumie jak np. Fundusz Pracy. Te koszty zachęcają czy też zmuszają część pracodawców do ucieczki w umowy cywilnoprawne jak umowa o dzieło, czy też umowa zlecenie. Niestety tutaj również kolejne rządy w imię ochrony praw pracowniczych dewaluują lub mówiąc bezpośrednio, niszczą ich wartość nakładając na nie kolejne obostrzenia i zakazy jak ich oskładkowanie czy też limit ich liczby. W mojej opinii takie działania bezpośrednio doprowadziły do wzrostu szarej strefy, powstania niezliczonej liczby pośredników pracy i dziesiątek innych metod obejścia szkodliwego dla pracowników i pracodawców prawa. Muszę przyznać, że intencje ustawodawców są dobre, ale skuteczność ich wdrożenia jest zerowa. Na samym końcu poszkodowany jest pracownik, któremu wolno coraz mniej oraz pracodawca, który ponosi coraz to wyższe koszty zatrudnienia. Mogę się zgodzić, z prosocjalnym punktem widzenia, że te działania (gdyby były skuteczne) są potrzebne na stanowiskach nisko opłacanych i niewymagających wysokich kwalifikacji. Jednak nie można jedną miarą brać całego rynku i do jednego worka wrzucać pracowników wykonujących proste prace i specjalistów. Swego czasu wyróżniono (w dużej mierze nieformalnie) kontrakty menadżerskie dedykowane kierownikom i osobom zarządzającym. Czy takie podejście nie mogłoby zostać zastosowane również dla specjalistów w tym dla omawianej przeze mnie branży IT?

Umowa dla branży IT

• ubezpieczenie emerytalne - gdzie posunięcia Warto przeanalizować sytuację branży IT. Jej prarządu Platformy Obywatelskiej i plany Prawa cownicy są najlepiej zarabiającą grupą zawodową 26

ELEMENT

PO CO WPROWADZONO

KORZYŚCI DLA PRACOWNIKÓW

KORZYŚCI DLA PRACODAWCÓW

Okres wypowie- Zabezpiecza on pradzenia cownika przed szybką utratą pracy i daje szansę na znalezienie nowej

W czasie kiedy pracownicy IT są na wagę złota i potrafią znaleźć pracę w ciągu jednego dnia mogliby skrócić okres wypowiedzenia za odpowiednio wyższe wynagrodzenie

Krótszy okres wypowiedzenia dawałby pracodawcom szanse na dużo elastyczniejsze zarządzanie zasobami, a przez to eliminację pośredników

Dni urlopowe, prawo do urlopów okolicznościowych, chorobowe itd.

Umowa gwarantuje pracownikowi wiele benefitów związanych z prawem do wypoczynku czy celebracji

Pracownik, który odkłada sobie na 3 miesięczne wakacje może się zgodzić na pracę w zdefiniowanym okresie czasu bez urlopu. Dla pracodawcy jest to tak duża wartość, że jest w stanie zapłacić większe wynagrodzenie. Pracownik na długi urlop musiałby odkładać „dni urlopowe” przez blisko 3 lata.

W praktyce chodzi o płacenie jedynie za realnie przepracowany czas. Jeśli pracownik dostaje wynagrodzenie za pracę, liczba dni chorobowych i nieplanowanych nieobecności gwałtownie maleje.

Składki ZUS

W teorii pozwala pracownikom zabezpieczać swoje zdrowie i emerytury

Wysoko opłacani pracownicy rzadko kiedy korzystają z publicznej opieki zdrowotnej. Mądrzy ludzie nie wierzą w emerytury wypłacane przez skompromitowany system emerytalny i sami odkładają na spokojną starość. Innym tematem jest ciągle podwyższany próg przejścia na emeryturę, który dla osoby zamożnej nie musi być w żaden sposób wiążący. Pracownicy najchętniej wcale nie płaciliby na ZUS, a jeśli już jest to konieczne zaakceptowaliby ich minimalny poziom.

Zerowe lub minimalne składki dałyby szanse na obniżenie kosztów pracy.

w Polsce. Stworzyła się więc swoista elita, świadoma swoich praw i obowiązków. Grupa świetnie wykształconych specjalistów, z dostępem do nieskończonej ilości informacji, potrafiąca z tych informacji korzystać. Nie jest to grupa, którą można określić mianem biernie roszczeniowej, to raczej pracownicy gotowi do tego by samodzielnie walczyć o swoje prawa. Dlatego też nie istnieje (lub nie jest powszechnie znany) związek zawodowy pracowników IT.

Niestety w mojej ocenie w tym obszarze mamy patologiczną sytuację na rynku pracy, na której tracą zarówno pracownicy IT jak i pracodawcy zatrudniający specjalistów. Jak to możliwe? Pracodawcy z sektora IT w wielu przypadkach potrzebują elastycznych i niewiążących dla nich umów. Branża IT jest zmienna i projekt, który jest realizowany dziś jutro może okazać się nieaktualny lub też przebudowany tak bardzo, że obecnie posiadani pracownicy nie są w stanie go kontynuować (np. nastąpiła zmiana języka programowania w ja27

kim napisana będzie aplikacja). Dlatego też pracodawcy często boją się prowadzić rekrutacje, a potem podpisywać „ciężkie” i kosztowne dla nich umowy o pracę. Wolą sięgnąć po zasoby tzw. firm outsourcingowych, które za odpowiednią marżę oferują im usługi pracowników. Kontrakty takie rzadko opiewają na kwoty niższe niż kilkadziesiąt tysięcy złotych, a lwią ich część zatrzymuje pośrednik. Poszkodowany jest więc również pracownik, który „oddaje” wypracowane przez siebie środki na rzecz firm, które nie posiadają żadnego know how, a jedynie prezesa, sprzedawców ludzi i panie rekruterki. Eliminacja pośrednika przez uelastycznienie zasad zatrudnienia doprowadziłaby do zysku zarówno dla pracodawców jak i pracowników. Należy jednak zrezygnować z wielu obostrzeń związanych z umową o pracę. Dziś robi się to poprzez wypychanie pracowników na własną działalność gospodarczą. Na to urzędnicy nie patrzą przychylnym okiem i mogą nałożyć na pracodawcę karę. Należy podkreślić, że własna działalność jest bardzo dobrym rozwiązaniem dla pracowników IT ponieważ daje możliwość generowania kosztów i odliczeń od podatków. Jest też korzystna w pierwszych dwóch latach jej prowadzenia ze względu na obniżone obciążenia zusow-

skie. Oczywiście działalność to również dodatkowy kłopot lub koszty związane z prowadzeniem księgowości, ale sumarycznie minusy nie powinny przysłaniać plusów. Umowa IT mogłaby uprościć relacje podmiotów nią związanych, ale obowiązki księgowe i obciążenia zostawić po stronie pracodawcy, który i tak zazwyczaj posiada już działy kadr i księgowości. Kolejną ważną rzeczą dla pracodawcy jest odpowiednie zabudżetowanie środków na prowadzenie projektu IT, który kupując zasoby od pośrednika zazwyczaj wie, że za 5 programistów, 1 analityka i 1 testera zapłaci kwotę X za okres Y. Przy umowie o pracę koszty pracodawcy są nie do przewidzenia. Oczywiście łatwo można przewidzieć urlopy, ale nie da się przewidzieć chorobowego. Przy pracowniku na umowę o pracę na zwolnieniu lekarskim często trzeba szukać zastępstwa, albo od razu pogodzić się z przesunięciem czasowym. Wychodzę więc z pomysłem, który wymagać będzie zapewne dopracowania i wielu konsultacji wśród zainteresowanych stron, by stworzyć specjalne umowy dopasowane do potrzeb konkretnych branż. Dla nas taka umowa mogłaby uwzględniać specyfikę pracy informatyków i umownie możemy

nazwać ją Umową IT. Można pomysłowi zarzucić, że jest to rozwiązanie tylko dla wąskiej grupy ludzi, ale rozmowa o potrzebie takich formalizacji współpracy między specjalistami, a pracodawcami przyda się również w innych branżach. Przyjrzyjmy się kilku elementom Umowy IT, które mogłyby podlegać negocjacjom podczas ich zawierania, a które uwzględniają otoczenie biznesowe projektów informatycznych.Propozycja to połączenie w Umowach IT elementów kontraktów menadżerskich i umów b2b czyli zawieranych między dwoma przedsiębiorcami. Mogą się tam również pojawić zapisy, które zawarte są w umowie o pracę, ale ich stosowanie byłoby już kwestią umowną. Taka umowa mogłaby szybko się rozpowszechnić. Aby unikać sytuacji, w których pracodawcy nadużywają swoich praw względem pracowników powinien obowiązywać dla nich dolny próg określający minimalny dochód (płaca minimalna na umowie IT). Chodzi o to, żeby elastyczność i możliwość negocjacji była dopuszczalna jedynie dla wysoko opłacanych specjalistów. Można założyć, że pracodawca mógłby zaproponować pracownikom umowę IT od np. kwoty 9999 PLN netto, czyli kwoty, która realnie trafia na konto pracownika. Kwota ta nie byłaby obwarowana dodatkowymi ustawowymi obowiązkami oprócz obowiązku świadczenia pracy. Wszystkie elementy umowy jak liczba dni urlopowych, godziny pracy, nadgodziny i każdy inny podlegałby negocjacjom pomiędzy pracownikiem i pracodawcą.

prowadziłoby do konieczności jeszcze większego dopłacania do emerytur z budżetu. Nawet partie o liberalnych programach „poddają się” lobby związków zawodowych czy katastrofalnej sytuacji finansów państwa i nie decydują się na radykalne zmiany na rynku pracy. Jeśli jednak rządzący byliby w stanie spojrzeć bardziej perspektywicznie to dostrzegliby, że choć na pewno w pierwszym okresie składki na ZUS by zmalały, to w dłuższym okresie czasu zwiększyłyby się środki z podatków i składki z nowo powstających miejsc pracy. Umowy IT znacząco poprawiłyby sytuację pracowników i pracodawców, ale stanowią jedynie pierwszy krok do zaadaptowania prawa do realiów. Nierozwiązaną sprawą ciągle pozostają umowy crowdsourcingowe, które nie tyle wymagałyby dodania nowych form umów, co całościowej zmiany prawa. Zmiany te muszą uwzględniać oczywiście pracowników innych branż.

Źródła https://pl.wikipedia.org/wiki/Rewolucja_przemys%C5%82owa http://testerzy.pl/baza-wiedzy/technologia-niszczy-miejsca-pracy http://www.oxfordmartin.ox.ac.uk/downloads/ academic/The_Future_of_Employment.pdf http://testerzy.pl/baza-wiedzy/ewolucja-testowania

http://forsal.pl/artykuly/929689,automatyzacja-i-robotyzacja-pracy-wypieranie-ludzi-przez-maszyChoć pomysł pomógłby pracownikom i praco- ny-z-rynku-pracy.html dawcom stabilnych i rozwijających się branż, to na pewno napotka na opór rządzących, którzy dostrzegą odpływające składki na ZUS. To z kolei do-

Podsumowanie

Radosław Smilgin, ekspert w obszarze testowania i zapewnienia jakości oprogramowania, przedsiębiorca i trener. W swojej pracy łączy dwie testerskie szkoły: testowanie formalne i eksploracyjne. Jest pomysłodawcą i organizatorem Mistrzostw w Testowaniu Oprogramowania Testing-Cup. Autor książki dla początkujących testerów „Zawód Tester”. Swoją wiedzą i doświadczeniem dzieli się w Internecie na portalu testerzy.pl oraz na wielu otwartych i zamkniętych wykładach w kraju i za granicą. 29

O zwinnym zbieraniu wymagań przy użyciu języka Gherkin rozmawiamy z Łukaszem Nowackim, Project Managerem z firmy Neoteric, która zajmuje się zwinnym wytwarzaniem oprogramowania.

Wywiad

REQ Magazyn: Łukaszu, wiem, że opiekujesz się projektami od momentu ich uruchomienia. Czy mógłbyś podzielić się z naszymi czytelnikami, jakie etapy analizy biznesowej i inżynierii wymagań wyróżniasz aby zebrać wymagania od Klienta? Łukasz Nowacki: Wspólnie z klientem definiujemy problem biznesowy oraz rozwiązanie tego problemu w sposób bardzo ogólny. REQ Magazyn: czyli rozpoczynasz od analizy biznesowej. Na tym etapie rozmawiacie o rozwiązaniu? Łukasz Nowacki: Można powiedzieć, że zaczynam od analizy biznesowej, bo zastanawiamy się wspólnie z klientem jak chciałby, aby jego proces biznesowy wyglądał po wdrożeniu rozwiązania. Dzięki temu wiem, z czym ma największy problem. Rozmawiając z klientem o rozwiązaniu bardziej skupiam się na tym, jakie cechy powinno mieć rozwiązanie, czego się obawia, na jakich funkcjonalnościach najbardziej mu zależy. Drugim krokiem jest sesja z klientem, w trakcie której rozpisujemy wymagania korzystając z User Story Mapping. Na początku staram się zebrać wymagania do MVP (Minimum Viable Product przyp. red) w zgodzie z metodologią Lean Startup. Bazując na doświadczeniach staram się łączyć kilka zwinnych narzędzi, które w połączeniu dają zdecydowanie zadowalające efekty. 30

REQ Magazyn: A czym jest User Story Mapping? Łukasz Nowacki: User Story Mapping jest drogą do zebrania wymagań w sposób ogólny. Ma na celu opracowanie bardziej usystematyzowanego podejścia do planowania jakie funkcjonalności znajdą się w aplikacji. Podczas sesji na tablicy przyklejane są kartki. Wzdłuż osi poziomej umieszczamy nazwy funkcji według hierarchii ważności (lub porządku, w jakim można opisać działania, aby wyjaśnić zachowanie systemu). Wzdłuż osi pionowej dokłada się karteczki z zapisanymi nagłówkami User Stories lub scenariuszami, które opisują funkcjonalności. W trakcie sesji z niektórych funkcjonalności się rezygnuje, a inne dokłada. Wszytko po to, aby osiągnąć MVP, w końcu według Lean Startup następne wymagania zbiera się już od klientów. REQ Magazyn: Co następuje po wykonaniu takiego User Story Mapping? Łukasz Nowacki: Najpierw zastanówmy się przez chwilę, jak najlepiej zebrać wymagania, aby spełniały one swoją rolę. Subiektywnie oceniając, uważam, że wymagania powinny spełniać 3 główne kryteria tzn., że powinny być: - jednoznaczne i przejrzyste, - zrozumiałe dla wszystkich interesariuszy, - aktualne i udokumentowane. Aby znacząco ułatwić zbieranie wymagań oraz właściwie spełnić wszystkie powyższe kryteria, mo-

żemy zebrać wymagania za pomocą języka Gherkin. Jest on językiem naturalnym i poza tym, że świetnie nadaje się do zbierania wymagań, może też służyć programistom przy tworzeniu scenariuszy do testów funkcjonalnych. REQ Magazyn: Język Gherkin nie jest zbyt popularny, czy mógłbyś przybliżyć jak się korzysta z tego języka? Łukasz Nowacki: Zapis wymagań w języku Gherkin jest jednoznaczny, przejrzysty i co najważniejsze - prosty do zrozumienia dla wszystkich zainteresowanych stron. Dzięki temu dyskusja nad wymaganiami staje się możliwa. Jak każdy inny język, Gherkin posiada swoją składnię. Narzucona jest jej określona struktura, pojawiają się pewne słowa kluczowe, które muszą wystąpić. Tu mam przykład jak wygląda taki przykładowy zapis funkcji wylogowania z aplikacji: Feature: Logout from application Scenario: Given I am logged in When I click “log out” button Then I am informed about successful logout And I am redirect to login page Przystępując do tworzenia nowego opisu wymagań, zapisujemy Feature - w tej sekcji opisujemy nazwę funkcjonalności. Następnie przystępujemy do stworzenia scenariusza (Scenario). Warto zaznaczyć, że w jednym pliku może wystąpić kilka scenariuszy. Każdy scenariusz zawiera kilka kroków oznaczanych na początku każdego wersu, kolejno: Given, When i Then. Kroki poprzedzone słowem Given ustalają warunki początkowe, When służy do opisywania akcji wykonywanych dla danej funkcjonalności, a Then określa spodziewany rezultat. W powyższym przykładzie znajduje się jeszcze jedno słowo kluczowe: And, które kontynuuje wcześniejszą metodę. I tak, na przykład, użyte po When, będzie kontynuowało tę sekcję. Istnieje jeszcze słowo kluczowe But, ale przyznam szczerze, że w całej swojej karierze nie znalazłem dla niego zastosowania. To tyle, jeżeli chodzi o podstawy.

REQ Magazyn: Składnia języka Gherkin bardzo przypomina Use Case, jaka zatem jest przewaga pisania wymagań w tym języku?? Łukasz Nowacki: Zbierane wymagania w Gherkinie zapisywane są do pliku z rozszerzeniem .feature. Programiści mogą użyć takich plików do pisania testów automatycznych w metodyce BDD (Behavior-driven development) przy użyciu narzędzia Cucumber. Dzięki temu aplikacja od razu ma zapisane testy akceptacyjne. Za pomocą Use Case opisujemy przepływ procesu biznesowego również w języku naturalnym, lecz nie mamy możliwości wykorzystania ich bezpośrednio w testach automatycznych bez wcześniejszego przygotowania. Do tego dochodzi tzw. “krzywa uczenia się”, czyli konieczność zapoznania się czytelnika z notacją przypadków użycia, znajomość <<include>>, <<extend>>, czego nie ma przy języku Gherkin. REQ Magazyn: A jak wygląda praca z Gherkinem w praktyce? Łukasz Nowacki: Gherkin daje nam więcej możliwości. Możemy skorzystać z jego rozszerzonych funkcji. Background pozwala nam na wyłączenie wspólnych wierszy Given dla wszystkich scenariuszy przed te scenariusze. Dzięki temu możemy zaoszczędzić cenny czas. Dołączę tu przykład jakby to mogło wyglądać dla wybrania profilu w aplikacji typu SaaS. Feature: Select profile Background: Given I am logged in Scenario: First profile select Given I go to application after logging When I am asked which profile I would like to choose from my list And I select profile from list Then I see dashboard for this profile Scenario: Next profile select Given I am on dashboard And I have selected profile When I select profile from dropdown with list Then I see dashboard for this 31

Dodatkowo, jeżeli chcemy omówić wymagania, a w przyszłości przetestować więcej niż jeden przypadek, warto użyć przykładów, czyli skorzystać z funkcji Example. Zbieranie wymagań w takiej formie jest często najbardziej jednoznaczne. Aby użyć Example wystarczy oznaczyć zmienne znakami <> oraz wprowadzić tabelę pod scenariuszem. Należy pamiętać, że jeżeli używamy przykładów, nasze scenariusze powinny się nazywać Scenario Outline. Tu dołączę również przykład, który powinien wszystko rozjaśnić: Feature: Login to application Background: Given I am registered user And my account is activated Scenario Outline: Successful login Given I am on login page When I fill „login” with <login> And I fill „password” with <correct-password> And click „Login” button Then I am redirect to page with profile select Examples: | login | correct-password | | Lukasz | Gh3rk1n | | Arek | Cucumb3r | Scenario Outline: Unsuccessful login Given I am on login page When I fill „login” with <login> And I fill „password” with <incorrect-password> And clik „Login” button Then I am be informed about unsuccessful login Examples: | login | incorrect-password | | Lukasz | Gherkin | | Arek | Cucumber | Scenario: Unauthorized entry Given I am not logged in When I try to go Dashboard page Then I am redirect to login page

REQ Magazyn: A co ze zmianami wymagań, przecież w projektach występuje to dość często? Łukasz Nowacki: W projektach zwinnych wymagania mogą ulec zmianie, ale pamiętajmy, że zmiana to nie “odwracanie kota ogonem”. Po zidentyfikowaniu zmiany osoba, która zarządza wymaganiami musi wprowadzić taką zmianę w plikach .feature, a co za tym idzie - musi dokonać zmian w testach do aplikacji. Dzięki temu nasza dokumentacja może być przez cały czas aktualna, programiści nazywają to “żyjącą dokumentacją”. Wykonywanie prac według kolejnych scenariuszy skutkuje dostarczaniem działających elementów i świetnie wpisuje się w zasady zwinnego zarządzania. Wyniki testów w zestawieniu z wymaganiami zapisanymi w języku Gherkin pokazują na jakim etapie wytworzenia oprogramowania jesteśmy oraz co najważniejsze - jest to zrozumiałe dla wszystkich zainteresowanych stron! Dzięki temu znacząco poprawia się komunikacja w projekcie. REQ Magazyn: No dobrze, więc od czego zacząć naukę tego języka, a co najważniejsze jak przekonać do tego pozostałych członków zespołu? Ile zajmuje wdrożenie takiego podejścia do opracowania wymagań w firmie? Łukasz Nowacki: Po zapoznaniu się z podstawami rozpoczynamy od zapisania kilku scenariuszy w ramach jednej funkcjonalności. Samo zrozumienie składni nie jest trudne, największą trudność sprawia zapis When i Then. Trzeba się dobrze zastanowić czy akcja w danej linii jest już wynikiem lub skutkiem (wtedy zapisujemy ją jako Then). W zasadzie po kilku napisanych funkcjonalnościach cały proces zbierania wymagań w ten sposób przebiega coraz sprawniej. Przekonanie pozostałych członków zespołu nie jest w tym wypadku takie trudne jak wdrożenie np. SCRUM. Jeżeli zespół rozumie potrzebę aktualnej dokumentacji i jednoznacznie zdefiniowanych wymagań to argument, że można tworzyć na tej podstawie w dużo łatwiejszy sposób testy akceptacyjne tylko dopełnia pozytywną decyzję. Klienta przekonywać nie trzeba, przedstawiamy mu scenariusze dla jego funkcjonalności w języku zrozumiałym, a on na wcześniejszym etapie jest w stanie podjąć decyzję o zmianach.

REQ Magazyn: Czy są wymagania, których nie da się opisać takim językiem? Łukasz Nowacki: Teoretycznie nie ma takich wymagań. Natomiast osobiście nie podejmowałem się jeszcze pisania wymagań dla aplikacji nie posiadających aplikacji frontendowej. Istnieją rozwiązania, a także narzędzia do testowania backendu (napisanego np. w języku Java) i na githubie można znaleźć przykłady takiego zapisu. Może za jakiś czas i mi się trafi taki projekt. Wtedy na pewno podejmę próbę i podzielę się wrażeniami przy następnym spotkaniu. REQ Magazyn: Możesz polecić naszym czytelnikom publikacje, w których można przeczytać i nauczyć się tego języka? Łukasz Nowacki: Zdecydowanie polecam rozdziały dotyczące Gherkin w książce “The Cucumber Book”. Autorami są Matt Wynne oraz Aslak Hellesoy. Dużo informacji można też znaleźć na portalu Quora, gdzie wielu miłośników BDD wymienia się informacjami o języku Gherkin. Sporą ilość przykładów plików z rozszerzeniem .feature można znaleźć na Github. REQ Magazyn: Serdecznie dziękuję za rozmowę. Łukasz Nowacki: Ja również dziękuję.

Łukasz Nowacki – Project Manager w gdańskim software housie Neoteric. Entuzjasta metodyk zwinnych i certyfikowany Scrum Master, prelegent na konferencjach IT. Obdarzony biznesowym instynktem, doskonale rozumie oczekiwania klientów i potrafi połączyć je z potrzebami użytkownika oraz z możliwościami zespoł u projektowego. W swojej codziennej pracy zarządza projektami IT, od dużych aplikacji B2B po mniejsze startupy. W wolnych chwilach lubidzielić się swoją wiedzą, odpowiadając na pytania użytkowników Quory. Znajdziecie go teżna LinkedIn: linkedin.com/in/lnowacki. 33

chcesz układać puzzle w

inżynierii wymagań

razem z nami

Facebook

http://www.facebook.com/reqmagazyn

SIW - Stowarzyszenie Inżynierii Wymagań

Reklama

kontakt@reqmagazyn.pl

Współpraca

Osoby zainteresowane współpracą w zakresie publikacji prosimy o kontakt: kontakt@reqmagazyn.pl