Tytuł oryginału: Specification by Example: How Successful Teams Deliver the Right Software
Tłumaczenie: Arkadiusz Romanek
ISBN: 978-83-246-9118-0
Original edition copyright © 2011 by Manning Publications Co.
All rights reserved.
Polish edition copyright © 2014 by HELION SA.
All rights reserved.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/speprz
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
Spis treĂci
Wprowadzenie 11
PodziÚkowania 22
O autorze 23
O ilustracji na okïadce 24
CZ}¥m I
Zaczynamy!
1
Kluczowe
korzyĂci 27
Sprawniejsze wprowadzanie zmian .............................................................................................. 30
Wyĝsza jakoĂÊ produktu ............................................................................................................... 32
Mniej przeróbek ............................................................................................................................ 36
Lepsze dostosowanie aktywnoĂci ................................................................................................. 39
PamiÚtaj ........................................................................................................................................ 41
2
Wzorce kluczowych procesów 43
Zdefiniowanie zakresu prac w oparciu o cele biznesowe ............................................................. 45
Wspólne specyfikowanie .............................................................................................................. 45
Opisywanie z wykorzystaniem przykïadów ilustrujÈcych .............................................................. 46
Udoskonalanie specyfikacji .......................................................................................................... 47
Automatyzacja walidacji bez zmiany specyfikacji ........................................................................ 47
CzÚsta walidacja ........................................................................................................................... 49
Tworzenie systemu dokumentacji ................................................................................................. 49
Praktyczny przykïad ...................................................................................................................... 50
Cel biznesowy ............................................................................................................................... 50
Przykïad poprawnego celu biznesowego .............................................................................................51
Zakres ........................................................................................................................................... 51
Historyjki uĝytkowników podstawowego elementu systemu lojalnoĂciowego .......................................51
Kluczowe przykïady ....................................................................................................................... 51
Kluczowe przykïady: Darmowa dostawa ..............................................................................................52
Specyfikacja z przykïadami .......................................................................................................... 52
Darmowa dostawa ..............................................................................................................................52
Przykïady ............................................................................................................................................53
Wykonywalna specyfikacja ........................................................................................................... 53
¿yjÈca dokumentacja .................................................................................................................... 53
PamiÚtaj ........................................................................................................................................ 54
3
¿yjÈca dokumentacja 55
Dlaczego potrzebujemy pewnej dokumentacji? ............................................................................ 56
Testy mogÈ byÊ dobrÈ dokumentacjÈ ........................................................................................... 57
Tworzenie dokumentacji na podstawie wykonywalnej specyfikacji ............................................. 58
Zalety modelu zorientowanego na dokumentacjÚ ......................................................................... 60
PamiÚtaj ........................................................................................................................................ 61
4
Spis treĂci
4
Inicjowanie zmian 63
Jak rozpoczÈÊ zmianÚ procesu? ................................................................................................... 64
Wdraĝaj specyfikacjÚ przez przykïady jako czÚĂÊ rozlegïego procesu zmian .........................................65
Kiedy: W projektach typu greenfield .............................................................................................65
Skup siÚ na poprawie jakoĂci ..............................................................................................................65
Zacznij od automatyzacji testów funkcjonalnych ..................................................................................66
Kiedy: Zmiany dotyczÈ istniejÈcego projektu .................................................................................66
Wprowadě narzÚdzie do wykonywalnych specyfikacji ..........................................................................68
Kiedy: Zaleĝnie od potrzeb wïasnych testerów ..............................................................................68
Wykorzystaj TDD jako odskoczniÚ .......................................................................................................70
Kiedy: Deweloperzy majÈ duĝÈ wiedzÚ na temat TDD ...................................................................70
Jak zaczÈÊ zmieniaÊ kulturÚ zespoïu? .......................................................................................... 70
Unikaj uĝywania terminów sugerujÈcych zwinnoĂÊ lub bycie „agile” ....................................................70
Kiedy: Pracujesz w Ărodowisku opornym na zmiany .....................................................................70
Zadbaj o uzyskanie wsparcia kierownictwa ..........................................................................................72
Sprzedaj specyfikacjÚ przez przykïady jako lepszÈ metodÚ wykonywania testów akceptacyjnych .........73
Niech automatyzacja testów nie bÚdzie celem koñcowym ...................................................................74
Nie koncentruj siÚ wyïÈcznie na narzÚdziu ...........................................................................................75
W czasie migracji niech jedna osoba ciÈgle pracuje nad starszymi skryptami ......................................75
Kiedy: Wprowadzasz automatyzacjÚ funkcjonalnÈ do istniejÈcych systemów ...............................75
Sprawdzaj, kto wykonuje testy automatyczne ......................................................................................76
Kiedy: Deweloperzy niechÚtnie podchodzÈ do uczestnictwa w procesie ........................................76
Jak zespoïy wdraĝajÈ zasady wspóïpracy w procesach iteracyjnych i przepïywu? ..................... 77
Zespóï Global Talent Management z Ultimate Software ............................................................... 77
Zespóï Sierra w BNP Paribas ........................................................................................................ 80
Sky Network Services ................................................................................................................... 81
Radzenie sobie z potrzebÈ formalnego zatwierdzenia i identyfikowalnoĂciÈ ............................... 82
Zachowaj wykonywalne specyfikacje w systemie kontroli wersji ..........................................................83
Uzyskaj zatwierdzenie na eksportowanej ĝyjÈcej dokumentacji ............................................................84
Kiedy: Zatwierdzasz iteracjÚ po iteracji ..........................................................................................84
Uzyskaj zatwierdzenie zakresu, a nie specyfikacji ................................................................................84
Kiedy: Zatwierdzasz odleglejsze kamienie milowe .........................................................................84
Uzyskaj zatwierdzenie „odchudzonych” przypadków uĝycia .................................................................85
Kiedy: Formalne zatwierdzenia wymagajÈ uzupeïnienia o szczegóïy ..............................................85
Wprowadě realizacje przypadków uĝycia .............................................................................................86
Kiedy: Formalne zatwierdzenia wymagajÈ uwzglÚdniania wszystkich szczegóïów .........................86
Znaki ostrzegawcze ....................................................................................................................... 87
Uwaĝaj na testy, które czÚsto dajÈ róĝne wyniki .......................................................................... 87
Uwaĝaj na bumerangi ................................................................................................................... 88
Uwaĝaj na niedopasowanie organizacyjne ................................................................................... 88
Uwaĝaj na kod „na wszelki wypadek” .......................................................................................... 89
Uwaĝaj na „chirurgiÚ ĂrutówkÈ” ................................................................................................... 90
PamiÚtaj ........................................................................................................................................ 90
Spis treĂci
5
CZ}¥m II
Wzorce kluczowych procesów
5
Definiowanie zakresu na podstawie celów 93
OkreĂlanie odpowiedniego zakresu .............................................................................................. 95
Znajdě odpowiedzi na pytania „Dlaczego?” i „Kto?” .............................................................................96
Zrozum, skÈd bierze siÚ wartoĂÊ .........................................................................................................98
Dowiedz siÚ, jakich wyników oczekujÈ uĝytkownicy biznesowi ............................................................99
Niech deweloperzy zapewniÈ czÚĂÊ „chcÚ” historyjek uĝytkownika ....................................................100
Kiedy: Uĝytkownicy biznesowi ufajÈ zespoïowi zajmujÈcemu siÚ wytwarzaniem oprogramowania .....100
Wspóïpraca w celu zdefiniowania zakresu bez kontroli wysokiego poziomu ............................. 101
Zapytaj o to, jak coĂ moĝe byÊ przydatne ..........................................................................................102
Zapytaj o rozwiÈzanie alternatywne ....................................................................................................103
Nie patrz na projekt wyïÈcznie z perspektywy najniĝszego poziomu ...................................................103
Zadbaj, aby zespoïy dostarczaïy kompletne funkcje ...........................................................................104
Kiedy: Pracujesz nad duĝymi projektami z czÚĂciami zespoïów w róĝnych lokalizacjach .............104
WiÚcej informacji ........................................................................................................................ 105
PamiÚtaj ...................................................................................................................................... 106
6
Wspólne specyfikowanie 107
Dlaczego podczas definiowania specyfikacji musimy ze sobÈ wspóïpracowaÊ? ....................... 108
Najpopularniejsze modele wspóïpracy ....................................................................................... 109
Spróbuj zorganizowaÊ duĝe warsztaty dla wszystkich czïonków zespoïu .................................................109
Kiedy: Zaczynasz wdraĝaÊ zasady specyfikacji przez przykïady ...................................................109
Wypróbuj spotkania w mniejszym gronie („trzej amigos”) .................................................................111
Kiedy: Domena wymaga skïadania czÚstych wyjaĂnieñ ..............................................................111
Programujcie w parach .....................................................................................................................113
Kiedy: Pracujecie nad dojrzaïymi produktami ..............................................................................113
Spraw, aby testerzy przed iteracjÈ regularnie sprawdzali testy ............................................................115
Kiedy: Analitycy tworzÈ testy ......................................................................................................115
Spróbuj nieformalnych rozmów .........................................................................................................115
Kiedy: Interesariusze biznesowi sÈ ïatwo dostÚpni ......................................................................115
Przygotowanie wspóïpracy ......................................................................................................... 116
Organizuj spotkania przygotowawcze ................................................................................................117
Kiedy: W projekcie uczestniczy wielu interesariuszy ...................................................................117
ZdobÈdě zaangaĝowanie interesariuszy ..............................................................................................118
Dobrze przygotuj siÚ do wstÚpnych spotkañ z interesariuszami ..........................................................119
Kiedy: Interesariusze nie sÈ dostÚpni na miejscu ........................................................................119
Niech czïonkowie zespoïu przejrzÈ historyjki na wczesnym etapie ......................................................121
Kiedy: Analitycy/eksperci ds. domeny sÈ wÈskim gardïem procesu ............................................121
Przygotuj tylko wstÚpne przykïady .....................................................................................................122
Kiedy: Interesariusze sÈ ïatwo dostÚpni ......................................................................................122
Nie utrudniaj dyskusji przez przesadne przygotowania .......................................................................123
Wybór modelu wspóïpracy ......................................................................................................... 124
PamiÚtaj ...................................................................................................................................... 125
6
Spis treĂci
7
Wykorzystanie
przykïadów ilustrujÈcych 127
Uzupeïnienie specyfikacji z wykorzystaniem przykïadów ilustrujÈcych: przykïad ...................... 130
Przykïady powinny byÊ precyzyjne ............................................................................................. 131
Nie uĝywaj w swoich przykïadach systemu zamkniÚtych odpowiedzi (tak/nie) ...................................131
Kiedy: Bazowe koncepcje nie sÈ definiowane osobno .................................................................131
Unikaj uĝywania abstrakcyjnych klas równowaĝnoĂci ........................................................................132
Kiedy: Moĝesz zdefiniowaÊ konkretny przykïad ...........................................................................132
Przykïady powinny byÊ kompletne .............................................................................................. 133
Eksperymentuj z danymi ...................................................................................................................133
Pytaj, czy istnieje alternatywna metoda sprawdzenia funkcjonalnoĂci ................................................133
Kiedy: Pracujesz ze zïoĝonÈ/starÈ infrastrukturÈ .........................................................................133
Przykïady powinny byÊ realistyczne ........................................................................................... 134
Unikaj generowania zmyĂlonych danych ...........................................................................................134
Kiedy: Podczas prac nad projektem opartym na danych .............................................................134
Pozyskaj podstawowe przykïady bezpoĂrednio od klientów ...............................................................135
Kiedy: Pracujesz dla klientów korporacyjnych .............................................................................135
Przykïady powinny byÊ zrozumiaïe ............................................................................................. 137
Unikaj pokusy zbadania wszelkich moĝliwych kombinacji ..................................................................138
Szukaj ukrytych koncepcji .................................................................................................................138
Ilustrowanie wymagañ niefunkcjonalnych .................................................................................. 140
ZdobÈdě precyzyjne wymagania wydajnoĂciowe ...............................................................................140
Kiedy: Wysoka wydajnoĂÊ jest funkcjÈ kluczowÈ ........................................................................140
Wykorzystaj uproszczone prototypy interfejsów uĝytkownika .............................................................141
Wypróbuj model QUPER ...................................................................................................................142
Kiedy: Wymagania zmieniajÈ siÚ i sÈ skalowalne ........................................................................142
Wykorzystaj listÚ kontrolnÈ podczas dyskusji ....................................................................................143
Kiedy: PojawiajÈ siÚ obawy przekrojowe ....................................................................................143
Stwórz przykïad referencyjny .............................................................................................................144
Kiedy: Wymagania sÈ niemoĝliwe do oszacowania .....................................................................144
PamiÚtaj ...................................................................................................................................... 145
8
Udoskonalanie specyfikacji 147
Przykïad dobrej specyfikacji ....................................................................................................... 149
Darmowa dostawa ...................................................................................................................... 149
Przykïady .................................................................................................................................... 149
Przykïad zïej specyfikacji ............................................................................................................ 150
Na co naleĝy zwróciÊ uwagÚ podczas udoskonalania specyfikacji? ........................................... 152
Przykïady powinny byÊ precyzyjne i testowalne ......................................................................... 152
Skrypty to nie specyfikacje ......................................................................................................... 152
Nie twórz opisów w formie przepïywów .............................................................................................154
Specyfikacje powinny dotyczyÊ funkcjonalnoĂci biznesowej, a nie projektu oprogramowania ...... 154
Unikaj tworzenia specyfikacji, które sÈ ĂciĂle powiÈzane z kodem ......................................................155
Oprzyj siÚ pokusie obejĂcia trudnoĂci technicznych w specyfikacjach ...............................................156
Kiedy: Pracujesz na starym systemie .........................................................................................156
Nie pozwól uwiÚziÊ siÚ przez szczegóïy interfejsu uĝytkownika ..........................................................157
Kiedy: Pracujesz nad projektami internetowymi ..........................................................................157
Specyfikacje powinny byÊ oczywiste .......................................................................................... 157
Uĝyj opisowego tytuïu i wyjaĂnij cel, stosujÈc krótkie zdania .............................................................158
Pokaĝ i milcz .....................................................................................................................................158
Kiedy: KtoĂ pracuje nad specyfikacjÈ samodzielnie ....................................................................158
W celu: Sprawdzenia, czy specyfikacja jest oczywista i nie wymaga dodatkowych tïumaczeñ ....158
Spis treĂci
7
Nie upraszczaj nadmiernie przykïadów ..............................................................................................159
Zacznij od podstawowych przykïadów, a nastÚpnie rozszerz zakres przez eksplorowanie ...................161
Kiedy: Opisujesz reguïy za pomocÈ wielu kombinacji parametrów ..............................................161
Specyfikacje powinny byÊ ostre ................................................................................................. 161
Zastosuj wzorzec „ZakïadajÈc/Jeĝeli/Wtedy” ......................................................................................162
W celu: Sprawienia, by testy byïy ïatwiejsze do zrozumienia .......................................................162
Nie definiuj jawnie wszystkich zaleĝnoĂci w specyfikacji ....................................................................163
Kiedy: Musisz poradziÊ sobie ze skomplikowanymi zaleĝnoĂciami/integralnoĂciÈ referencyjnÈ ......163
Zastosuj ustawienia domyĂlne w warstwie automatyzacji ..................................................................164
Nie polegaj na domyĂlnych wartoĂciach w kaĝdym przypadku ...........................................................164
Kiedy: Pracujesz z obiektami o wielu atrybutach .........................................................................164
Specyfikacje powinny byÊ napisane w jÚzyku domeny ............................................................... 165
Udoskonalanie specyfikacji w praktyce ...................................................................................... 165
PamiÚtaj ...................................................................................................................................... 168
9
Automatyczna walidacja bez zmiany specyfikacji 169
Czy automatyzacja jest w ogóle potrzebna? ............................................................................... 170
RozpoczÚcie automatyzacji ......................................................................................................... 172
Aby poznaÊ narzÚdzia, wypróbuj je najpierw w prostym projekcie ......................................................172
Kiedy: Pracujesz z istniejÈcym systemem ..................................................................................172
Zaplanuj automatyzacjÚ z wyprzedzeniem ..........................................................................................173
Nie opóěniaj i nie odsuwaj od siebie prac zwiÈzanych z automatyzacjÈ ..............................................175
Unikaj automatyzacji istniejÈcych skryptów testów rÚcznych .............................................................175
ZdobÈdě zaufanie dziÚki testom interfejsu uĝytkownika ......................................................................176
Kiedy: Czïonkowie zespoïu sÈ nastawieni sceptycznie do wykonywalnych specyfikacji ...............176
ZarzÈdzanie warstwÈ automatyzacji ........................................................................................... 178
Nie traktuj kodu automatyzacji jak kodu drugiej kategorii ....................................................................178
Opisz procesy walidacji w warstwie automatyzacji ............................................................................179
Nie powielaj logiki biznesowej w warstwie automatyzacji testów ........................................................180
Automatyzuj wzdïuĝ granic systemu ..................................................................................................181
Kiedy: Integracje sÈ skomplikowane ...........................................................................................181
Nie sprawdzaj logiki biznesowej za pomocÈ interfejsu uĝytkownika ....................................................182
Automatyzacja pod skórÈ aplikacji .....................................................................................................183
Kiedy: Sprawdzasz ograniczenia sesji i przepïywu ......................................................................183
Automatyzacja interfejsów uĝytkownika ..................................................................................... 184
OkreĂl funkcjonalnoĂÊ interfejsu uĝytkownika na wyĝszym poziomie abstrakcji ..................................186
FunkcjonalnoĂÊ interfejsu uĝytkownika sprawdzaj tylko ze specyfikacjÈ interfejsu uĝytkownika ..........188
Kiedy: Interfejs uĝytkownika zawiera zïoĝonÈ logikÚ ....................................................................188
Unikaj zarejestrowanych testów interfejsu uĝytkownika ......................................................................188
Ustaw kontekst w bazie danych .........................................................................................................189
ZarzÈdzanie danymi testowymi ................................................................................................... 191
Unikaj wykorzystywania danych wstÚpnie wypeïnionych ...................................................................191
Kiedy: Definiujesz logikÚ, która nie bazuje na danych ..................................................................191
Spróbuj wykorzystaÊ wstÚpnie przygotowane dane referencyjne .......................................................192
Kiedy: W systemach bazujÈcych na danych ...............................................................................192
WyciÈgnij prototypy z bazy danych ....................................................................................................193
Kiedy: W starych, dojrzaïych systemach bazujÈcych na danych .................................................193
PamiÚtaj ...................................................................................................................................... 194
8
Spis treĂci
10
CzÚsta walidacja 195
Zmniejszenie zawodnoĂci ........................................................................................................... 197
Znajdě najbardziej irytujÈcy CiÚ element, napraw go, a nastÚpnie powtórz caïÈ operacjÚ ....................198
Kiedy: Pracujesz w systemie z kiepskim wsparciem dla testów automatycznych ........................198
OkreĂl niestabilne testy, korzystajÈc z historii testów ciÈgïej integracji ...................................................199
Kiedy: Modernizujesz i dopasowujesz automatyczne testy do starego systemu ..........................199
Utwórz dedykowane Ărodowisko ciÈgïej walidacji ..............................................................................199
Zastosuj w peïni zautomatyzowanÈ procedurÚ instalacji .....................................................................200
Utwórz uproszczonych „dublerów” systemów zewnÚtrznych .............................................................201
Kiedy: Pracujesz z zewnÚtrznymi ěródïami danych referencyjnych ..............................................201
Odizoluj wybrane systemy zewnÚtrzne ..............................................................................................202
Kiedy: Na WaszÈ pracÚ majÈ wpïyw systemy zewnÚtrzne ...........................................................202
Wypróbuj walidacjÚ wielostopniowÈ ..................................................................................................202
Kiedy: Pracujesz w duĝych grupach lub z grupami w róĝnych lokalizacjach ................................202
Wykonaj testy w transakcjach ...........................................................................................................203
Kiedy: Wykonywalne specyfikacje modyfikujÈ dane referencyjne ................................................203
Wykonaj szybkie testy danych referencyjnych ...................................................................................204
Kiedy: W systemach opartych na danych ...................................................................................204
Oczekuj zdarzeñ, zamiast nastawiaÊ siÚ na okreĂlony czas trwania ....................................................204
Uczyñ przetwarzanie asynchroniczne rozwiÈzaniem opcjonalnym ......................................................205
Kiedy: Pracujesz nad projektami typu greenfield .........................................................................205
Nie wykorzystuj wykonywalnych specyfikacji w funkcji walidacji kompleksowej typu end-to-end .......206
Kiedy: W projektach typu brownfield ..........................................................................................206
Szybsze uzyskiwanie informacji zwrotnej ................................................................................... 207
Wprowadě operacyjny czas dziaïania ................................................................................................207
Kiedy: Musisz radziÊ sobie z ograniczeniami czasowymi ............................................................207
Podziel duĝe zestawy testów na mniejsze moduïy .............................................................................208
Unikaj wykorzystywania do testów baz danych przechowywanych w pamiÚci ...................................209
Kiedy: W systemach bazujÈcych na danych ...............................................................................209
Oddziel testy szybkie od wolnych ......................................................................................................210
Kiedy: Niewielka czÚĂÊ testów zajmuje wiÚkszoĂÊ czasu przeznaczonego na ich wykonanie .......210
Utrzymaj stabilnoĂÊ uruchamianych na noc pakietów testów .............................................................210
Kiedy: Niemrawe testy sÈ rozpoczynane w nocy ........................................................................210
Stwórz pakiet aktualnej iteracji ...........................................................................................................211
Wykonuj testy równolegle .................................................................................................................212
Kiedy: Moĝesz stworzyÊ kilka Ărodowisk testowych ...................................................................212
Spróbuj wyïÈczyÊ testy, z których wykonaniem wiÈĝe siÚ mniejsze ryzyko .........................................213
Kiedy: Feedback z testów jest bardzo niemrawy .........................................................................213
ZarzÈdzanie testami, które koñczÈ siÚ niepowodzeniem ............................................................ 214
Stwórz pakiet znanych nieudanych testów regresji ............................................................................215
Sprawdzaj automatycznie, które testy sÈ wyïÈczone ..........................................................................216
Kiedy: Nieudane testy zostajÈ zneutralizowane, a nie trafiajÈ do oddzielnego pakietu ...................216
PamiÚtaj ...................................................................................................................................... 217
11
Tworzenie systemu dokumentacji 219
¿yjÈca dokumentacja powinna byÊ ïatwa do zrozumienia .......................................................... 219
Nie twórz dïugich specyfikacji ...........................................................................................................220
Nie uĝywaj wielu specyfikacji do opisania jednej funkcji ....................................................................220
Szukaj koncepcji wyĝszego poziomu .................................................................................................221
Unikaj stosowania w testach technicznych pojÚÊ automatyki .............................................................221
Kiedy: Interesariusze nie majÈ wystarczajÈcej wiedzy technicznej ...............................................221
Spis treĂci
9
¿yjÈca dokumentacja powinna byÊ spójna ................................................................................. 222
EwoluujÈcy jÚzyk ...............................................................................................................................223
TworzÈc jÚzyk specyfikacji, bazuj na personach ................................................................................224
Kiedy: W projektach internetowych ............................................................................................224
Promuj wspóïpracÚ w celu zdefiniowania sïownika jÚzyka .................................................................225
Kiedy: Rezygnujesz z warsztatów specyfikacji ............................................................................225
Gromadě dokumentacjÚ swoich bloków konstrukcyjnych ..................................................................226
¿yjÈca dokumentacja powinna byÊ zorganizowana
zgodnie z reguïami uïatwiajÈcymi dostÚp ............................................................................ 227
Organizuj bieĝÈcÈ pracÚ, segregujÈc jÈ wedïug historyjek ..................................................................228
Zorganizuj historyjki na podstawie obszarów funkcjonalnych .............................................................228
Pogrupuj specyfikacje wedïug dróg nawigacji w interfejsie uĝytkownika ............................................229
Kiedy: Dokumentujesz interfejsy uĝytkownika .............................................................................229
Zorganizuj specyfikacje wedïug procesów biznesowych ....................................................................230
Kiedy: Wymagana jest identyfikowalnoĂÊ przypadków uĝycia typu end-to-end ...........................230
Uĝywaj znaczników zamiast adresów URL, odnoszÈc siÚ do specyfikacji wykonywalnych .................231
Kiedy: Potrzebujesz identyfikowalnoĂci specyfikacji ...................................................................231
Sïuchaj swojej ĝyjÈcej dokumentacji .......................................................................................... 232
PamiÚtaj ...................................................................................................................................... 233
CZ}¥m III
Studia przypadków
12
uSwitch 237
RozpoczÚcie zmiany procesu ...................................................................................................... 238
Optymalizacja procesu ............................................................................................................... 240
Obecny ksztaït procesu ............................................................................................................... 244
Efekt koñcowy ............................................................................................................................. 245
Najwaĝniejsze lekcje ................................................................................................................... 245
13
RainStor 247
Zmiana procesu .......................................................................................................................... 247
Obecny ksztaït procesu ............................................................................................................... 250
Najwaĝniejsze lekcje ................................................................................................................... 251
14
Iowa Student Loan 253
Zmiana procesu .......................................................................................................................... 253
Optymalizacja procesu ............................................................................................................... 255
¿yjÈca dokumentacja jako przewaga konkurencyjna ................................................................. 258
Najwaĝniejsze lekcje ................................................................................................................... 259
15
Sabre Airline Solutions 261
Zmiana procesu .......................................................................................................................... 261
Poprawa wspóïpracy .................................................................................................................. 263
Efekt koñcowy ............................................................................................................................. 265
Najwaĝniejsze lekcje ................................................................................................................... 265
10
Spis treĂci
16
ePlan Services 267
Zmiana procesu .......................................................................................................................... 267
¿yjÈca dokumentacja .................................................................................................................. 270
Obecny proces ............................................................................................................................ 271
Najwaĝniejsze lekcje ................................................................................................................... 273
17
Songkick 275
Zmiana procesu .......................................................................................................................... 276
Obecny ksztaït procesu ............................................................................................................... 278
Najwaĝniejsze lekcje ................................................................................................................... 280
18
Podsumowanie 283
Wspóïpraca przy definiowaniu wymagañ buduje wzajemne zaufanie interesariuszy
i czïonków zespoïu ................................................................................................................ 283
Wspóïpraca wymaga przygotowania .......................................................................................... 284
Wspóïpraca moĝe przybieraÊ wiele róĝnych form ...................................................................... 285
Przydaje siÚ umiejÚtnoĂÊ spojrzenia na cel koñcowy jak na dokumentowanie
procesów biznesowych ......................................................................................................... 286
W dïuĝszej perspektywie prawdziwÈ wartoĂciÈ dla zespoïu jest system ĝyjÈcej dokumentacji ..... 287
Dodatek A. ½ródïa 289
Skorowidz 293
Wprowadzenie
siÈĝka, którÈ trzymasz w dïoniach (lub którÈ widzisz na monitorze swojego kom-
putera), jest efektem koñcowym cyklu badañ nad procesem, w czasie którego zaj-
mujÈce siÚ wytwarzaniem oprogramowania zespoïy na caïym Ăwiecie definiujÈ,
rozwijajÈ i dostarczajÈ
wïaĂciwe produkty — wolne od bïÚdów i opracowywane w krót-
kich cyklach projektowych. Ta ksiÈĝka zawiera wiedzÚ zgromadzonÈ dziÚki analizie pra-
wie piÚÊdziesiÚciu projektów inĝynierii oprogramowania, podczas których zespoïy pracowaïy
nad dostarczeniem szerokiego zakresu produktów — poczÈwszy od ogólnodostÚpnych stron
internetowych aĝ po wewnÚtrzne systemy typu
back-office. ZbierajÈc materiaïy do tej ksiÈĝki,
przeanalizowaïem dziaïania zespoïów rozmaitych typów — byïy to zarówno maïe grupy ludzi
pracujÈcych w tym samym biurze, jak i powiÈzane sieci programistów czasami rozlokowane
nawet na róĝnych kontynentach, osoby posïugujÈce siÚ róĝnorakimi metodologiami pro-
cesów inĝynierii: programowaniem ekstremalnym (ang.
Extreme Programming), Scrumem,
Kanbanem czy podobnymi metodami (czÚsto poïÈczonymi ze sobÈ i przybierajÈcymi formy
metod zwinnych, tj.
agile i lean). Wszystkie te zespoïy ïÈczyïo jedno: Ăcisïa wspóïpraca
w zakresie opracowywania poprawnych specyfikacji oraz testów, a takĝe koñcowy sukces
i korzyĂci, jakie staïy siÚ ich udziaïem dziÚki tej wspóïpracy.
Specyfikacja przez przykïady
Róĝne zespoïy stosujÈ róĝne terminy dla nazwania tego, co robiÈ ze specyfikacjami i testami,
a przecieĝ w kaĝdym przypadku ludzie ci odwoïujÈ siÚ do tych samych kluczowych zasad
i koncepcji, które moim zdaniem w gruncie rzeczy sÈ zawsze takie same. WĂród uĝywanych
przez zespoïy terminów i skrótów znajdujemy takie jak:
x
Zwinne testowanie akceptacyjne.
x
ATDD (ang.
Acceptance Test-Driven Development), czyli wytwarzanie oprogramowania
w oparciu o testy akceptacyjne.
x
EDT (ang.
Example-Driven Development), tj. wytwarzanie oprogramowania w oparciu
o przykïady.
x
Testowanie przez historyjki uĝytkownika (ang.
story testing).
x
BDD (ang.
Behavior-Driven Development), czyli wytwarzanie oprogramowania w oparciu
o analizÚ zachowañ uĝytkowników.
x
Specyfikacja przez przykïady (ang.
Specification by Example).
Juĝ sam fakt, ĝe te same dziaïania majÈ tak wiele róĝnych nazw, moĝe nam wiele powiedzieÊ
o ogromnej innowacyjnoĂci, z jakÈ mamy do czynienia w tej dziedzinie. MnogoĂÊ stosowa-
nych terminów i definicji Ăwiadczy takĝe o tym, ĝe praktyki opisane w tej ksiÈĝce wpïywajÈ
na zmianÚ podejĂcia zespoïów do specyfikacji oraz do zagadnienia wytwarzania oprogramo-
wania i jego testowania. KierujÈc siÚ dÈĝeniem do zachowania spójnoĂci przekazu, musiaïem
K
12
Specyfikacja na przykïadach
jednak wybraÊ jeden termin. Zdecydowaïem siÚ na
specyfikacjÚ przez przykïady i bÚdÚ uĝywaï
tego okreĂlenia w caïej ksiÈĝce. WyjaĂniÚ mój wybór w czÚĂci tego wprowadzenia zatytuïo-
wanej „Kilka sïów na temat terminologii”, gdzie znajdzie siÚ takĝe kilka szczegóïów dotyczÈ-
cych reszty terminów zastosowanych dla nazwania elementów opisywanego procesu.
W Ăwiecie rzeczywistym…
Szczegóïy proponowanej przeze mnie metodyki przedstawiam, odwoïujÈc siÚ do licznych
studiów przypadków i zarejestrowanych rozmów z czïonkami grup programistów. Wybra-
ïem to podejĂcie Ăwiadomie, z myĂlÈ o tym, ĝeby czytelnicy mieli szansÚ dowiedzieÊ siÚ,
jak radziïy sobie prawdziwe zespoïy, pracujÈce zgodnie z reguïami tej metody i czerpiÈce
z niej spore korzyĂci. Specyfikacja przez przykïady w ĝadnym razie nie jest ciemniejszÈ
stronÈ sztuki, mimo ĝe niektóre popularne media przekonujÈ, ĝe jest inaczej.
Prawie wszystko, o czym mówimy w tej ksiÈĝce, pochodzi z rzeczywistego Ăwiata inĝy-
nierii oprogramowania, dotyczy dziaïajÈcych w tym Ăwiecie zespoïów oraz ich — jak najbar-
dziej realnych — doĂwiadczeñ. Tylko nieliczne praktyki zostaïy przedstawione w formie
sugestii niepopartych studium przypadku. SÈ to zwykle pomysïy, które — moim zda-
niem — bÚdÈ w przyszïoĂci stanowiÊ waĝny przyczynek do dyskusji. I wïaĂnie jako takie sÈ
przeze mnie przedstawiane.
Jestem przekonany, ĝe moje wnioski, a takĝe badania, jakie przeprowadziïem na potrzeby
tej ksiÈĝki, nie zostanÈ uznane za powaĝne studia naukowe przez sceptyków, którzy twier-
dzÈ, iĝ zwinne praktyki siÚ nie sprawdzajÈ, a branĝa powinna wróciÊ do „prawdziwej inĝy-
nierii oprogramowania”
1
. AkceptujÚ to. Zasoby, do jakich miaïem dostÚp podczas zbierania
materiaïów na potrzeby tego projektu, moĝna uznaÊ za niewystarczajÈce w porównaniu
z tym, czego wymaga siÚ od powaĝnych badañ naukowych. I nawet gdybym dysponowaï
zasobami speïniajÈcymi kryteria uznanych metodologii, to przecieĝ ani nie jestem naukow-
cem, ani nie zamierzam przedstawiaÊ siebie jako naukowca. Jestem praktykiem.
Kto powinien zapoznaÊ siÚ z tÈ ksiÈĝkÈ?
JeĂli tak jak ja jesteĂ praktykiem i zarabiasz na chleb, pracujÈc przy wytwarzaniu oprogra-
mowania lub wspierajÈc pracÚ nad oprogramowaniem, ta ksiÈĝka ma Ci wiele do zaofe-
rowania. Powstaïa wszak przede wszystkim z myĂlÈ o zespoïach, które staraïy siÚ wdroĝyÊ
w swoich Ărodowiskach zwinne praktyki, ale napotkaïy problemy wpïywajÈce niekorzystnie
na jakoĂÊ produktu koñcowego, zwiÚkszajÈce nakïad pracy i prowadzÈce do tego, ĝe dzieïo
rÈk programistów nie speïniaïo oczekiwañ klientów. (Tak… wówczas mamy do czynienia
1
JeĂli chcesz poznaÊ argumenty tych, którzy ïudzÈ siÚ, iĝ rygorystyczne podejĂcie do inĝynierii
oprogramowania przynosi korzyĂci, tak jak gdyby byïa to jakaĂ drugorzÚdna gaïÈě fizyki, zajrzyj na stronÚ
http://www.semat.org. Dobre kontrargumenty zawiera prezentacja Glenna Vanderburga zatytuïowana
Software Engineering Doesn’t Work!, z którÈ moĝna zapoznaÊ siÚ na stronie http://confreaks.net/videos/282-
lsrc2010-real-software-engineering.
Wprowadzenie
13
z prawdziwymi kïopotami i w takiej sytuacji zwykïa iteracja nie na wiele siÚ zda, poniewaĝ
staje siÚ „objazdem”, a nie rozwiÈzaniem problemu). Specyfikacja przez przykïady, zwinne
testowanie akceptacyjne, BDD i wszystkie alternatywne nazwy okreĂlajÈ ten sam proces,
zorientowany na rozwiÈzywanie tych problemów. Ta ksiÈĝka pomoĝe Ci poznaÊ podstawy
wspomnianych dobrych praktyk inĝynierii oprogramowania. Dowiesz siÚ z niej, jak moĝesz
mieÊ wiÚkszy pozytywny wpïyw na zespóï, niezaleĝnie od tego, czy jesteĂ testerem, dewelo-
perem, analitykiem, czy wïaĂcicielem produktu.
Jeszcze kilka lat temu wiÚkszoĂÊ ludzi, których spotykaïem na konferencjach, nigdy
wczeĂniej nie sïyszaïa o opisanych w tej ksiÈĝce praktykach. Gros tych, z którymi rozma-
wiam dziĂ, ma ĂwiadomoĂÊ istnienia wspomnianych praktyk, ale wielu z nich nie udaïo siÚ
wdroĝyÊ ich prawidïowo. Istnieje niewielka baza literatury fachowej traktujÈcej o proble-
mach, jakie napotykajÈ zespoïy podczas szeroko pojÚtego wdraĝania zwinnych praktyk, dla-
tego kaĝdy zniechÚcony zespóï stwierdza, ĝe jego przypadek musi byÊ wyjÈtkowy, a sfor-
malizowane koncepcje po prostu nie sprawdzajÈ siÚ w „jego Ăwiecie”. Ludzie z takich
zniechÚconych zespoïów dziwiÈ siÚ, jak po zaledwie piÚciu minutach rozmowy udaje mi siÚ
trafnie zidentyfikowaÊ ich trzy lub cztery najwiÚksze problemy. CzÚsto sÈ bardzo zdziwieni,
sïyszÈc, ĝe wiele innych zespoïów napotyka na swojej drodze te same przeszkody.
JeĂli pracujesz w takim zespole, ksiÈĝka, którÈ wïaĂnie trzymasz w dïoniach, uĂwiadomi
Ci przede wszystkim, ĝe nie jesteĂ sam. Zespoïy, z którymi rozmawiaïem podczas zbiera-
nia materiaïów do tej pozycji, wcale nie byïy zespoïami idealnymi. Takĝe one napotkaïy
na swojej drodze mnóstwo problemów! Jednak zamiast rezygnowaÊ po zderzeniu z murem
przeciwnoĂci, ludzie Ci postanowili go „objechaÊ” lub zburzyÊ. Taka ĂwiadomoĂÊ wspólnoty
czÚsto pozwala zobaczyÊ swoje problemy w innym Ăwietle. Mam nadziejÚ, ĝe po przeczy-
taniu tej ksiÈĝki bÚdziesz wïaĂnie jednÈ z tych wyjÈtkowych osób, które potrafiÈ spojrzeÊ na
sytuacjÚ z innej perspektywy.
JeĂli akurat znajdujesz siÚ w trakcie wdraĝania specyfikacji przez przykïady, ta ksiÈĝka
dostarczy Ci przydatnych wskazówek, dziÚki którym dowiesz siÚ, jak poradziÊ sobie z bieĝÈ-
cymi problemami i czego moĝesz spodziewaÊ siÚ w przyszïoĂci. Mam nadziejÚ, ĝe bÚdziesz
uczyÊ siÚ na bïÚdach innych ludzi i niektórych z nich uda Ci siÚ uniknÈÊ.
Ta ksiÈĝka zostaïa napisana takĝe z myĂlÈ o doĂwiadczonych praktykach, osobach, któ-
rym udaïo siÚ wdroĝenie zasad specyfikacji przez przykïady. Gdy zaczynaïem rejestrowanie
wywiadów z zespoïami, spodziewaïem siÚ, ĝe nie dowiem siÚ niczego nowego. MyĂlaïem, ĝe
„wiem, co jest grane”, i szukaïem tylko potwierdzenia. Tymczasem ostatecznie musiaïem
przyznaÊ, ĝe zaskoczyïo mnie to, jak wiele róĝnych pomysïów moĝna zastosowaÊ zaleĝnie
od kontekstu. Dowiadywaïem siÚ o rozwiÈzaniach, które wczeĂniej trudno mi byïo sobie
wyobraziÊ! Wiele siÚ przy tym nauczyïem. Dlatego mam nadziejÚ, ĝe i Ty, drogi Czytelniku,
wiele nauczysz siÚ dziÚki lekturze tej ksiÈĝki. Przedstawione w niej praktyki i pomysïy
powinny zainspirowaÊ CiÚ do wypróbowania alternatywnych rozwiÈzañ problemów i daÊ Ci
kilka podpowiedzi, jak usprawniÊ pracÚ zespoïu, gdy tylko natkniesz siÚ na historiÚ przypo-
minajÈcÈ jakiĂ opisany tu przykïad.
14
Specyfikacja na przykïadach
Co znajdziesz w Ărodku?
W pierwszej czÚĂci ksiÈĝki przedstawiÚ podstawy koncepcji specyfikacji przez przykïady.
Zamiast przekonywaÊ CiÚ do tego, byĂ przestrzegaï zasad opisanych w tej ksiÈĝce, pokaĝÚ
Ci — w sposób charakterystyczny dla metodyki specyfikacji przez przykïady — konkretne
korzyĂci, jakie zespoïy pracujÈce nad wytwarzaniem oprogramowania mogÈ uzyskaÊ dziÚki
zastosowaniu prezentowanych tu reguï. JeĂli zastanawiasz siÚ nad zakupem tej ksiÈĝki,
najpierw przejrzyj rozdziaï 1. i odpowiedz sobie na pytanie, czy którejĂ z opisanych tam
korzyĂci moĝna spodziewaÊ siÚ takĝe podczas realizacji Twojego projektu. W rozdziale 2.
przedstawiÚ najwaĝniejsze modele procesów i kluczowe artefakty specyfikacji przez przy-
kïady. W rozdziale 3. omówiÚ szczegóïowo koncepcjÚ ĝyjÈcej dokumentacji. W rozdziale 4.
przedstawiÚ typowe punkty wyjĂcia dla zainicjowania zmian procesu i kultury pracy zespoïu
oraz wskaĝÚ, na co naleĝy zwróciÊ uwagÚ podczas implementacji metodyki.
Jednym z moich celów jako autora tej ksiÈĝki jest stworzenie spójnego sïownika dla
wzorców, idei i artefaktów, który bÚdzie mógï byÊ stosowany podczas wdraĝania zasad
specyfikacji przez przykïady. W branĝy inĝynierii oprogramowania uĝywa siÚ tuzina róĝnych
terminów dla nazwania samej praktyki i dwa razy wiÚcej dla nazwania poszczególnych ele-
mentów kluczowych metodyki. Ludzie nazywajÈ ten sam element: plikami wïaĂciwoĂci,
przypadkami testowymi, plikami BDD, testami akceptacyjnymi itp. Z tego powodu w roz-
dziale 2. przedstawiÚ najlepsze (moim zdaniem) terminy stosowane dla okreĂlenia wszyst-
kich kluczowych elementów omawianej metodyki. Nawet jeĂli jesteĂ doĂwiadczonym prak-
tykiem, proponujÚ, ĝebyĂ zapoznaï siÚ z tym rozdziaïem i odpowiedziaï sobie na pytanie, czy
tak samo rozumiemy kluczowe terminy, wyraĝenia i wzorce, o których mówimy w tej ksiÈĝce.
W drugiej czÚĂci przedstawiÚ najistotniejsze praktyki, z których zespoïy opisane w stu-
diach przypadków korzystaïy, by wdroĝyÊ zasady specyfikacji przez przykïady. Zespoïy
dziaïajÈce w róĝnych Ărodowiskach podejmowaïy róĝnorakie decyzje — czasem diametralnie
róĝne, a czasami wrÚcz sprzeczne — aby jednak ostatecznie uzyskaÊ takie same efekty.
Opis tych praktyk uzupeïniÚ dodatkowo charakterystykÈ kontekstów, w których dziaïaïy
zespoïy podczas wdraĝania reguï specyfikacji przez przykïady. Siedem rozdziaïów drugiej
czÚĂci podzieliïem mniej wiÚcej zgodnie z podziaïem na obszary procesów.
W branĝy takiej jak inĝynieria oprogramowania nie istniejÈ uniwersalne, idealne roz-
wiÈzania, ale na pewno moĝna mówiÊ o dobrych pomysïach, które da siÚ zastosowaÊ ze
Ăwietnym skutkiem w róĝnych kontekstach. W drugiej czÚĂci tej ksiÈĝki znajdziesz ikonki
przedstawiajÈce kciuk uniesiony w górÚ lub skierowany w dóï. Takie grafiki bÚdÈ pojawiaÊ
siÚ przy nagïówkach z opisem dziaïañ, które badane zespoïy uznaïy za uĝyteczne, lub pro-
blemów, z którymi czÚsto musiaïy siÚ mierzyÊ. Potraktuj te wskazania jak propozycje wypró-
bowania przedstawionego przeze mnie rozwiÈzania lub ostrzeĝenie przed sytuacjÈ, jakiej
warto unikaÊ. Nie sÈ to w ĝadnym razie gotowe recepty, które naleĝy koniecznie zastoso-
waÊ. Ikony przedstawiajÈce strzaïki podkreĂlajÈ najistotniejsze koncepcje zwiÈzane z kaĝdym
z prezentowanych dziaïañ.
Wytwarzanie oprogramowania nie jest sztukÈ statycznÈ, poniewaĝ stale zmieniajÈ siÚ
zarówno zespoïy, jak i Ărodowiska, w których pracujÈ ludzie. Procesy rozwoju produktu
muszÈ nadÈĝaÊ za tymi zmianami. W czÚĂci trzeciej tej ksiÈĝki przedstawiÚ studia przypad-
Wprowadzenie
15
ków opisujÈce „podróĝe” kilku wybranych zespoïów. OmówiÚ procesy, ograniczenia i kon-
teksty, analizujÈc ewolucjÚ projektów. Przedstawione w tej czÚĂci historie pozwolÈ Ci lepiej
przygotowaÊ siÚ do czekajÈcych CiÚ zmian lub zachÚcÈ do wykonania nastÚpnego kroku,
pomogÈ w poszukiwaniach inspiracji, a takĝe zainspirujÈ do odkrywania nowych metod
dziaïañ i rozwiÈzañ.
W ostatnim rozdziale podsumujÚ najwaĝniejsze wnioski, do których doszedïem dziÚki
analizie licznych studiów przypadków zebranych na potrzeby tej ksiÈĝki.
CoĂ wiÚcej niĝ podstawy
Gdyby odwoïaÊ siÚ do tradycyjnego modelu doskonalenia
Shu-ha-ri
2
, ta ksiÈĝka znajduje siÚ
na poziomie
ha. Na tym etapie uczeñ ïamie obowiÈzujÈce zasady i dowiaduje siÚ, ĝe istnieje
wiele róĝnych sprawdzajÈcych siÚ modeli. Mój model i moje doĂwiadczenie przedstawiïem
w
Bridging the Communication Gap. Natomiast w ksiÈĝce, którÈ wïaĂnie trzymasz w dïoniach,
bardzo staram siÚ zachowaÊ obiektywne spojrzenie i uniknÈÊ ulegania wpïywom moich
dotychczasowych osobistych doĂwiadczeñ. O projektach, nad którymi pracowaïem osobiĂcie,
mówiÚ tylko wtedy, gdy naprawdÚ zaleĝy mi na przekazaniu waĝnych informacji, a ĝaden
z ankietowanych zespoïów nigdy nie zetknÈï siÚ z podobnÈ sytuacjÈ. W tym sensie specyfi-
kacja przez przykïady zaczyna siÚ tam, gdzie skoñczyïem
Bridging the Communication Gap.
Podstawowe zasady opisujÚ krótko w rozdziale 2. Nawet jeĂli nigdy wczeĂniej nie sïy-
szaïeĂ o ĝadnej z przedstawionych tam koncepcji, lektura tego rozdziaïu powinna zapewniÊ
Ci doĂÊ danych, ĝebyĂ mógï zrozumieÊ resztÚ ksiÈĝki. Staram siÚ przy tym nie zagïÚbiaÊ
za bardzo w podstawy. SzczegóïowÈ analizÚ fundamentów teorii specyfikacji przez przy-
kïady znajdziesz w
Bridging the Communication Gap i nie jest moim celem kopiowanie tych
informacji.
JeĂli chcesz poszerzyÊ swojÈ wiedzÚ w zakresie podstaw, zajrzyj na stronÚ
http://
specificationbyexample.com, zarejestruj posiadany egzemplarz tej ksiÈĝki, a otrzymasz za darmo
plik PDF z
Bridging the Communication Gap.
Nie sÈdzÚ, ĝe kiedykolwiek powstanie kontynuacja tej pozycji — to znaczy ksiÈĝka
mojego autorstwa na poziomie
ri — poniewaĝ moim zdaniem poziom ten jest w ogóle nie-
osiÈgalny dla ksiÈĝek. Z drugiej strony wierzÚ, ĝe ta ksiÈĝka pomoĝe Ci przejĂÊ na wyĝ-
szy poziom. Gdy zaczniesz rozumieÊ, ĝe wybór konkretnego narzÚdzia nie ma znaczenia,
bÚdzie to znaczyïo, ĝe znalazïeĂ siÚ na poziomie
ri.
2
Shu-ha-ri to model doskonalenia zwiÈzany z naukÈ aikido. Shu-ha-ri znaczy mniej wiÚcej tyle co:
podporzÈdkuj siÚ – zerwij – odejdě. Na pierwszym poziomie (shu — podporzÈdkuj siÚ) uczeñ zdobywa wiedzÚ,
pilnie naĂladujÈc przedstawiony mu model. Na drugim poziomie (
ha — zerwij) uczeñ dowiaduje siÚ, ĝe
istniejÈ inne modele i rozwiÈzania. Na trzecim poziomie (
ri — odejdě) uczeñ przekracza granicÚ, wychodzÈc
poza dziaïania polegajÈce na bezrefleksyjnym powtarzaniu znanych rozwiÈzañ.
16
Specyfikacja na przykïadach
Ta ksiÈĝka nie zawiera kodu ěródïowego
i nie wyjaĂnia dziaïania ĝadnych narzÚdzi
Nie znajdziesz w tej ksiÈĝce kodu ěródïowego
ani instrukcji opisujÈcych, jak uĝyÊ konkretnego
narzÚdzia. CzujÚ siÚ zobligowany do uprzedze-
nia o tym juĝ teraz, poniewaĝ nawet w trakcie
trwania procesu wydawniczego byïem zmu-
szony do skïadania wyjaĂnieñ w tej kwestii
(zwykle chodziïo o odpowiedě na pytanie: „Co
wïaĂciwie masz na myĂli? KsiÈĝka o programo-
waniu bez kodu ěródïowego? Jak to moĝliwe?”).
Zasady i praktyki specyfikacji przez przykïady wpïywajÈ przede
wszystkim na sposób komunikacji miÚdzyludzkiej w zespoïach pracu-
jÈcych nad dostarczaniem oprogramowania, a takĝe na wspóïpracÚ
zespoïów z uĝytkownikami biznesowymi i interesariuszami (ang.
stakeholders). Jestem pewien,
ĝe wielu sprzedawców narzÚdzi informatycznych bÚdzie próbowaÊ sprzedaÊ Ci gotowe roz-
wiÈzania. Z kolei wielu menedĝerów chÚtnie nawet zapïaciïoby za to, aby ktoĂ sprawiï, ĝeby
ich problem po prostu zniknÈï. Niestety mamy do czynienia przede wszystkim z problemem
ludzkim, a nie technicznym.
Bill Gates mawiaï: „PierwszÈ zasadÈ dotyczÈcÈ wszelkich technologii wykorzystywa-
nych w dziaïalnoĂci gospodarczej jest to, ĝe zautomatyzowanie skutecznego dziaïania potÚ-
guje efektywnoĂÊ. Druga zasada mówi, ĝe automatyzacja zastosowana do nieefektywnego
dziaïania zwiÚksza poziom nieskutecznoĂci”. Wiele zespoïów, którym nie udaïo siÚ poprawne
wdroĝenie specyfikacji przez przykïady, powiÚkszyïo swojÈ nieefektywnoĂÊ poprzez auto-
matyzacjÚ dotychczasowych (niepoprawnych) praktyk. Zamiast wiÚc skupiaÊ siÚ na konkret-
nym narzÚdziu, chcÚ zaproponowaÊ rozwiÈzanie problemów, które sÈ prawdziwÈ przyczynÈ
niepowodzeñ. JeĂli tylko uda Ci siÚ zapanowaÊ nad komunikacjÈ i ustaliÊ zasady wspóïpracy,
przyjdzie czas na wybranie odpowiednio dopasowanego narzÚdzia. JeĂli po przeczytaniu tej
ksiÈĝki bÚdziesz chciaï poszerzyÊ swojÈ wiedzÚ na temat narzÚdzi, które wspierajÈ wdroĝe-
nie specyfikacji przez przykïady, odwiedě stronÚ
http://specificationbyexample.com i przejrzyj
znajdujÈce siÚ tam zasoby.
Kilka sïów na temat terminologii
JeĂli jest to Twój pierwszy kontakt ze specyfikacjÈ przez przykïady, ATDD, ze zwinnymi tes-
tami akceptacyjnymi, BDD czy z którymkolwiek z terminów, których ludzie uĝywajÈ na
okreĂlenie zbioru praktyk bÚdÈcego podstawowym tematem tej ksiÈĝki, oznacza to, ĝe udaïo
Ci siÚ uniknÈÊ wielu lat zamieszania spowodowanego powielaniem i kreowaniem mylÈcych
nazw. PowinieneĂ siÚ z tego ucieszyÊ i moĝesz pominÈÊ tÚ czÚĂÊ wprowadzenia. JeĂli jednak
zetknÈïeĂ siÚ kiedyĂ z którymkolwiek z wymienionych terminów, okreĂlenia uĝywane przeze
mnie w tej ksiÈĝce mogÈ CiÚ zaskoczyÊ. Za chwilÚ wyjaĂniÚ, dlaczego wybraïem te, a nie inne
terminy, i dlaczego uwaĝam, ĝe Ty takĝe powinieneĂ zaczÈÊ z nich korzystaÊ.
Wprowadzenie
17
Podczas prac nad tÈ ksiÈĝkÈ borykaïem siÚ z problemami, które nie sÈ obce wszystkim
praktykom piszÈcym na temat zautomatyzowanych specyfikacji. JeĂli terminologia ma mieÊ
sens, musi byÊ spójna. CzÚsto rozumiemy to dopiero wtedy, gdy sami zabieramy siÚ do opisa-
nia jakiegoĂ zagadnienia. Poniewaĝ moja ksiÈĝka jest produktem bazujÈcym na cyklu wywia-
dów, a wiele osób, z którymi rozmawiaïem, uĝywaïo róĝnych terminów do nazwania tej samej
rzeczy, uzyskanie spójnoĂci terminologicznej okazaïo siÚ zadaniem niezwykle trudnym.
Zdaïem sobie sprawÚ, ĝe specjaliĂci realizujÈcy reguïy specyfikacji przez przykïady
w praktyce — na czele ze mnÈ — sami sÈ sobie winni, bo to przecieĝ oni uĝywajÈ zdradli-
wych terminów technicznych, wprowadzajÈcych w bïÈd nie tylko ich samych, ale i wszystkich
tych, którzy próbowali wdroĝyÊ owe praktyki. Wtedy zdecydowaïem, ĝe jednym z celów tej
ksiÈĝki bÚdzie opracowanie spójnej terminologii, którÈ bÚdÈ mogli posïugiwaÊ siÚ wszyscy
czïonkowie spoïecznoĂci wytwórców oprogramowania. JeĂli zaleĝy nam na wiÚkszym zaan-
gaĝowaniu w prace projektowe uĝytkowników biznesowych — co jest przecieĝ jednym
z naszych gïównych celów — musimy zaczÈÊ uĝywaÊ wïaĂciwych terminów do nazwania
wïaĂciwych rzeczy. Czas przestaÊ wprowadzaÊ zamieszanie!
Doskonale rozumiemy potrzebÚ zachowania spójnoĂci, gdy tworzymy specyfikacje.
Wiemy, ĝe musimy zachowaÊ powtarzalnoĂÊ terminów i unikaÊ wprowadzania pojÚÊ nie-
jednoznacznych. Tyle ĝe jakoĂ zapominamy o tym, gdy zaczynamy mówiÊ o procesach.
Na przykïad gdy mówimy o
ciÈgïej integracji w kontekĂcie specyfikacji przez przykïady, tak
naprawdÚ wcale nie chodzi nam o wykonywanie testów integracyjnych. Dlaczego wiÚc
mielibyĂmy uĝywaÊ tego terminu, a nastÚpnie wyjaĂniaÊ, czym róĝniÈ siÚ testy akceptacyjne
od testów integracyjnych? Zanim sam nie zaczÈïem uĝywaÊ terminu
warsztat specyfikacji do
nazwania spotkania, w którym uczestniczÈ osoby odpowiedzialne za wspólne opracowanie
testów akceptacyjnych, miaïem spore trudnoĂci, aby przekonaÊ uĝytkowników biznesowych
do udziaïu w takich zgromadzeniach. Zwykïa zmiana nazwy sprawiïa, ĝe problem przestaï
istnieÊ. DziÚki uĝyciu lepszego glosariusza terminologicznego moĝna uniknÈÊ zupeïnie bez-
sensownych dysput, sprawiajÈc, ĝe wszyscy dobrze siÚ rozumiejÈ.
Dlaczego specyfikacja przez przykïady?
W pierwszej kolejnoĂci chciaïbym wyjaĂniÊ, dlaczego wybraïem termin „specyfikacja przez
przykïady” dla nazwania zbioru praktyk. Dlaczego nie zwinne testowanie akceptacyjne,
BDD czy ATDD?
Podczas konferencji „Domain Driven Design eXchange”, która odbyïa siÚ w 2010 roku
w Londynie
3
, Eric Evans stwierdziï, ĝe termin
zwinny (ang. agile) straciï juĝ wszelkie zna-
czenie, bo obecnie wszystko moĝna nazwaÊ zwinnym. Niestety Eric ma racjÚ. Widziaïem
o wiele za duĝo zespoïów, próbujÈcych wdroĝyÊ proces, który nie miaï szans zakoñczenia siÚ
powodzeniem, choÊ wszystkim wydawaïo siÚ, ĝe etykietka
agile w jakiĂ magiczny sposób
sprawi, ĝe okaĝe siÚ skuteczniejszy, niĝ byï w rzeczywistoĂci. Przecieĝ mamy do swojej dyspo-
zycji ogromnÈ bibliotekÚ dostÚpnego piĂmiennictwa omawiajÈcego prawidïowe wdraĝanie
zasad programowania ekstremalnego, Scruma czy innych mniej popularnych procesów
z bogatego wachlarza praktyk zwinnych.
3
http://skillsmatter.com/event/design-architecture/ddd-exchange-2010.
18
Specyfikacja na przykïadach
Aby odejĂÊ od tych wprowadzajÈcych zamieszanie niejasnoĂci oraz dyskusji na temat
tego, czy zwinne praktyki siÚ sprawdzajÈ, czy nie (i wyjaĂniÊ, co to wïaĂciwie znaczy
byÊ
agile), w tej ksiÈĝce staram siÚ ze wszystkich siï unikaÊ terminu zwinny. Uĝywam go tylko
wtedy, gdy nawiÈzujÚ do zespoïów, które rozpoczÚïy realizacjÚ dobrze zdefiniowanych proce-
sów zbudowanych na zasadach okreĂlonych w ManifeĂcie Agile. Tak wiÚc w sytuacji, gdy nie
mogÚ umieĂciÊ wtrÚtu ze sïowem „agile” w co drugim moim zdaniu, uĝycie terminu „zwinne
testowanie akceptacyjne” jest po prostu nie do przyjÚcia.
Opisane w tej ksiÈĝce praktyki nie stanowiÈ kompletnej metodyki tworzenia oprogra-
mowania. SÈ za to uzupeïnieniem innych metod — zarówno tych bazujÈcych na iteracji, jak
i na przepïywach — zapewniajÈc dyscyplinÚ specyfikacji i testów, poprawiajÈc komunikacjÚ
miÚdzy interesariuszami i czïonkami zespoïów deweloperskich, ograniczajÈc liczbÚ zbÚdnych
przeróbek i uïatwiajÈc wprowadzanie zmian. Nie chcÚ zatem uĝywaÊ ĝadnego terminu
zawierajÈcego element „Driven Development” (a zwïaszcza
Behavior-Driven Development —
BDD). Nie chodzi o to, ĝe mam coĂ przeciwko BDD. WrÚcz przeciwnie! Kocham BDD
i uwaĝam, ĝe wiÚkszoĂÊ z tego, co znajdziesz w tej ksiÈĝce, w rzeczywistoĂci stanowi klu-
czowy element BDD. Ale BDD równieĝ jest ofiarÈ problemu z nazewnictwem.
Znaczenie terminu BDD podlega ciÈgïym zmianom. Dan North, najwiÚkszy autory-
tet w kwestii metodyki BDD oraz czïowiek, który jako jeden z niewielu ma prawo decydo-
waÊ, czym jest i czym nie jest BDD, stwierdziï podczas konferencji „Agile Specifications,
BDD and Testing Exchange” w 2009 roku, ĝe BDD jest
metodykÈ
4
. (A dokïadniej powiedziaï,
ĝe BDD jest: „zwinnÈ metodykÈ drugiej generacji, typu
outside-in, pull-based, multiple-
stakeholder, multiple-scale, high-automation”). Aby uniknÈÊ nieporozumieñ i niejasnoĂci w kwe-
stii róĝnicy pomiÚdzy definicjÈ BDD zaproponowanÈ przez Dana Northa a tym, co ja sam
uwaĝam za BDD, rezygnujÚ ze stosowania takĝe tego terminu. Ta ksiÈĝka mówi o precy-
zyjnie zdefiniowanym zestawie praktyk, które moĝna stosowaÊ w ramach róĝnych metod,
w tym równieĝ metodyki takiej jak BDD (jeĂli przyjÈÊ, ĝe BDD naprawdÚ jest metodykÈ).
Chciaïbym równieĝ uniknÈÊ naduĝywania terminu
test. Wielu menedĝerów i uĝytkow-
ników biznesowych niestety uwaĝa testy za aktywnoĂÊ uzupeïniajÈcÈ o czysto technicznej
naturze, a nie coĂ, w czym chcieliby braÊ udziaï. Przecieĝ majÈ od tego wyspecjalizowanych
testerów! Specyfikacja przez przykïady wymaga aktywnego uczestnictwa interesariuszy
i czïonków zespoïu dostarczajÈcego oprogramowanie, wïÈcznie z deweloperami, testerami
i analitykami. JeĂli nie moĝemy naduĝywaÊ terminu
test, trudno mówiÊ o testowaniu history-
jek, zwinnym testowaniu akceptacyjnym i posïugiwaÊ siÚ innymi, podobnymi okreĂleniami.
W ten oto sposób doszliĂmy do terminu specyfikacja przez przykïady, który staje siÚ
najsensowniejszym wyborem, poniewaĝ niesie najmniejszy bagaĝ negatywnych konotacji.
Wzorce procesów
Na model specyfikacji przez przykïady skïada siÚ kilka wzorców procesów, tj. etapów cyklu
ĝyciowego procesu wytwarzania oprogramowania, definiowanych w nieco szerszej perspek-
tywie. Terminy, których uĝywam w tej ksiÈĝce w kontekĂcie specyfikacji przez przykïady,
4
http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business
.
Skorowidz
A
analitycy, 121
analiza
kaskadowa, 78
wstÚpna, 123
aplikacje typu back-office, 102, 230
ATDD, Acceptance Test-Driven
Development, 11, 55, 116
automatyzacja
elementów systemu, 68
interfejsu uĝytkownika, 183
scenariuszy, 79
testów, 20, 66, 74
walidacji specyfikacji, 169,
172, 194
wykonywalnych specyfikacji,
69, 72, 177, 232
zmiany zegara, 208
B
BDD, Behavior-Driven
Development, 11, 18, 55
biblioteki
automatyzacji interfejsu
uĝytkownika, 184
automatyzacyjne przeglÈdarki,
184
bumerang, 88
C
cel biznesowy, 50, 94
zakres prac, 45
chirurgia ĂrutówkÈ, 90
CI, continuous integration, 195
ciÈgïa
integracja, CI, 195, 213
walidacja, 199
CRUD, Create, Read, Update,
Delete, 96
czas reakcji, 141
D
dane
referencyjne, 192, 193
testowe, 191
DDE, 80
dedykowane Ărodowisko testowe, 200
definicje kroków, step definitions, 170
definiowanie
historyjek, 100
wymagañ, 283
zakresu, 19, 93, 95
mapowanie efektu, 105
mapowanie historyjki
uĝytkownika, 105
wstrzykiwanie
funkcjonalnoĂci, 19, 105
demo produktu, 79
dokumentacja, 29, 49, 56, 219
dokumentowanie procesów
biznesowych, 286
dzielenie testów, 211
E
EDT, Example-Driven
Development, 11
efektywne dostarczanie
oprogramowania, 276
eksperci, 121
F
feature injection, 19, 105
feedback, 77, 78
fikstury, fixtures, 170
fikstury testowe, 181
formuïowanie celów, 99
formy wspóïpracy, 285
funkcjonalnoĂÊ
biznesowa, 154
interfejsu uĝytkownika, 186, 188
G
gromadzenie wiedzy, 147
grupowanie
nieudanych testów, 215
specyfikacji, 229
H
hierarchia systemu ĝyjÈcej
dokumentacji, 229
historyjki, 78–81, 95, 101, 228
I
identyfikowalnoĂÊ wymagañ, 83
ilustrowanie wymagañ
niefunkcjonalnych, 140
informacja zwrotna, 207
inicjowanie zmian, 63
integracja zespoïów
multidyscyplinarnych, 78
interfejs uĝytkownika, 141, 157
automatyzacja, 184
funkcjonalnoĂÊ, 186, 188
poziomy automatyzacji, 190
test, 185, 188
iteracje, 80, 81
J
jÚzyk
specyfikacji, 223, 224
wszechobecny, Ubiquitous
Language, 165
K
kamienie milowe, 84
Kanban, 30
klasy równowaĝnoĂci, 132
kod automatyzacji, 178
komunikacja w zespole, 242
koncepcje wyĝszego poziomu, 221
konsultant, 173
kontekst w bazie danych, 189
kontrola
jakoĂciowa, QA, 114
wersji, 83
koszt
automatyzacji, 171
utrzymania wykonywalnych
specyfikacji, 170
kryteria akceptacji, 250
294
Skorowidz
L
lista kontrolna, 143, 144
logika biznesowa, 180, 182
M
mapowanie
efektu, 105
historyjki uĝytkownika, 105
menedĝer produktu, 136
metadane, 250
metaprogramowanie, 119
metodyka scrumowa, 81
metodyki zwinne, 65
migracja, 75
minimalne zbywalne wïaĂciwoĂci, 99
model
ATDD, 55
BDD, 55
QUPER, 142
tradycyjny, 28
ZakïadajÈc/Jeĝeli/Wtedy,
163, 168
zorientowany na
dokumentacjÚ, 60
modele wspóïpracy, 109, 124
modyfikacja przykïadów, 138
N
narzÚdzia, 290
do automatyzacji, 84, 172
specyfikacji, 170
testów, 182
monitorujÈce, 77
open source, 259
narzÚdzie
Balsamiq Mockups, 142
Cucumber, 84
FIT, 171, 261
FitNesse, 262, 272
niedopasowanie organizacyjne, 88
O
odchudzone wytwarzanie
oprogramowania, 95
opis, 154
procesów walidacji, 179, 180
testów akceptacyjnych, 154
optymalizacja
praktyk testowania, 87
procesu, 240
organizacja warsztatów
specyfikacji, 111
P
PBR, Product Backlog
Refinement, 111
planowanie automatyzacji, 173
podziaï historyjek, 104
poprawa jakoĂci, 65
powielanie logiki biznesowej, 180
poziom
przepïywu pracy
uĝytkownika, 190
reguï biznesowych, 190
techniczny aktywnoĂci, 190
priorytetyzacja, 98, 244
priorytetyzacja historyjek, 118
proces
asynchroniczny, 206
konfiguracji, 238
RUP, 86
wytwarzania
oprogramowania, 245
programiĂci, 121
programowanie
ekstremalne, XP, 30, 195
w parach, 113
projekt
typu brownfield, 34
typu greenfield, 34, 199
projektowanie testów, 270
projekty oparte na danych, 266
przepïyw procesu, 183
przetwarzanie asynchroniczne, 204
przykïady
funkcjonalne, 142
kompletne, 133
podstawowe, 161
przypadków brzegowych, 138
realistyczne, 134, 136
referencyjne, 144, 145
reprezentatywne, 159
wymagañ funkcjonalnych, 140
zrozumiaïe, 137
przypadki
brzegowe, 239
uĝycia, use cases, 85, 86
Q
QA, 114
QUPER, 142
R
realizacje przypadków uĝycia, 86
refaktoryzacja, 186
refaktoryzacja specyfikacji, 87
reguïy biznesowe, 87
reorganizacja
pracy, 104
warstwy automatyki, 187
restrukturyzacja skryptów, 154
rola Batmana, 76
rozwiÈzania alternatywne, 103
RUP, Rational Unified Process, 86
rzucanie wyzwania wymaganiom, 96
S
SBE, Specification by Example, 65
Scrum, 30
SKIT, 79
skrypt, 152
skrypty testów rÚcznych, 175
sïownik jÚzyka specyfikacji, 225
specyfikacja, 45, 107, 147–168
dobra, 149
domyĂlne wartoĂci, 164
funkcjonalnoĂÊ biznesowa, 154
implementacja
oprogramowania, 155
integralnoĂÊ referencyjna, 163
interfejs uĝytkownika, 157
jedna reguïa biznesowa, 161
jÚzyk domeny, 165
oczekiwane wyniki, 158
reprezentatywne przykïady, 159
trudnoĂci techniczne, 156
udoskonalanie, 20, 147–168
utrzymywanie, 61
wartoĂci wejĂciowe, 158
wdraĝanie, 147
zïa, 150
specyfikacja przez przykïady, 11,
20, 28–30, 54, 61, 75, 78
dostosowanie aktywnoĂci, 39
identyfikowalnoĂÊ, 82
jakoĂÊ produktu, 32
wdraĝanie, 74
wprowadzanie zmian, 30
zatwierdzenia, 82
znajdowanie bïÚdów, 36
specyfikacje
grupowane, 229
rozbudowane, 220
wykonywalne, 20, 48, 53, 58
Skorowidz
295
spike, 172
spotkanie
ATDD, 116
przygotowawcze, 117
trzech amigos, 112
z interesariuszami, 119
spójnoĂÊ ĝyjÈcej dokumentacji, 223
sprawdzanie
logiki biznesowej, 182
testu, 87
funkcjonalnoĂci, 133
stabilnoĂÊ automatycznych testów,
198
studia przypadków, 235
system kontroli wersji, 84
systemy zewnÚtrzne, 202
szacowanie historyjek, 99
¥
Ăledzenie
bumerangów, 88
procesu przepïywu, 182
przebiegu zatwierdzeñ
wymagañ, 82
T
tablica Kanban, 78
TDD, 70
test, 50
akceptacyjny, 50, 100, 196
automatyczny, 57
Cucumbera, 239, 244
first, 19
FitNesse, 269
funkcjonalny, 66, 74
integracyjny, 206, 207
jednostkowy, 196
niefunkcjonujÈcy, 69
nieudany, 215, 216
niskiego poziomu, 104
regresji, 215
równolegïy, 183, 212
sanity testing, 263
szybki, 210
techniczny, 155
typu end-to-end, 207
wolny, 210
wyĝszego poziomu, 104
testerzy, 120, 279
testowanie
baz danych, 209
danych referencyjnych, 204
interfejsu uĝytkownika, 176,
185, 188
przez historyjki uĝytkownika,
11
regresyjne, 50
specyfikacji wykonywalnej,
157
w chmurze, 213
w transakcjach, 203
timing, 44
transakcje, 203
tworzenie
baz danych, 191
dokumentacji, 49, 55–62, 219
strony internetowe, 60
testy automatyczne, 57
wykonywalna
specyfikacja, 58
dublera systemu, 201
procesu przepïywu, 82
przykïadów, 127
specyfikacji, 46, 107, 147–168
przykïady ilustrujÈce, 130
U
UAT, User Acceptance Testing, 35
udoskonalanie specyfikacji, 20,
147–168
utrzymywanie specyfikacji, 61
uĝytecznoĂÊ, 141, 144
uĝytkownik biznesowy, 99
uĝywanie znaczników, 231
W
walidacja, 20, 47, 49, 195
procesów asynchronicznych, 204
specyfikacji, 169, 172
typu end-to-end, 206
wielostopniowa, 202
warstwa
automatyzacji, 163, 178, 179
interfejsu uĝytkownika, 183
warsztaty
PBR, 111
specyfikacji, 110, 116, 239
wartoĂÊ, 98
wdraĝanie
specyfikacji, 147
zasady wspóïpracy, 77
wersje oprogramowania, 73
wïaĂciciel produktu, 118
wsparcie kierownictwa, 72
wspomaganie definiowania
zakresu, 105
wspóïpraca, 109, 116, 263,
283–285
wstrzykiwanie funkcjonalnoĂci,
feature injection, 19, 105
wybór
modelu wspóïpracy, 124
zakresu automatyzacji, 185
wydajnoĂÊ, 140
wymagania
interesariuszy, 136
niefunkcjonalne, 140, 141
przekrojowe, 144
wydajnoĂciowe, 140
wzorce
kluczowych procesów, 43, 44
procesu specyfikacji, 54
X
XP, Extreme Programming, 30
Z
zaangaĝowanie interesariuszy,
118, 119
zakres
automatyzacji, 185
implementacji, 45
projektu, 93
zamkniÚte odpowiedzi, 131
zarzÈdzanie
danymi testowymi, 191
testami, 197, 214
warstwÈ automatyzacji, 178
wymaganiami, 257
zastÚpowanie specyfikacji, 221
zatwierdzanie, 82
zatwierdzenie przypadków uĝycia,
85
zaufanie, 283
zespóï
Knighta, 136
Andrew Jackmana, 114
Bekk Consulting, 163
Clare McLennan, 198
ePlan Services, 267–273
Global Talent Management,
77, 83
Google, 87
Iana Coopera, 154, 202
296
Skorowidz
zespóï
Iowa Student Loan, 216,
253–259
Jodie Parker, 123
Marty Gonzalez Ferrero, 128
Pierre’a Veragena, 189
QA, 238
RainStor, 211, 247–252
Rakesha Patela, 220
Roba Parka, 201
Sabre Airline Solutions,
261–266
Sierra, 80, 120, 226
SNS, 81, 83
Songkick, 275–281
Steera, 86
Stuarta Taylora, 113
TechTalk, 131
uSwitch, 100, 173, 214,
237–246
zestawy testów, 208
zmiana procesu, 64
zmniejszanie zawodnoĂci, 197
znaczniki, 231
zwiÚkszanie niezawodnoĂci
systemu, 198
zwinne testowanie akceptacyjne,
11, 18
½
ěródïa wartoĂci, 98
¿
ĝyjÈca dokumentacja, 30, 53–62,
270, 287
hierarchia, 229
jako przewaga konkurencyjna,
258
ïatwy dostÚp, 219, 227
spójny jÚzyk, 223
utrzymywanie, 233
Wyszukiwarka
Podobne podstrony:
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie speprz 2
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie 2
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie speprz
METODA INDYWIDUALNEGO PRZYPADKU - na przykładzie, Pomoc Społeczna, Metody i techniki badań
Na przykładzie konkretnego stanowiska pracy oceń ryzyko zawodowe Przedstaw zastosowane kryteria meto
Poznajemy praktyczne ćwiczenia i metody korelacji między dyscyplinami sportowymi na przykładzie piłk
Metody pracy opiekuńczo wychowawczej- wykłady(1), pedagogika, wszystko razem - na pewno przydatne na
MB2 Automatyzacja pracy maszyn roboczych na przykładzie koparki podsiębiernej ogarnijtemat com (
Metody pracy z uczniem o specyficznych trudnościach 2, specyficzne trudności w uczeniu się, SPE
materiały na egzamin, Egzamin Metody, Egzamin Metody pracy hodowlanej:
na metodyke, Studia-PEDAGOGIKA, PEDAGOGIKA III ROK(resocjalizacyjna), metodyka pracy w środowisku ot
pem1-cw1-metody pomiarowe na przykładzie pomiaru masy , Grupa 11 zespół 2
Metodyka Pracy Resocjalizacyjnej, Notatki na studia
materiały na egzamin, egzamin, opr by offca, METODY PRACY HODOWLANEJ - Pytania na egzamin:
Analiza wybranych problemów kształtowania środowiska pracy (na przykładzie nauczycieli), Moje prace
więcej podobnych podstron