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:

• poznasz zalety SBE
• dowiesz siÄ™, dlaczego wspólne specyfikowanie jest tak istotne
• nauczysz siÄ™ definiować cel z uwzglÄ™dnieniem wzorców
• zmienisz kulturÄ™ pracy Twojego zespoÅ‚u
• skutecznie wprowadzisz SBE w Twojej organizacji

Poznaj zalety SBE!

Osoby które kupowały "Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie", wybierały także:

• Superinteligencja. Scenariusze, strategie, zagro 66,67 zÅ‚, (14,00 zÅ‚ -79%)
• Poradnik design thinking - czyli jak wykorzysta 48,28 zÅ‚, (14,00 zÅ‚ -71%)
• Kosymulacja. Elastyczne projektowanie i symulacja wielodomenowa 38,39 zÅ‚, (11,90 zÅ‚ -69%)
• F# 4.0 dla zaawansowanych. Wydanie IV 96,45 zÅ‚, (29,90 zÅ‚ -69%)
• Systemy reaktywne. Wzorce projektowe i ich stosowanie 65,31 zÅ‚, (20,90 zÅ‚ -68%)

Spis treści

Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie eBook -- 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)