Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie

background image
background image

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.

Kup książkę

Poleć książkę

Oceń książkę

Księgarnia internetowa

Lubię to! » Nasza społeczność

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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
.

Kup książkę

Poleć książkę

background image

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.

Kup książkę

Poleć książkę

background image

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-

Kup książkę

Poleć książkę

background image

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 (shupodporzÈdkuj siÚ) uczeñ zdobywa wiedzÚ,
pilnie naĂladujÈc przedstawiony mu model. Na drugim poziomie (

hazerwij) uczeñ dowiaduje siÚ, ĝe

istniejÈ inne modele i rozwiÈzania. Na trzecim poziomie (

riodejdě) uczeñ przekracza granicÚ, wychodzÈc

poza dziaïania polegajÈce na bezrefleksyjnym powtarzaniu znanych rozwiÈzañ.

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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.

Kup książkę

Poleć książkę

background image

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

.

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image

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

Kup książkę

Poleć książkę

background image
background image

Wyszukiwarka

Podobne podstrony:
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie
Specyfikacja na przykladach Poznaj zwinne metody pracy i dostarczaj wlasciwe oprogramowanie speprz 2
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