Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00148 010449 11038677 na godz. na dobę w sumie
Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie - książka
Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie - książka
Autor: Liczba stron: 296
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-9118-0 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Skutecznie zbieraj wymagania!

Dokładne poznanie wymagań klienta to klucz do w pełni wydajnej aplikacji. Jest niezbędne, by sprostać oczekiwaniom jej przyszłych użytkowników. Metoda SBE (skrót od ang. specification by example) zachęca do zwinnego (agile) podejścia do tego tematu, dzięki czemu zebranie wymagań będzie przebiegało zdecydowanie sprawniej.

Ta książka rozwieje wszystkie Twoje wątpliwości! Poznasz kluczowe wzorce procesu oraz nauczysz się wprowadzać w nich zmiany. Podejście SBE wymaga zmiany kultury pracy zespołu. Nie jest to zadanie łatwe, dlatego znajdziesz tu najlepsze praktyki stosowane w tej sytuacji. Ostatnie rozdziały książki zostały poświęcone omówieniu przykładów z życia wziętych, a dotyczących najczęściej spotykanych problemów. To szczególnie cenne informacje, które pozwolą Ci wybrać najlepsze sposoby uniknięcia typowych błędów. Książka ta jest obowiązkową lekturą dla wszystkich twórców oprogramowania!

Dzięki tej książce:

Poznaj zalety SBE!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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ść Spis tre(cid:258)ci Wprowadzenie 11 Podzi(cid:218)kowania 22 O autorze 23 O ilustracji na ok(cid:239)adce 24 CZ(cid:125)(cid:165)(cid:109) I Zaczynamy! 1 Kluczowe korzy(cid:258)ci 27 Sprawniejsze wprowadzanie zmian .............................................................................................. 30 Wy(cid:285)sza jako(cid:258)(cid:202) produktu ............................................................................................................... 32 Mniej przeróbek ............................................................................................................................ 36 Lepsze dostosowanie aktywno(cid:258)ci ................................................................................................. 39 Pami(cid:218)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(cid:239)adów ilustruj(cid:200)cych .............................................................. 46 Udoskonalanie specyfikacji .......................................................................................................... 47 Automatyzacja walidacji bez zmiany specyfikacji ........................................................................ 47 Cz(cid:218)sta walidacja ........................................................................................................................... 49 Tworzenie systemu dokumentacji ................................................................................................. 49 Praktyczny przyk(cid:239)ad ...................................................................................................................... 50 Cel biznesowy ............................................................................................................................... 50 Przyk(cid:239)ad poprawnego celu biznesowego .............................................................................................51 Zakres ........................................................................................................................................... 51 Historyjki u(cid:285)ytkowników podstawowego elementu systemu lojalno(cid:258)ciowego .......................................51 Kluczowe przyk(cid:239)ady ....................................................................................................................... 51 Kluczowe przyk(cid:239)ady: Darmowa dostawa ..............................................................................................52 Specyfikacja z przyk(cid:239)adami .......................................................................................................... 52 Darmowa dostawa ..............................................................................................................................52 Przyk(cid:239)ady ............................................................................................................................................53 Wykonywalna specyfikacja ........................................................................................................... 53 (cid:191)yj(cid:200)ca dokumentacja .................................................................................................................... 53 Pami(cid:218)taj ........................................................................................................................................ 54 (cid:191)yj(cid:200)ca dokumentacja 55 Dlaczego potrzebujemy pewnej dokumentacji? ............................................................................ 56 Testy mog(cid:200) by(cid:202) dobr(cid:200) dokumentacj(cid:200) ........................................................................................... 57 Tworzenie dokumentacji na podstawie wykonywalnej specyfikacji ............................................. 58 Zalety modelu zorientowanego na dokumentacj(cid:218) ......................................................................... 60 Pami(cid:218)taj ........................................................................................................................................ 61 3 Kup książkęPoleć książkę 4 Spis tre(cid:258)ci 4 Inicjowanie zmian 63 Jak rozpocz(cid:200)(cid:202) zmian(cid:218) procesu? ................................................................................................... 64 Wdra(cid:285)aj specyfikacj(cid:218) przez przyk(cid:239)ady jako cz(cid:218)(cid:258)(cid:202) rozleg(cid:239)ego procesu zmian .........................................65 Kiedy: W projektach typu greenfield .............................................................................................65 Skup si(cid:218) na poprawie jako(cid:258)ci ..............................................................................................................65 Zacznij od automatyzacji testów funkcjonalnych ..................................................................................66 Kiedy: Zmiany dotycz(cid:200) istniej(cid:200)cego projektu .................................................................................66 Wprowad(cid:283) narz(cid:218)dzie do wykonywalnych specyfikacji ..........................................................................68 Kiedy: Zale(cid:285)nie od potrzeb w(cid:239)asnych testerów ..............................................................................68 Wykorzystaj TDD jako odskoczni(cid:218) .......................................................................................................70 Kiedy: Deweloperzy maj(cid:200) du(cid:285)(cid:200) wiedz(cid:218) na temat TDD ...................................................................70 Jak zacz(cid:200)(cid:202) zmienia(cid:202) kultur(cid:218) zespo(cid:239)u? .......................................................................................... 70 Unikaj u(cid:285)ywania terminów sugeruj(cid:200)cych zwinno(cid:258)(cid:202) lub bycie „agile” ....................................................70 Kiedy: Pracujesz w (cid:258)rodowisku opornym na zmiany .....................................................................70 Zadbaj o uzyskanie wsparcia kierownictwa ..........................................................................................72 Sprzedaj specyfikacj(cid:218) przez przyk(cid:239)ady jako lepsz(cid:200) metod(cid:218) wykonywania testów akceptacyjnych .........73 Niech automatyzacja testów nie b(cid:218)dzie celem ko(cid:241)cowym ...................................................................74 Nie koncentruj si(cid:218) wy(cid:239)(cid:200)cznie na narz(cid:218)dziu ...........................................................................................75 W czasie migracji niech jedna osoba ci(cid:200)gle pracuje nad starszymi skryptami ......................................75 Kiedy: Wprowadzasz automatyzacj(cid:218) funkcjonaln(cid:200) do istniej(cid:200)cych systemów ...............................75 Sprawdzaj, kto wykonuje testy automatyczne ......................................................................................76 Kiedy: Deweloperzy niech(cid:218)tnie podchodz(cid:200) do uczestnictwa w procesie ........................................76 Jak zespo(cid:239)y wdra(cid:285)aj(cid:200) zasady wspó(cid:239)pracy w procesach iteracyjnych i przep(cid:239)ywu? ..................... 77 Zespó(cid:239) Global Talent Management z Ultimate Software ............................................................... 77 Zespó(cid:239) Sierra w BNP Paribas ........................................................................................................ 80 Sky Network Services ................................................................................................................... 81 Radzenie sobie z potrzeb(cid:200) formalnego zatwierdzenia i identyfikowalno(cid:258)ci(cid:200) ............................... 82 Zachowaj wykonywalne specyfikacje w systemie kontroli wersji ..........................................................83 Uzyskaj zatwierdzenie na eksportowanej (cid:285)yj(cid:200)cej dokumentacji ............................................................84 Kiedy: Zatwierdzasz iteracj(cid:218) po iteracji ..........................................................................................84 Uzyskaj zatwierdzenie zakresu, a nie specyfikacji ................................................................................84 Kiedy: Zatwierdzasz odleglejsze kamienie milowe .........................................................................84 Uzyskaj zatwierdzenie „odchudzonych” przypadków u(cid:285)ycia .................................................................85 Kiedy: Formalne zatwierdzenia wymagaj(cid:200) uzupe(cid:239)nienia o szczegó(cid:239)y ..............................................85 Wprowad(cid:283) realizacje przypadków u(cid:285)ycia .............................................................................................86 Kiedy: Formalne zatwierdzenia wymagaj(cid:200) uwzgl(cid:218)dniania wszystkich szczegó(cid:239)ów .........................86 Znaki ostrzegawcze ....................................................................................................................... 87 Uwa(cid:285)aj na testy, które cz(cid:218)sto daj(cid:200) ró(cid:285)ne wyniki .......................................................................... 87 Uwa(cid:285)aj na bumerangi ................................................................................................................... 88 Uwa(cid:285)aj na niedopasowanie organizacyjne ................................................................................... 88 Uwa(cid:285)aj na kod „na wszelki wypadek” .......................................................................................... 89 Uwa(cid:285)aj na „chirurgi(cid:218) (cid:258)rutówk(cid:200)” ................................................................................................... 90 Pami(cid:218)taj ........................................................................................................................................ 90 Kup książkęPoleć książkę CZ(cid:125)(cid:165)(cid:109) II Wzorce kluczowych procesów 5 Definiowanie zakresu na podstawie celów 93 Spis tre(cid:258)ci 5 Okre(cid:258)lanie odpowiedniego zakresu .............................................................................................. 95 Znajd(cid:283) odpowiedzi na pytania „Dlaczego?” i „Kto?” .............................................................................96 Zrozum, sk(cid:200)d bierze si(cid:218) warto(cid:258)(cid:202) .........................................................................................................98 Dowiedz si(cid:218), jakich wyników oczekuj(cid:200) u(cid:285)ytkownicy biznesowi ............................................................99 Niech deweloperzy zapewni(cid:200) cz(cid:218)(cid:258)(cid:202) „chc(cid:218)” historyjek u(cid:285)ytkownika ....................................................100 Kiedy: U(cid:285)ytkownicy biznesowi ufaj(cid:200) zespo(cid:239)owi zajmuj(cid:200)cemu si(cid:218) wytwarzaniem oprogramowania .....100 Wspó(cid:239)praca w celu zdefiniowania zakresu bez kontroli wysokiego poziomu ............................. 101 Zapytaj o to, jak co(cid:258) mo(cid:285)e by(cid:202) przydatne ..........................................................................................102 Zapytaj o rozwi(cid:200)zanie alternatywne ....................................................................................................103 Nie patrz na projekt wy(cid:239)(cid:200)cznie z perspektywy najni(cid:285)szego poziomu ...................................................103 Zadbaj, aby zespo(cid:239)y dostarcza(cid:239)y kompletne funkcje ...........................................................................104 Kiedy: Pracujesz nad du(cid:285)ymi projektami z cz(cid:218)(cid:258)ciami zespo(cid:239)ów w ró(cid:285)nych lokalizacjach .............104 Wi(cid:218)cej informacji ........................................................................................................................ 105 Pami(cid:218)taj ...................................................................................................................................... 106 6 Wspólne specyfikowanie 107 Dlaczego podczas definiowania specyfikacji musimy ze sob(cid:200) wspó(cid:239)pracowa(cid:202)? ....................... 108 Najpopularniejsze modele wspó(cid:239)pracy ....................................................................................... 109 Spróbuj zorganizowa(cid:202) du(cid:285)e warsztaty dla wszystkich cz(cid:239)onków zespo(cid:239)u .................................................109 Kiedy: Zaczynasz wdra(cid:285)a(cid:202) zasady specyfikacji przez przyk(cid:239)ady ...................................................109 Wypróbuj spotkania w mniejszym gronie („trzej amigos”) .................................................................111 Kiedy: Domena wymaga sk(cid:239)adania cz(cid:218)stych wyja(cid:258)nie(cid:241) ..............................................................111 Programujcie w parach .....................................................................................................................113 Kiedy: Pracujecie nad dojrza(cid:239)ymi produktami ..............................................................................113 Spraw, aby testerzy przed iteracj(cid:200) regularnie sprawdzali testy ............................................................115 Kiedy: Analitycy tworz(cid:200) testy ......................................................................................................115 Spróbuj nieformalnych rozmów .........................................................................................................115 Kiedy: Interesariusze biznesowi s(cid:200) (cid:239)atwo dost(cid:218)pni ......................................................................115 Przygotowanie wspó(cid:239)pracy ......................................................................................................... 116 Organizuj spotkania przygotowawcze ................................................................................................117 Kiedy: W projekcie uczestniczy wielu interesariuszy ...................................................................117 Zdob(cid:200)d(cid:283) zaanga(cid:285)owanie interesariuszy ..............................................................................................118 Dobrze przygotuj si(cid:218) do wst(cid:218)pnych spotka(cid:241) z interesariuszami ..........................................................119 Kiedy: Interesariusze nie s(cid:200) dost(cid:218)pni na miejscu ........................................................................119 Niech cz(cid:239)onkowie zespo(cid:239)u przejrz(cid:200) historyjki na wczesnym etapie ......................................................121 Kiedy: Analitycy/eksperci ds. domeny s(cid:200) w(cid:200)skim gard(cid:239)em procesu ............................................121 Przygotuj tylko wst(cid:218)pne przyk(cid:239)ady .....................................................................................................122 Kiedy: Interesariusze s(cid:200) (cid:239)atwo dost(cid:218)pni ......................................................................................122 Nie utrudniaj dyskusji przez przesadne przygotowania .......................................................................123 Wybór modelu wspó(cid:239)pracy ......................................................................................................... 124 Pami(cid:218)taj ...................................................................................................................................... 125 Kup książkęPoleć książkę 6 Spis tre(cid:258)ci 7 Wykorzystanie przyk(cid:239)adów ilustruj(cid:200)cych 127 8 Udoskonalanie specyfikacji 147 Uzupe(cid:239)nienie specyfikacji z wykorzystaniem przyk(cid:239)adów ilustruj(cid:200)cych: przyk(cid:239)ad ...................... 130 Przyk(cid:239)ady powinny by(cid:202) precyzyjne ............................................................................................. 131 Nie u(cid:285)ywaj w swoich przyk(cid:239)adach systemu zamkni(cid:218)tych odpowiedzi (tak/nie) ...................................131 Kiedy: Bazowe koncepcje nie s(cid:200) definiowane osobno .................................................................131 Unikaj u(cid:285)ywania abstrakcyjnych klas równowa(cid:285)no(cid:258)ci ........................................................................132 Kiedy: Mo(cid:285)esz zdefiniowa(cid:202) konkretny przyk(cid:239)ad ...........................................................................132 Przyk(cid:239)ady powinny by(cid:202) kompletne .............................................................................................. 133 Eksperymentuj z danymi ...................................................................................................................133 Pytaj, czy istnieje alternatywna metoda sprawdzenia funkcjonalno(cid:258)ci ................................................133 Kiedy: Pracujesz ze z(cid:239)o(cid:285)on(cid:200)/star(cid:200) infrastruktur(cid:200) .........................................................................133 Przyk(cid:239)ady powinny by(cid:202) realistyczne ........................................................................................... 134 Unikaj generowania zmy(cid:258)lonych danych ...........................................................................................134 Kiedy: Podczas prac nad projektem opartym na danych .............................................................134 Pozyskaj podstawowe przyk(cid:239)ady bezpo(cid:258)rednio od klientów ...............................................................135 Kiedy: Pracujesz dla klientów korporacyjnych .............................................................................135 Przyk(cid:239)ady powinny by(cid:202) zrozumia(cid:239)e ............................................................................................. 137 Unikaj pokusy zbadania wszelkich mo(cid:285)liwych kombinacji ..................................................................138 Szukaj ukrytych koncepcji .................................................................................................................138 Ilustrowanie wymaga(cid:241) niefunkcjonalnych .................................................................................. 140 Zdob(cid:200)d(cid:283) precyzyjne wymagania wydajno(cid:258)ciowe ...............................................................................140 Kiedy: Wysoka wydajno(cid:258)(cid:202) jest funkcj(cid:200) kluczow(cid:200) ........................................................................140 Wykorzystaj uproszczone prototypy interfejsów u(cid:285)ytkownika .............................................................141 Wypróbuj model QUPER ...................................................................................................................142 Kiedy: Wymagania zmieniaj(cid:200) si(cid:218) i s(cid:200) skalowalne ........................................................................142 Wykorzystaj list(cid:218) kontroln(cid:200) podczas dyskusji ....................................................................................143 Kiedy: Pojawiaj(cid:200) si(cid:218) obawy przekrojowe ....................................................................................143 Stwórz przyk(cid:239)ad referencyjny .............................................................................................................144 Kiedy: Wymagania s(cid:200) niemo(cid:285)liwe do oszacowania .....................................................................144 Pami(cid:218)taj ...................................................................................................................................... 145 Przyk(cid:239)ad dobrej specyfikacji ....................................................................................................... 149 Darmowa dostawa ...................................................................................................................... 149 Przyk(cid:239)ady .................................................................................................................................... 149 Przyk(cid:239)ad z(cid:239)ej specyfikacji ............................................................................................................ 150 Na co nale(cid:285)y zwróci(cid:202) uwag(cid:218) podczas udoskonalania specyfikacji? ........................................... 152 Przyk(cid:239)ady powinny by(cid:202) precyzyjne i testowalne ......................................................................... 152 Skrypty to nie specyfikacje ......................................................................................................... 152 Nie twórz opisów w formie przep(cid:239)ywów .............................................................................................154 Specyfikacje powinny dotyczy(cid:202) funkcjonalno(cid:258)ci biznesowej, a nie projektu oprogramowania ...... 154 Unikaj tworzenia specyfikacji, które s(cid:200) (cid:258)ci(cid:258)le powi(cid:200)zane z kodem ......................................................155 Oprzyj si(cid:218) pokusie obej(cid:258)cia trudno(cid:258)ci technicznych w specyfikacjach ...............................................156 Kiedy: Pracujesz na starym systemie .........................................................................................156 Nie pozwól uwi(cid:218)zi(cid:202) si(cid:218) przez szczegó(cid:239)y interfejsu u(cid:285)ytkownika ..........................................................157 Kiedy: Pracujesz nad projektami internetowymi ..........................................................................157 Specyfikacje powinny by(cid:202) oczywiste .......................................................................................... 157 U(cid:285)yj opisowego tytu(cid:239)u i wyja(cid:258)nij cel, stosuj(cid:200)c krótkie zdania .............................................................158 Poka(cid:285) i milcz .....................................................................................................................................158 Kiedy: Kto(cid:258) pracuje nad specyfikacj(cid:200) samodzielnie ....................................................................158 W celu: Sprawdzenia, czy specyfikacja jest oczywista i nie wymaga dodatkowych t(cid:239)umacze(cid:241) ....158 Kup książkęPoleć książkę Spis tre(cid:258)ci 7 Nie upraszczaj nadmiernie przyk(cid:239)adów ..............................................................................................159 Zacznij od podstawowych przyk(cid:239)adów, a nast(cid:218)pnie rozszerz zakres przez eksplorowanie ...................161 Kiedy: Opisujesz regu(cid:239)y za pomoc(cid:200) wielu kombinacji parametrów ..............................................161 Specyfikacje powinny by(cid:202) ostre ................................................................................................. 161 Zastosuj wzorzec „Zak(cid:239)adaj(cid:200)c/Je(cid:285)eli/Wtedy” ......................................................................................162 W celu: Sprawienia, by testy by(cid:239)y (cid:239)atwiejsze do zrozumienia .......................................................162 Nie definiuj jawnie wszystkich zale(cid:285)no(cid:258)ci w specyfikacji ....................................................................163 Kiedy: Musisz poradzi(cid:202) sobie ze skomplikowanymi zale(cid:285)no(cid:258)ciami/integralno(cid:258)ci(cid:200) referencyjn(cid:200) ......163 Zastosuj ustawienia domy(cid:258)lne w warstwie automatyzacji ..................................................................164 Nie polegaj na domy(cid:258)lnych warto(cid:258)ciach w ka(cid:285)dym przypadku ...........................................................164 Kiedy: Pracujesz z obiektami o wielu atrybutach .........................................................................164 Specyfikacje powinny by(cid:202) napisane w j(cid:218)zyku domeny ............................................................... 165 Udoskonalanie specyfikacji w praktyce ...................................................................................... 165 Pami(cid:218)taj ...................................................................................................................................... 168 9 Automatyczna walidacja bez zmiany specyfikacji 169 Czy automatyzacja jest w ogóle potrzebna? ............................................................................... 170 Rozpocz(cid:218)cie automatyzacji ......................................................................................................... 172 Aby pozna(cid:202) narz(cid:218)dzia, wypróbuj je najpierw w prostym projekcie ......................................................172 Kiedy: Pracujesz z istniej(cid:200)cym systemem ..................................................................................172 Zaplanuj automatyzacj(cid:218) z wyprzedzeniem ..........................................................................................173 Nie opó(cid:283)niaj i nie odsuwaj od siebie prac zwi(cid:200)zanych z automatyzacj(cid:200) ..............................................175 Unikaj automatyzacji istniej(cid:200)cych skryptów testów r(cid:218)cznych .............................................................175 Zdob(cid:200)d(cid:283) zaufanie dzi(cid:218)ki testom interfejsu u(cid:285)ytkownika ......................................................................176 Kiedy: Cz(cid:239)onkowie zespo(cid:239)u s(cid:200) nastawieni sceptycznie do wykonywalnych specyfikacji ...............176 Zarz(cid:200)dzanie warstw(cid:200) 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(cid:239)u(cid:285) granic systemu ..................................................................................................181 Kiedy: Integracje s(cid:200) skomplikowane ...........................................................................................181 Nie sprawdzaj logiki biznesowej za pomoc(cid:200) interfejsu u(cid:285)ytkownika ....................................................182 Automatyzacja pod skór(cid:200) aplikacji .....................................................................................................183 Kiedy: Sprawdzasz ograniczenia sesji i przep(cid:239)ywu ......................................................................183 Automatyzacja interfejsów u(cid:285)ytkownika ..................................................................................... 184 Okre(cid:258)l funkcjonalno(cid:258)(cid:202) interfejsu u(cid:285)ytkownika na wy(cid:285)szym poziomie abstrakcji ..................................186 Funkcjonalno(cid:258)(cid:202) interfejsu u(cid:285)ytkownika sprawdzaj tylko ze specyfikacj(cid:200) interfejsu u(cid:285)ytkownika ..........188 Kiedy: Interfejs u(cid:285)ytkownika zawiera z(cid:239)o(cid:285)on(cid:200) logik(cid:218) ....................................................................188 Unikaj zarejestrowanych testów interfejsu u(cid:285)ytkownika ......................................................................188 Ustaw kontekst w bazie danych .........................................................................................................189 Zarz(cid:200)dzanie danymi testowymi ................................................................................................... 191 Unikaj wykorzystywania danych wst(cid:218)pnie wype(cid:239)nionych ...................................................................191 Kiedy: Definiujesz logik(cid:218), która nie bazuje na danych ..................................................................191 Spróbuj wykorzysta(cid:202) wst(cid:218)pnie przygotowane dane referencyjne .......................................................192 Kiedy: W systemach bazuj(cid:200)cych na danych ...............................................................................192 Wyci(cid:200)gnij prototypy z bazy danych ....................................................................................................193 Kiedy: W starych, dojrza(cid:239)ych systemach bazuj(cid:200)cych na danych .................................................193 Pami(cid:218)taj ...................................................................................................................................... 194 Kup książkęPoleć książkę 8 Spis tre(cid:258)ci 10 Cz(cid:218)sta walidacja 195 Zmniejszenie zawodno(cid:258)ci ........................................................................................................... 197 Znajd(cid:283) najbardziej irytuj(cid:200)cy Ci(cid:218) element, napraw go, a nast(cid:218)pnie powtórz ca(cid:239)(cid:200) operacj(cid:218) ....................198 Kiedy: Pracujesz w systemie z kiepskim wsparciem dla testów automatycznych ........................198 Okre(cid:258)l niestabilne testy, korzystaj(cid:200)c z historii testów ci(cid:200)g(cid:239)ej integracji ...................................................199 Kiedy: Modernizujesz i dopasowujesz automatyczne testy do starego systemu ..........................199 Utwórz dedykowane (cid:258)rodowisko ci(cid:200)g(cid:239)ej walidacji ..............................................................................199 Zastosuj w pe(cid:239)ni zautomatyzowan(cid:200) procedur(cid:218) instalacji .....................................................................200 Utwórz uproszczonych „dublerów” systemów zewn(cid:218)trznych .............................................................201 Kiedy: Pracujesz z zewn(cid:218)trznymi (cid:283)ród(cid:239)ami danych referencyjnych ..............................................201 Odizoluj wybrane systemy zewn(cid:218)trzne ..............................................................................................202 Kiedy: Na Wasz(cid:200) prac(cid:218) maj(cid:200) wp(cid:239)yw systemy zewn(cid:218)trzne ...........................................................202 Wypróbuj walidacj(cid:218) wielostopniow(cid:200) ..................................................................................................202 Kiedy: Pracujesz w du(cid:285)ych grupach lub z grupami w ró(cid:285)nych lokalizacjach ................................202 Wykonaj testy w transakcjach ...........................................................................................................203 Kiedy: Wykonywalne specyfikacje modyfikuj(cid:200) dane referencyjne ................................................203 Wykonaj szybkie testy danych referencyjnych ...................................................................................204 Kiedy: W systemach opartych na danych ...................................................................................204 Oczekuj zdarze(cid:241), zamiast nastawia(cid:202) si(cid:218) na okre(cid:258)lony czas trwania ....................................................204 Uczy(cid:241) przetwarzanie asynchroniczne rozwi(cid:200)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(cid:283) operacyjny czas dzia(cid:239)ania ................................................................................................207 Kiedy: Musisz radzi(cid:202) sobie z ograniczeniami czasowymi ............................................................207 Podziel du(cid:285)e zestawy testów na mniejsze modu(cid:239)y .............................................................................208 Unikaj wykorzystywania do testów baz danych przechowywanych w pami(cid:218)ci ...................................209 Kiedy: W systemach bazuj(cid:200)cych na danych ...............................................................................209 Oddziel testy szybkie od wolnych ......................................................................................................210 Kiedy: Niewielka cz(cid:218)(cid:258)(cid:202) testów zajmuje wi(cid:218)kszo(cid:258)(cid:202) czasu przeznaczonego na ich wykonanie .......210 Utrzymaj stabilno(cid:258)(cid:202) uruchamianych na noc pakietów testów .............................................................210 Kiedy: Niemrawe testy s(cid:200) rozpoczynane w nocy ........................................................................210 Stwórz pakiet aktualnej iteracji ...........................................................................................................211 Wykonuj testy równolegle .................................................................................................................212 Kiedy: Mo(cid:285)esz stworzy(cid:202) kilka (cid:258)rodowisk testowych ...................................................................212 Spróbuj wy(cid:239)(cid:200)czy(cid:202) testy, z których wykonaniem wi(cid:200)(cid:285)e si(cid:218) mniejsze ryzyko .........................................213 Kiedy: Feedback z testów jest bardzo niemrawy .........................................................................213 Zarz(cid:200)dzanie testami, które ko(cid:241)cz(cid:200) si(cid:218) niepowodzeniem ............................................................ 214 Stwórz pakiet znanych nieudanych testów regresji ............................................................................215 Sprawdzaj automatycznie, które testy s(cid:200) wy(cid:239)(cid:200)czone ..........................................................................216 Kiedy: Nieudane testy zostaj(cid:200) zneutralizowane, a nie trafiaj(cid:200) do oddzielnego pakietu ...................216 Pami(cid:218)taj ...................................................................................................................................... 217 11 Tworzenie systemu dokumentacji 219 (cid:191)yj(cid:200)ca dokumentacja powinna by(cid:202) (cid:239)atwa do zrozumienia .......................................................... 219 Nie twórz d(cid:239)ugich specyfikacji ...........................................................................................................220 Nie u(cid:285)ywaj wielu specyfikacji do opisania jednej funkcji ....................................................................220 Szukaj koncepcji wy(cid:285)szego poziomu .................................................................................................221 Unikaj stosowania w testach technicznych poj(cid:218)(cid:202) automatyki .............................................................221 Kiedy: Interesariusze nie maj(cid:200) wystarczaj(cid:200)cej wiedzy technicznej ...............................................221 Kup książkęPoleć książkę Spis tre(cid:258)ci 9 (cid:191)yj(cid:200)ca dokumentacja powinna by(cid:202) spójna ................................................................................. 222 Ewoluuj(cid:200)cy j(cid:218)zyk ...............................................................................................................................223 Tworz(cid:200)c j(cid:218)zyk specyfikacji, bazuj na personach ................................................................................224 Kiedy: W projektach internetowych ............................................................................................224 Promuj wspó(cid:239)prac(cid:218) w celu zdefiniowania s(cid:239)ownika j(cid:218)zyka .................................................................225 Kiedy: Rezygnujesz z warsztatów specyfikacji ............................................................................225 Gromad(cid:283) dokumentacj(cid:218) swoich bloków konstrukcyjnych ..................................................................226 (cid:191)yj(cid:200)ca dokumentacja powinna by(cid:202) zorganizowana zgodnie z regu(cid:239)ami u(cid:239)atwiaj(cid:200)cymi dost(cid:218)p ............................................................................ 227 Organizuj bie(cid:285)(cid:200)c(cid:200) prac(cid:218), segreguj(cid:200)c j(cid:200) wed(cid:239)ug historyjek ..................................................................228 Zorganizuj historyjki na podstawie obszarów funkcjonalnych .............................................................228 Pogrupuj specyfikacje wed(cid:239)ug dróg nawigacji w interfejsie u(cid:285)ytkownika ............................................229 Kiedy: Dokumentujesz interfejsy u(cid:285)ytkownika .............................................................................229 Zorganizuj specyfikacje wed(cid:239)ug procesów biznesowych ....................................................................230 Kiedy: Wymagana jest identyfikowalno(cid:258)(cid:202) przypadków u(cid:285)ycia typu end-to-end ...........................230 U(cid:285)ywaj znaczników zamiast adresów URL, odnosz(cid:200)c si(cid:218) do specyfikacji wykonywalnych .................231 Kiedy: Potrzebujesz identyfikowalno(cid:258)ci specyfikacji ...................................................................231 S(cid:239)uchaj swojej (cid:285)yj(cid:200)cej dokumentacji .......................................................................................... 232 Pami(cid:218)taj ...................................................................................................................................... 233 CZ(cid:125)(cid:165)(cid:109) III Studia przypadków 12 uSwitch 237 Rozpocz(cid:218)cie zmiany procesu ...................................................................................................... 238 Optymalizacja procesu ............................................................................................................... 240 Obecny kszta(cid:239)t procesu ............................................................................................................... 244 Efekt ko(cid:241)cowy ............................................................................................................................. 245 Najwa(cid:285)niejsze lekcje ................................................................................................................... 245 13 RainStor 247 14 Iowa Student Loan 253 Zmiana procesu .......................................................................................................................... 247 Obecny kszta(cid:239)t procesu ............................................................................................................... 250 Najwa(cid:285)niejsze lekcje ................................................................................................................... 251 Zmiana procesu .......................................................................................................................... 253 Optymalizacja procesu ............................................................................................................... 255 (cid:191)yj(cid:200)ca dokumentacja jako przewaga konkurencyjna ................................................................. 258 Najwa(cid:285)niejsze lekcje ................................................................................................................... 259 15 Sabre Airline Solutions 261 Zmiana procesu .......................................................................................................................... 261 Poprawa wspó(cid:239)pracy .................................................................................................................. 263 Efekt ko(cid:241)cowy ............................................................................................................................. 265 Najwa(cid:285)niejsze lekcje ................................................................................................................... 265 Kup książkęPoleć książkę 10 Spis tre(cid:258)ci 16 ePlan Services 267 17 Songkick 275 18 Podsumowanie 283 Zmiana procesu .......................................................................................................................... 267 (cid:191)yj(cid:200)ca dokumentacja .................................................................................................................. 270 Obecny proces ............................................................................................................................ 271 Najwa(cid:285)niejsze lekcje ................................................................................................................... 273 Zmiana procesu .......................................................................................................................... 276 Obecny kszta(cid:239)t procesu ............................................................................................................... 278 Najwa(cid:285)niejsze lekcje ................................................................................................................... 280 Wspó(cid:239)praca przy definiowaniu wymaga(cid:241) buduje wzajemne zaufanie interesariuszy i cz(cid:239)onków zespo(cid:239)u ................................................................................................................ 283 Wspó(cid:239)praca wymaga przygotowania .......................................................................................... 284 Wspó(cid:239)praca mo(cid:285)e przybiera(cid:202) wiele ró(cid:285)nych form ...................................................................... 285 Przydaje si(cid:218) umiej(cid:218)tno(cid:258)(cid:202) spojrzenia na cel ko(cid:241)cowy jak na dokumentowanie procesów biznesowych ......................................................................................................... 286 W d(cid:239)u(cid:285)szej perspektywie prawdziw(cid:200) warto(cid:258)ci(cid:200) dla zespo(cid:239)u jest system (cid:285)yj(cid:200)cej dokumentacji ..... 287 Dodatek A. (cid:189)ród(cid:239)a 289 Skorowidz 293 Kup książkęPoleć książkę Wprowadzenie K si(cid:200)(cid:285)ka, któr(cid:200) trzymasz w d(cid:239)oniach (lub któr(cid:200) widzisz na monitorze swojego kom- putera), jest efektem ko(cid:241)cowym cyklu bada(cid:241) nad procesem, w czasie którego zaj- muj(cid:200)ce si(cid:218) wytwarzaniem oprogramowania zespo(cid:239)y na ca(cid:239)ym (cid:258)wiecie definiuj(cid:200), rozwijaj(cid:200) i dostarczaj(cid:200) w(cid:239)a(cid:258)ciwe produkty — wolne od b(cid:239)(cid:218)dów i opracowywane w krót- kich cyklach projektowych. Ta ksi(cid:200)(cid:285)ka zawiera wiedz(cid:218) zgromadzon(cid:200) dzi(cid:218)ki analizie pra- wie pi(cid:218)(cid:202)dziesi(cid:218)ciu projektów in(cid:285)ynierii oprogramowania, podczas których zespo(cid:239)y pracowa(cid:239)y nad dostarczeniem szerokiego zakresu produktów — pocz(cid:200)wszy od ogólnodost(cid:218)pnych stron internetowych a(cid:285) po wewn(cid:218)trzne systemy typu back-office. Zbieraj(cid:200)c materia(cid:239)y do tej ksi(cid:200)(cid:285)ki, przeanalizowa(cid:239)em dzia(cid:239)ania zespo(cid:239)ów rozmaitych typów — by(cid:239)y to zarówno ma(cid:239)e grupy ludzi pracuj(cid:200)cych w tym samym biurze, jak i powi(cid:200)zane sieci programistów czasami rozlokowane nawet na ró(cid:285)nych kontynentach, osoby pos(cid:239)uguj(cid:200)ce si(cid:218) ró(cid:285)norakimi metodologiami pro- cesów in(cid:285)ynierii: programowaniem ekstremalnym (ang. Extreme Programming), Scrumem, Kanbanem czy podobnymi metodami (cz(cid:218)sto po(cid:239)(cid:200)czonymi ze sob(cid:200) i przybieraj(cid:200)cymi formy metod zwinnych, tj. agile i lean). Wszystkie te zespo(cid:239)y (cid:239)(cid:200)czy(cid:239)o jedno: (cid:258)cis(cid:239)a wspó(cid:239)praca w zakresie opracowywania poprawnych specyfikacji oraz testów, a tak(cid:285)e ko(cid:241)cowy sukces i korzy(cid:258)ci, jakie sta(cid:239)y si(cid:218) ich udzia(cid:239)em dzi(cid:218)ki tej wspó(cid:239)pracy. Specyfikacja przez przyk(cid:239)ady Ró(cid:285)ne zespo(cid:239)y stosuj(cid:200) ró(cid:285)ne terminy dla nazwania tego, co robi(cid:200) ze specyfikacjami i testami, a przecie(cid:285) w ka(cid:285)dym przypadku ludzie ci odwo(cid:239)uj(cid:200) si(cid:218) do tych samych kluczowych zasad i koncepcji, które moim zdaniem w gruncie rzeczy s(cid:200) zawsze takie same. W(cid:258)ród u(cid:285)ywanych przez zespo(cid:239)y terminów i skrótów znajdujemy takie jak: (cid:120) Zwinne testowanie akceptacyjne. (cid:120) ATDD (ang. Acceptance Test-Driven Development), czyli wytwarzanie oprogramowania w oparciu o testy akceptacyjne. (cid:120) EDT (ang. Example-Driven Development), tj. wytwarzanie oprogramowania w oparciu o przyk(cid:239)ady. (cid:120) Testowanie przez historyjki u(cid:285)ytkownika (ang. story testing). (cid:120) BDD (ang. Behavior-Driven Development), czyli wytwarzanie oprogramowania w oparciu o analiz(cid:218) zachowa(cid:241) u(cid:285)ytkowników. (cid:120) Specyfikacja przez przyk(cid:239)ady (ang. Specification by Example). Ju(cid:285) sam fakt, (cid:285)e te same dzia(cid:239)ania maj(cid:200) tak wiele ró(cid:285)nych nazw, mo(cid:285)e nam wiele powiedzie(cid:202) o ogromnej innowacyjno(cid:258)ci, z jak(cid:200) mamy do czynienia w tej dziedzinie. Mnogo(cid:258)(cid:202) stosowa- nych terminów i definicji (cid:258)wiadczy tak(cid:285)e o tym, (cid:285)e praktyki opisane w tej ksi(cid:200)(cid:285)ce wp(cid:239)ywaj(cid:200) na zmian(cid:218) podej(cid:258)cia zespo(cid:239)ów do specyfikacji oraz do zagadnienia wytwarzania oprogramo- wania i jego testowania. Kieruj(cid:200)c si(cid:218) d(cid:200)(cid:285)eniem do zachowania spójno(cid:258)ci przekazu, musia(cid:239)em Kup książkęPoleć książkę 12 Specyfikacja na przyk(cid:239)adach jednak wybra(cid:202) jeden termin. Zdecydowa(cid:239)em si(cid:218) na specyfikacj(cid:218) przez przyk(cid:239)ady i b(cid:218)d(cid:218) u(cid:285)ywa(cid:239) tego okre(cid:258)lenia w ca(cid:239)ej ksi(cid:200)(cid:285)ce. Wyja(cid:258)ni(cid:218) mój wybór w cz(cid:218)(cid:258)ci tego wprowadzenia zatytu(cid:239)o- wanej „Kilka s(cid:239)ów na temat terminologii”, gdzie znajdzie si(cid:218) tak(cid:285)e kilka szczegó(cid:239)ów dotycz(cid:200)- cych reszty terminów zastosowanych dla nazwania elementów opisywanego procesu. W (cid:258)wiecie rzeczywistym… Szczegó(cid:239)y proponowanej przeze mnie metodyki przedstawiam, odwo(cid:239)uj(cid:200)c si(cid:218) do licznych studiów przypadków i zarejestrowanych rozmów z cz(cid:239)onkami grup programistów. Wybra- (cid:239)em to podej(cid:258)cie (cid:258)wiadomie, z my(cid:258)l(cid:200) o tym, (cid:285)eby czytelnicy mieli szans(cid:218) dowiedzie(cid:202) si(cid:218), jak radzi(cid:239)y sobie prawdziwe zespo(cid:239)y, pracuj(cid:200)ce zgodnie z regu(cid:239)ami tej metody i czerpi(cid:200)ce z niej spore korzy(cid:258)ci. Specyfikacja przez przyk(cid:239)ady w (cid:285)adnym razie nie jest ciemniejsz(cid:200) stron(cid:200) sztuki, mimo (cid:285)e niektóre popularne media przekonuj(cid:200), (cid:285)e jest inaczej. Prawie wszystko, o czym mówimy w tej ksi(cid:200)(cid:285)ce, pochodzi z rzeczywistego (cid:258)wiata in(cid:285)y- nierii oprogramowania, dotyczy dzia(cid:239)aj(cid:200)cych w tym (cid:258)wiecie zespo(cid:239)ów oraz ich — jak najbar- dziej realnych — do(cid:258)wiadcze(cid:241). Tylko nieliczne praktyki zosta(cid:239)y przedstawione w formie sugestii niepopartych studium przypadku. S(cid:200) to zwykle pomys(cid:239)y, które — moim zda- niem — b(cid:218)d(cid:200) w przysz(cid:239)o(cid:258)ci stanowi(cid:202) wa(cid:285)ny przyczynek do dyskusji. I w(cid:239)a(cid:258)nie jako takie s(cid:200) przeze mnie przedstawiane. Jestem przekonany, (cid:285)e moje wnioski, a tak(cid:285)e badania, jakie przeprowadzi(cid:239)em na potrzeby tej ksi(cid:200)(cid:285)ki, nie zostan(cid:200) uznane za powa(cid:285)ne studia naukowe przez sceptyków, którzy twier- dz(cid:200), i(cid:285) zwinne praktyki si(cid:218) nie sprawdzaj(cid:200), a bran(cid:285)a powinna wróci(cid:202) do „prawdziwej in(cid:285)y- nierii oprogramowania”1. Akceptuj(cid:218) to. Zasoby, do jakich mia(cid:239)em dost(cid:218)p podczas zbierania materia(cid:239)ów na potrzeby tego projektu, mo(cid:285)na uzna(cid:202) za niewystarczaj(cid:200)ce w porównaniu z tym, czego wymaga si(cid:218) od powa(cid:285)nych bada(cid:241) naukowych. I nawet gdybym dysponowa(cid:239) zasobami spe(cid:239)niaj(cid:200)cymi kryteria uznanych metodologii, to przecie(cid:285) ani nie jestem naukow- cem, ani nie zamierzam przedstawia(cid:202) siebie jako naukowca. Jestem praktykiem. Kto powinien zapozna(cid:202) si(cid:218) z t(cid:200) ksi(cid:200)(cid:285)k(cid:200)? Je(cid:258)li tak jak ja jeste(cid:258) praktykiem i zarabiasz na chleb, pracuj(cid:200)c przy wytwarzaniu oprogra- mowania lub wspieraj(cid:200)c prac(cid:218) nad oprogramowaniem, ta ksi(cid:200)(cid:285)ka ma Ci wiele do zaofe- rowania. Powsta(cid:239)a wszak przede wszystkim z my(cid:258)l(cid:200) o zespo(cid:239)ach, które stara(cid:239)y si(cid:218) wdro(cid:285)y(cid:202) w swoich (cid:258)rodowiskach zwinne praktyki, ale napotka(cid:239)y problemy wp(cid:239)ywaj(cid:200)ce niekorzystnie na jako(cid:258)(cid:202) produktu ko(cid:241)cowego, zwi(cid:218)kszaj(cid:200)ce nak(cid:239)ad pracy i prowadz(cid:200)ce do tego, (cid:285)e dzie(cid:239)o r(cid:200)k programistów nie spe(cid:239)nia(cid:239)o oczekiwa(cid:241) klientów. (Tak… wówczas mamy do czynienia 1 Je(cid:258)li chcesz pozna(cid:202) argumenty tych, którzy (cid:239)udz(cid:200) si(cid:218), i(cid:285) rygorystyczne podej(cid:258)cie do in(cid:285)ynierii oprogramowania przynosi korzy(cid:258)ci, tak jak gdyby by(cid:239)a to jaka(cid:258) drugorz(cid:218)dna ga(cid:239)(cid:200)(cid:283) fizyki, zajrzyj na stron(cid:218) http://www.semat.org. Dobre kontrargumenty zawiera prezentacja Glenna Vanderburga zatytu(cid:239)owana Software Engineering Doesn’t Work!, z któr(cid:200) mo(cid:285)na zapozna(cid:202) si(cid:218) na stronie http://confreaks.net/videos/282- lsrc2010-real-software-engineering. Kup książkęPoleć książkę Wprowadzenie 13 z prawdziwymi k(cid:239)opotami i w takiej sytuacji zwyk(cid:239)a iteracja nie na wiele si(cid:218) zda, poniewa(cid:285) staje si(cid:218) „objazdem”, a nie rozwi(cid:200)zaniem problemu). Specyfikacja przez przyk(cid:239)ady, zwinne testowanie akceptacyjne, BDD i wszystkie alternatywne nazwy okre(cid:258)laj(cid:200) ten sam proces, zorientowany na rozwi(cid:200)zywanie tych problemów. Ta ksi(cid:200)(cid:285)ka pomo(cid:285)e Ci pozna(cid:202) podstawy wspomnianych dobrych praktyk in(cid:285)ynierii oprogramowania. Dowiesz si(cid:218) z niej, jak mo(cid:285)esz mie(cid:202) wi(cid:218)kszy pozytywny wp(cid:239)yw na zespó(cid:239), niezale(cid:285)nie od tego, czy jeste(cid:258) testerem, dewelo- perem, analitykiem, czy w(cid:239)a(cid:258)cicielem produktu. Jeszcze kilka lat temu wi(cid:218)kszo(cid:258)(cid:202) ludzi, których spotyka(cid:239)em na konferencjach, nigdy wcze(cid:258)niej nie s(cid:239)ysza(cid:239)a o opisanych w tej ksi(cid:200)(cid:285)ce praktykach. Gros tych, z którymi rozma- wiam dzi(cid:258), ma (cid:258)wiadomo(cid:258)(cid:202) istnienia wspomnianych praktyk, ale wielu z nich nie uda(cid:239)o si(cid:218) wdro(cid:285)y(cid:202) ich prawid(cid:239)owo. Istnieje niewielka baza literatury fachowej traktuj(cid:200)cej o proble- mach, jakie napotykaj(cid:200) zespo(cid:239)y podczas szeroko poj(cid:218)tego wdra(cid:285)ania zwinnych praktyk, dla- tego ka(cid:285)dy zniech(cid:218)cony zespó(cid:239) stwierdza, (cid:285)e jego przypadek musi by(cid:202) wyj(cid:200)tkowy, a sfor- malizowane koncepcje po prostu nie sprawdzaj(cid:200) si(cid:218) w „jego (cid:258)wiecie”. Ludzie z takich zniech(cid:218)conych zespo(cid:239)ów dziwi(cid:200) si(cid:218), jak po zaledwie pi(cid:218)ciu minutach rozmowy udaje mi si(cid:218) trafnie zidentyfikowa(cid:202) ich trzy lub cztery najwi(cid:218)ksze problemy. Cz(cid:218)sto s(cid:200) bardzo zdziwieni, s(cid:239)ysz(cid:200)c, (cid:285)e wiele innych zespo(cid:239)ów napotyka na swojej drodze te same przeszkody. Je(cid:258)li pracujesz w takim zespole, ksi(cid:200)(cid:285)ka, któr(cid:200) w(cid:239)a(cid:258)nie trzymasz w d(cid:239)oniach, u(cid:258)wiadomi Ci przede wszystkim, (cid:285)e nie jeste(cid:258) sam. Zespo(cid:239)y, z którymi rozmawia(cid:239)em podczas zbiera- nia materia(cid:239)ów do tej pozycji, wcale nie by(cid:239)y zespo(cid:239)ami idealnymi. Tak(cid:285)e one napotka(cid:239)y na swojej drodze mnóstwo problemów! Jednak zamiast rezygnowa(cid:202) po zderzeniu z murem przeciwno(cid:258)ci, ludzie Ci postanowili go „objecha(cid:202)” lub zburzy(cid:202). Taka (cid:258)wiadomo(cid:258)(cid:202) wspólnoty cz(cid:218)sto pozwala zobaczy(cid:202) swoje problemy w innym (cid:258)wietle. Mam nadziej(cid:218), (cid:285)e po przeczy- taniu tej ksi(cid:200)(cid:285)ki b(cid:218)dziesz w(cid:239)a(cid:258)nie jedn(cid:200) z tych wyj(cid:200)tkowych osób, które potrafi(cid:200) spojrze(cid:202) na sytuacj(cid:218) z innej perspektywy. Je(cid:258)li akurat znajdujesz si(cid:218) w trakcie wdra(cid:285)ania specyfikacji przez przyk(cid:239)ady, ta ksi(cid:200)(cid:285)ka dostarczy Ci przydatnych wskazówek, dzi(cid:218)ki którym dowiesz si(cid:218), jak poradzi(cid:202) sobie z bie(cid:285)(cid:200)- cymi problemami i czego mo(cid:285)esz spodziewa(cid:202) si(cid:218) w przysz(cid:239)o(cid:258)ci. Mam nadziej(cid:218), (cid:285)e b(cid:218)dziesz uczy(cid:202) si(cid:218) na b(cid:239)(cid:218)dach innych ludzi i niektórych z nich uda Ci si(cid:218) unikn(cid:200)(cid:202). Ta ksi(cid:200)(cid:285)ka zosta(cid:239)a napisana tak(cid:285)e z my(cid:258)l(cid:200) o do(cid:258)wiadczonych praktykach, osobach, któ- rym uda(cid:239)o si(cid:218) wdro(cid:285)enie zasad specyfikacji przez przyk(cid:239)ady. Gdy zaczyna(cid:239)em rejestrowanie wywiadów z zespo(cid:239)ami, spodziewa(cid:239)em si(cid:218), (cid:285)e nie dowiem si(cid:218) niczego nowego. My(cid:258)la(cid:239)em, (cid:285)e „wiem, co jest grane”, i szuka(cid:239)em tylko potwierdzenia. Tymczasem ostatecznie musia(cid:239)em przyzna(cid:202), (cid:285)e zaskoczy(cid:239)o mnie to, jak wiele ró(cid:285)nych pomys(cid:239)ów mo(cid:285)na zastosowa(cid:202) zale(cid:285)nie od kontekstu. Dowiadywa(cid:239)em si(cid:218) o rozwi(cid:200)zaniach, które wcze(cid:258)niej trudno mi by(cid:239)o sobie wyobrazi(cid:202)! Wiele si(cid:218) przy tym nauczy(cid:239)em. Dlatego mam nadziej(cid:218), (cid:285)e i Ty, drogi Czytelniku, wiele nauczysz si(cid:218) dzi(cid:218)ki lekturze tej ksi(cid:200)(cid:285)ki. Przedstawione w niej praktyki i pomys(cid:239)y powinny zainspirowa(cid:202) Ci(cid:218) do wypróbowania alternatywnych rozwi(cid:200)za(cid:241) problemów i da(cid:202) Ci kilka podpowiedzi, jak usprawni(cid:202) prac(cid:218) zespo(cid:239)u, gdy tylko natkniesz si(cid:218) na histori(cid:218) przypo- minaj(cid:200)c(cid:200) jaki(cid:258) opisany tu przyk(cid:239)ad. Kup książkęPoleć książkę 14 Specyfikacja na przyk(cid:239)adach Co znajdziesz w (cid:258)rodku? W pierwszej cz(cid:218)(cid:258)ci ksi(cid:200)(cid:285)ki przedstawi(cid:218) podstawy koncepcji specyfikacji przez przyk(cid:239)ady. Zamiast przekonywa(cid:202) Ci(cid:218) do tego, by(cid:258) przestrzega(cid:239) zasad opisanych w tej ksi(cid:200)(cid:285)ce, poka(cid:285)(cid:218) Ci — w sposób charakterystyczny dla metodyki specyfikacji przez przyk(cid:239)ady — konkretne korzy(cid:258)ci, jakie zespo(cid:239)y pracuj(cid:200)ce nad wytwarzaniem oprogramowania mog(cid:200) uzyska(cid:202) dzi(cid:218)ki zastosowaniu prezentowanych tu regu(cid:239). Je(cid:258)li zastanawiasz si(cid:218) nad zakupem tej ksi(cid:200)(cid:285)ki, najpierw przejrzyj rozdzia(cid:239) 1. i odpowiedz sobie na pytanie, czy której(cid:258) z opisanych tam korzy(cid:258)ci mo(cid:285)na spodziewa(cid:202) si(cid:218) tak(cid:285)e podczas realizacji Twojego projektu. W rozdziale 2. przedstawi(cid:218) najwa(cid:285)niejsze modele procesów i kluczowe artefakty specyfikacji przez przy- k(cid:239)ady. W rozdziale 3. omówi(cid:218) szczegó(cid:239)owo koncepcj(cid:218) (cid:285)yj(cid:200)cej dokumentacji. W rozdziale 4. przedstawi(cid:218) typowe punkty wyj(cid:258)cia dla zainicjowania zmian procesu i kultury pracy zespo(cid:239)u oraz wska(cid:285)(cid:218), na co nale(cid:285)y zwróci(cid:202) uwag(cid:218) podczas implementacji metodyki. Jednym z moich celów jako autora tej ksi(cid:200)(cid:285)ki jest stworzenie spójnego s(cid:239)ownika dla wzorców, idei i artefaktów, który b(cid:218)dzie móg(cid:239) by(cid:202) stosowany podczas wdra(cid:285)ania zasad specyfikacji przez przyk(cid:239)ady. W bran(cid:285)y in(cid:285)ynierii oprogramowania u(cid:285)ywa si(cid:218) tuzina ró(cid:285)nych terminów dla nazwania samej praktyki i dwa razy wi(cid:218)cej dla nazwania poszczególnych ele- mentów kluczowych metodyki. Ludzie nazywaj(cid:200) ten sam element: plikami w(cid:239)a(cid:258)ciwo(cid:258)ci, przypadkami testowymi, plikami BDD, testami akceptacyjnymi itp. Z tego powodu w roz- dziale 2. przedstawi(cid:218) najlepsze (moim zdaniem) terminy stosowane dla okre(cid:258)lenia wszyst- kich kluczowych elementów omawianej metodyki. Nawet je(cid:258)li jeste(cid:258) do(cid:258)wiadczonym prak- tykiem, proponuj(cid:218), (cid:285)eby(cid:258) zapozna(cid:239) si(cid:218) z tym rozdzia(cid:239)em i odpowiedzia(cid:239) sobie na pytanie, czy tak samo rozumiemy kluczowe terminy, wyra(cid:285)enia i wzorce, o których mówimy w tej ksi(cid:200)(cid:285)ce. W drugiej cz(cid:218)(cid:258)ci przedstawi(cid:218) najistotniejsze praktyki, z których zespo(cid:239)y opisane w stu- diach przypadków korzysta(cid:239)y, by wdro(cid:285)y(cid:202) zasady specyfikacji przez przyk(cid:239)ady. Zespo(cid:239)y dzia(cid:239)aj(cid:200)ce w ró(cid:285)nych (cid:258)rodowiskach podejmowa(cid:239)y ró(cid:285)norakie decyzje — czasem diametralnie ró(cid:285)ne, a czasami wr(cid:218)cz sprzeczne — aby jednak ostatecznie uzyska(cid:202) takie same efekty. Opis tych praktyk uzupe(cid:239)ni(cid:218) dodatkowo charakterystyk(cid:200) kontekstów, w których dzia(cid:239)a(cid:239)y zespo(cid:239)y podczas wdra(cid:285)ania regu(cid:239) specyfikacji przez przyk(cid:239)ady. Siedem rozdzia(cid:239)ów drugiej cz(cid:218)(cid:258)ci podzieli(cid:239)em mniej wi(cid:218)cej zgodnie z podzia(cid:239)em na obszary procesów. W bran(cid:285)y takiej jak in(cid:285)ynieria oprogramowania nie istniej(cid:200) uniwersalne, idealne roz- wi(cid:200)zania, ale na pewno mo(cid:285)na mówi(cid:202) o dobrych pomys(cid:239)ach, które da si(cid:218) zastosowa(cid:202) ze (cid:258)wietnym skutkiem w ró(cid:285)nych kontekstach. W drugiej cz(cid:218)(cid:258)ci tej ksi(cid:200)(cid:285)ki znajdziesz ikonki przedstawiaj(cid:200)ce kciuk uniesiony w gór(cid:218) lub skierowany w dó(cid:239). Takie grafiki b(cid:218)d(cid:200) pojawia(cid:202) si(cid:218) przy nag(cid:239)ówkach z opisem dzia(cid:239)a(cid:241), które badane zespo(cid:239)y uzna(cid:239)y za u(cid:285)yteczne, lub pro- blemów, z którymi cz(cid:218)sto musia(cid:239)y si(cid:218) mierzy(cid:202). Potraktuj te wskazania jak propozycje wypró- bowania przedstawionego przeze mnie rozwi(cid:200)zania lub ostrze(cid:285)enie przed sytuacj(cid:200), jakiej warto unika(cid:202). Nie s(cid:200) to w (cid:285)adnym razie gotowe recepty, które nale(cid:285)y koniecznie zastoso- wa(cid:202). Ikony przedstawiaj(cid:200)ce strza(cid:239)ki podkre(cid:258)laj(cid:200) najistotniejsze koncepcje zwi(cid:200)zane z ka(cid:285)dym z prezentowanych dzia(cid:239)a(cid:241). Wytwarzanie oprogramowania nie jest sztuk(cid:200) statyczn(cid:200), poniewa(cid:285) stale zmieniaj(cid:200) si(cid:218) zarówno zespo(cid:239)y, jak i (cid:258)rodowiska, w których pracuj(cid:200) ludzie. Procesy rozwoju produktu musz(cid:200) nad(cid:200)(cid:285)a(cid:202) za tymi zmianami. W cz(cid:218)(cid:258)ci trzeciej tej ksi(cid:200)(cid:285)ki przedstawi(cid:218) studia przypad- Kup książkęPoleć książkę Wprowadzenie 15 ków opisuj(cid:200)ce „podró(cid:285)e” kilku wybranych zespo(cid:239)ów. Omówi(cid:218) procesy, ograniczenia i kon- teksty, analizuj(cid:200)c ewolucj(cid:218) projektów. Przedstawione w tej cz(cid:218)(cid:258)ci historie pozwol(cid:200) Ci lepiej przygotowa(cid:202) si(cid:218) do czekaj(cid:200)cych Ci(cid:218) zmian lub zach(cid:218)c(cid:200) do wykonania nast(cid:218)pnego kroku, pomog(cid:200) w poszukiwaniach inspiracji, a tak(cid:285)e zainspiruj(cid:200) do odkrywania nowych metod dzia(cid:239)a(cid:241) i rozwi(cid:200)za(cid:241). W ostatnim rozdziale podsumuj(cid:218) najwa(cid:285)niejsze wnioski, do których doszed(cid:239)em dzi(cid:218)ki analizie licznych studiów przypadków zebranych na potrzeby tej ksi(cid:200)(cid:285)ki. Co(cid:258) wi(cid:218)cej ni(cid:285) podstawy Gdyby odwo(cid:239)a(cid:202) si(cid:218) do tradycyjnego modelu doskonalenia Shu-ha-ri2, ta ksi(cid:200)(cid:285)ka znajduje si(cid:218) na p
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: