Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie (ebook)(audiobook)(audiobook)

Spis treści

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)

pokaż cały spis treści

ukryj recenzje