Wprowadzenie (11)

Podziękowania (22)

O autorze (23)

O ilustracji na okładce (24)

CZĘŚĆ I. ZACZYNAMY!

1. Kluczowe korzyści (27)

Sprawniejsze wprowadzanie zmian (30)
Wyższa jakość produktu (32)
Mniej przeróbek (36)
Lepsze dostosowanie aktywności (39)
Pamiętaj (41)

2. Wzorce kluczowych procesów (43)

Zdefiniowanie zakresu prac w oparciu o cele biznesowe (45)
Wspólne specyfikowanie (45)
Opisywanie z wykorzystaniem przykładów ilustrujących (46)
Udoskonalanie specyfikacji (47)
Automatyzacja walidacji bez zmiany specyfikacji (47)
Częsta walidacja (49)
Tworzenie systemu dokumentacji (49)
Praktyczny przykład (50)
- Cel biznesowy (50)
- Przykład poprawnego celu biznesowego (51)
- Zakres (51)
- Historyjki użytkowników podstawowego elementu systemu lojalnościowego (51)
- Kluczowe przykłady (51)
- Kluczowe przykłady: Darmowa dostawa (52)
- Specyfikacja z przykładami (52)
- Darmowa dostawa (52)
- Przykłady (53)
- Wykonywalna specyfikacja (53)
- Żyjąca dokumentacja (53)
Pamiętaj (54)

3. Żyjąca dokumentacja (55)

Dlaczego potrzebujemy pewnej dokumentacji? (56)
Testy mogą być dobrą dokumentacją (57)
Tworzenie dokumentacji na podstawie wykonywalnej specyfikacji (58)
Zalety modelu zorientowanego na dokumentację (60)
Pamiętaj (61)

4. Inicjowanie zmian (63)

Jak rozpocząć zmianę procesu? (64)
- Wdrażaj specyfikację przez przykłady jako część rozległego procesu zmian (65)
- Skup się na poprawie jakości (65)
- Zacznij od automatyzacji testów funkcjonalnych (66)
- Wprowadź narzędzie do wykonywalnych specyfikacji (68)
- Wykorzystaj TDD jako odskocznię (70)
Jak zacząć zmieniać kulturę zespołu? (70)
- Unikaj używania terminów sugerujących zwinność lub bycie "agile" (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)
- Sprawdzaj, kto wykonuje testy automatyczne (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)
- Uzyskaj zatwierdzenie zakresu, a nie specyfikacji (84)
- Uzyskaj zatwierdzenie "odchudzonych" przypadków użycia (85)
- Wprowadź realizacje przypadków użycia (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)

CZĘŚĆ 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)
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)
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)
- Wypróbuj spotkania w mniejszym gronie ("trzej amigos") (111)
- Programujcie w parach (113)
- Spraw, aby testerzy przed iteracją regularnie sprawdzali testy (115)
- Spróbuj nieformalnych rozmów (115)
Przygotowanie współpracy (116)
- Organizuj spotkania przygotowawcze (117)
- Zdobądź zaangażowanie interesariuszy (118)
- Dobrze przygotuj się do wstępnych spotkań z interesariuszami (119)
- Niech członkowie zespołu przejrzą historyjki na wczesnym etapie (121)
- Przygotuj tylko wstępne przykłady (122)
- Nie utrudniaj dyskusji przez przesadne przygotowania (123)
Wybór modelu współpracy (124)
Pamiętaj (125)

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)
- Unikaj używania abstrakcyjnych klas równoważności (132)
Przykłady powinny być kompletne (133)
- Eksperymentuj z danymi (133)
- Pytaj, czy istnieje alternatywna metoda sprawdzenia funkcjonalności (133)
Przykłady powinny być realistyczne (134)
- Unikaj generowania zmyślonych danych (134)
- Pozyskaj podstawowe przykłady bezpośrednio od klientów (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)
- Wykorzystaj uproszczone prototypy interfejsów użytkownika (141)
- Wypróbuj model QUPER (142)
- Wykorzystaj listę kontrolną podczas dyskusji (143)
- Stwórz przykład referencyjny (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)
- Nie pozwól uwięzić się przez szczegóły interfejsu użytkownika (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)
- Nie upraszczaj nadmiernie przykładów (159)
- Zacznij od podstawowych przykładów, a następnie rozszerz zakres przez eksplorowanie (161)
- Specyfikacje powinny być ostre (161)
- Zastosuj wzorzec "Zakładając/Jeżeli/Wtedy" (162)
- Nie definiuj jawnie wszystkich zależności w specyfikacji (163)
- Zastosuj ustawienia domyślne w warstwie automatyzacji (164)
- Nie polegaj na domyślnych wartościach w każdym przypadku (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)
- 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)
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)
- Nie sprawdzaj logiki biznesowej za pomocą interfejsu użytkownika (182)
- Automatyzacja pod skórą aplikacji (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)
- 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)
- Spróbuj wykorzystać wstępnie przygotowane dane referencyjne (192)
- Wyciągnij prototypy z bazy danych (193)
Pamiętaj (194)

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)
- Określ niestabilne testy, korzystając z historii testów ciągłej integracji (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)
- Odizoluj wybrane systemy zewnętrzne (202)
- Wypróbuj walidację wielostopniową (202)
- Wykonaj testy w transakcjach (203)
- Wykonaj szybkie testy danych referencyjnych (204)
- Oczekuj zdarzeń, zamiast nastawiać się na określony czas trwania (204)
- Uczyń przetwarzanie asynchroniczne rozwiązaniem opcjonalnym (205)
- Nie wykorzystuj wykonywalnych specyfikacji w funkcji walidacji kompleksowej typu end-to-end (206)
Szybsze uzyskiwanie informacji zwrotnej (207)
- Wprowadź operacyjny czas działania (207)
- Podziel duże zestawy testów na mniejsze moduły (208)
- Unikaj wykorzystywania do testów baz danych przechowywanych w pamięci (209)
- Oddziel testy szybkie od wolnych (210)
- Utrzymaj stabilność uruchamianych na noc pakietów testów (210)
- Stwórz pakiet aktualnej iteracji (211)
- Wykonuj testy równolegle (212)
- Spróbuj wyłączyć testy, z których wykonaniem wiąże się mniejsze ryzyko (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)
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)
Żyjąca dokumentacja powinna być spójna (222)
- Ewoluujący język (223)
- Tworząc język specyfikacji, bazuj na personach (224)
- Promuj współpracę w celu zdefiniowania słownika języka (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)
- Zorganizuj specyfikacje według procesów biznesowych (230)
- Używaj znaczników zamiast adresów URL, odnosząc się do specyfikacji wykonywalnych (231)
Słuchaj swojej żyjącej dokumentacji (232)
Pamiętaj (233)

CZĘŚĆ 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)

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)

Specyfikacja na przykładach

Opis

Autor

Pozostałe książki:

Gdzie kupić

Moja Biblioteczka

Recenzje

Moja opinia o książce

Cytaty z książki