reklama - zainteresowany?

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

Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie
ebook
Autor: Gojko Adzic
Tytuł oryginału: Specification by Example: How Successful Teams Deliver the Right Software
TÅ‚umaczenie: Arkadiusz Romanek
ISBN: 978-83-246-9119-7
stron: 296, Format: ebook
Data wydania: 2014-08-11
Księgarnia: Helion

Cena książki: 32,45 zł (poprzednio: 57,95 zł)
Oszczędzasz: 44% (-25,50 zł)

Dodaj do koszyka Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie

Tagi: Inne - Programowanie | programowanie-kupon

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!

Dodaj do koszyka Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie

 

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

  • DevOps w praktyce. Kurs video. Jenkins, Ansible, Terraform i Docker
  • Wyrażenia regularne od podstaw
  • Projektowanie systemów rozproszonych. Wzorce i paradygmaty dla skalowalnych, niezawodnych usÅ‚ug
  • Zrozum struktury danych. Algorytmy i praca na danych w Javie
  • Kosymulacja. Elastyczne projektowanie i symulacja wielodomenowa

Dodaj do koszyka Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie

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)

Dodaj do koszyka Specyfikacja na przykładach. Poznaj zwinne metody pracy i dostarczaj właściwe oprogramowanie

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.