Architektura Lean w projektach Agile James O. Coplien, Gertrud Bjornvig

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

O autorach (11)

Wstęp (13)

1. Wprowadzenie (19)

• 1.1. Podwaliny: Lean i Agile (19)
• 1.2. Architektura Lean i wytwarzanie funkcji zgodnie z metodyką Agile (22)
• 1.3. Produkcja Agile (24)
  
  • 1.3.1. Agile bazuje na architekturze Lean (24)
  • 1.3.2. Zakres systemów Agile (25)
  • 1.3.3. Agile i DCI (26)
• 1.4. Książka w bardzo małej pigułce (27)
• 1.5. Lean i Agile: kontrastujące i uzupełniające (28)
  
  • 1.5.1. Sekret Lean (30)
• 1.6. Utracone praktyki (30)
  
  • 1.6.1. Architektura (31)
  • 1.6.2. Obsługa zależności pomiędzy wymaganiami (31)
  • 1.6.3. Podstawy użyteczności (31)
  • 1.6.4. Dokumentacja (32)
  • 1.6.5. Zdrowy rozsądek, myślenie i opieka (35)
• 1.7. O czym ta książka nie jest? (36)
• 1.8. Agile, Lean, Scrum i inne metodologie (37)
• 1.9. Rys historyczny (38)

2 . Produkcja Agile w pigułce (41)

• 2.1. Zaangażuj interesariuszy (41)
• 2.2. Zdefiniowanie problemu (43)
• 2.3. Czym system jest: podstawa formy (43)
• 2.4. Czym system jest: siła napędowa systemu (45)
• 2.5. Projekt i kodowanie (46)
• 2.6. Odliczanie: 3, 2, 1... (47)

3. Zaangażowanie interesariuszy (49)

• 3.1. Strumień wartości (49)
  
  • 3.1.1. Użytkownicy końcowi i inni interesariusze jako kotwice strumienia wartości (50)
  • 3.1.2. Architektura w ramach strumienia wartości (51)
  • 3.1.3. Sekret Lean (52)
• 3.2. Najważniejsi interesariusze (54)
  
  • 3.2.1. Użytkownicy docelowi (56)
  • 3.2.2. Biznes (60)
  • 3.2.3. Klienci (61)
  • 3.2.4. Eksperci dziedzinowi (64)
  • 3.2.5. Deweloperzy i testerzy (66)
• 3.3. Elementy procesu angażowania interesariuszy (68)
  
  • 3.3.1. Od czego zacząć? (68)
  • 3.3.2. Zaangażowanie klienta (70)
• 3.4. Sieć interesariuszy: eliminowanie marnotrawstwa czasu (71)
  
  • 3.4.1. Linia produkcyjna czy rój? (71)
  • 3.4.2. Pierwsza rzecz, którą należy zbudować (73)
  • 3.4.3. Utrzymuj jedność zespołu (74)
• 3.5. Nie ma szybkich rozwiązań, ale jest nadzieja (75)

4. Definiowanie problemu (77)

• 4.1. Jakie cechy Agile mają definicje problemów? (78)
• 4.2. Jakie cechy Lean mają definicje problemów? (78)
• 4.3. Dobre i złe definicje problemów (79)
• 4.4. Problemy i rozwiązania (81)
• 4.5. Proces definiowania problemów (82)
  
  • 4.5.1. Ceń bardziej polowanie niż nagrodę (82)
  • 4.5.2. Własność problemu (83)
  • 4.5.3. Przerost funkcjonalności (84)
• 4.6. Definicje problemu, cele, czartery, wizje i zamierzenia (84)
• 4.7. Dokumentacja? (85)

5. Czym jest system? Część I. Architektura Lean (87)

• 5.1. Kilka niespodzianek o architekturze (88)
  
  • 5.1.1. Co Lean ma z tym wspólnego? (90)
  • 5.1.2. Co Agile ma wspólnego z architekturą? (91)
• 5.2. Pierwszy krok w projekcie: podział na części (94)
  
  • 5.2.1. Pierwszy podział: forma dziedzinowa a forma behawioralna (95)
  • 5.2.2. Drugi podział: prawo Conwaya (96)
  • 5.2.3. Rzeczywista złożoność podziału systemu (98)
  • 5.2.4. Wymiary złożoności (99)
  • 5.2.5. Dziedziny. Wyjątkowy podział (99)
  • 5.2.6. Wracamy do wymiarów złożoności (101)
  • 5.2.7. Architektura i kultura (104)
  • 5.2.8. Wnioski na temat prawa Conwaya (105)
• 5.3. Drugi krok w projekcie: wybór stylu projektu (105)
  
  • 5.3.1. Struktura a podział (106)
  • 5.3.2. Podstawy stylu: części stałe i zmienne (107)
  • 5.3.3. Zaczynamy od oczywistych części wspólnych i różnic (108)
  • 5.3.4. Części wspólne, różnice i zakres (111)
  • 5.3.5. Jawne wyrażanie części wspólnych i różnic (113)
  • 5.3.6. Najpopularniejszy styl: programowanie obiektowe (116)
  • 5.3.7. Inne style w obrębie świata von Neumanna (118)
  • 5.3.8. Języki dziedzinowe i generatory aplikacji (120)
  • 5.3.9. Formy skodyfikowane: języki wzorców (123)
  • 5.3.10. Oprogramowanie dostawców zewnętrznych i inne paradygmaty (124)
• 5.4. Dokumentacja? (127)
  
  • 5.4.1. Słownik dziedziny (127)
  • 5.4.2. Przenoszenie architektury (128)
• 5.5. Tło historyczne (128)

6. Czym jest system? Część II. Kodowanie (131)

• 6.1. Krok trzeci: szkic kodu (131)
  
  • 6.1.1. Abstrakcyjne klasy bazowe (132)
  • 6.1.2. Warunki wstępne, warunki końcowe i asercje (136)
  • 6.1.3. Skalowanie algorytmów: druga strona statycznych asercji (142)
  • 6.1.4. Forma a dostępne usługi (143)
  • 6.1.5. Rusztowanie (144)
  • 6.1.6. Testowanie architektury (146)
• 6.2. Relacje w architekturze (149)
  
  • 6.2.1. Typy relacji (149)
  • 6.2.2. Testowanie relacji (150)
• 6.3. Programowanie obiektowe "po nowemu" (151)
• 6.4. Ile architektury? (153)
  
  • 6.4.1. Równowaga pomiędzy BUFD a YAGNI (154)
  • 6.4.2. Jeden rozmiar nie pasuje wszystkim (154)
  • 6.4.3. Kiedy architektura jest gotowa? (156)
• 6.5. Dokumentacja? (156)
• 6.6. Tło historyczne (157)

7. Co system robi: funkcje systemu (159)

• 7.1. Co system robi? (160)
  
  • 7.1.1. Opowieści użytkowników: początek (160)
  • 7.1.2. Wykorzystanie specyfikacji i przypadków użycia (161)
  • 7.1.3. Pomoc należy się także programistom (162)
  • 7.1.4. Kilometraż nie zawsze jest taki sam (163)
• 7.2. Kto będzie korzystać z naszego oprogramowania? (164)
  
  • 7.2.1. Profile użytkowników (164)
  • 7.2.2. Osoby (164)
  • 7.2.3. Profile użytkowników czy osoby? (165)
  • 7.2.4. Role użytkowników i terminologia (165)
• 7.3. Do czego użytkownicy chcą wykorzystać nasze oprogramowanie? (166)
  
  • 7.3.1. Lista własności (166)
  • 7.3.2. Diagramy przepływu danych (166)
  • 7.3.3. Osoby i scenariusze (167)
  • 7.3.4. Narracje (167)
  • 7.3.5. Projektowanie aplikacji sterowane zachowaniami (167)
  • 7.3.6. Teraz, gdy jesteśmy rozgrzani... (168)
• 7.4. Dlaczego użytkownicy chcą korzystać z naszego oprogramowania? (169)
• 7.5. Konsolidacja tego, co system robi (170)
  
  • 7.5.1. Widok helikoptera (172)
  • 7.5.2. Ustawianie sceny (177)
  • 7.5.3. Odtwarzanie scenariusza słonecznego dnia (178)
  • 7.5.4. Dodawanie interesujących rzeczy (183)
  • 7.5.5. Od przypadków użycia do ról (191)
• 7.6. Podsumowanie (193)
  
  • 7.6.1. Wsparcie przepływu pracy użytkowników (193)
  • 7.6.2. Wsparcie dla testów blisko prac rozwojowych (193)
  • 7.6.3. Wsparcie dla wydajnego podejmowania decyzji na temat funkcjonalności (194)
  • 7.6.4. Wsparcie dla nowo powstających wymagań (odchyleń) (194)
  • 7.6.5. Wsparcie dla planowania wydań (194)
  • 7.6.6. Uzyskanie danych wejściowych do opracowania architektury (195)
  • 7.6.7. Budowanie w zespole zrozumienia przedmiotu pracy (195)
• 7.7. "To zależy": kiedy przypadki użycia nie są dobre? (196)
  
  • 7.7.1. Klasyczne programowanie obiektowe: architektury atomowych zdarzeń (196)
• 7.8. Testowanie użyteczności (197)
• 7.9. Dokumentacja? (198)
• 7.10. Tło historyczne (200)

8. Kodowanie: podstawowy montaż (201)

• 8.1. Obraz z góry: wzorzec projektowy Model-View-Controller-User (201)
  
  • 8.1.1. Czym jest program? (202)
  • 8.1.2. Czym jest program Agile? (203)
  • 8.1.3. MVC bardziej szczegółowo (204)
  • 8.1.4. MVC-U: to nie koniec opowieści (205)
• 8.2. Forma i architektura systemów zdarzeń atomowych (208)
  
  • 8.2.1. Obiekty dziedziny (208)
  • 8.2.2. Role obiektów, interfejsy i Model (208)
  • 8.2.3. Refleksje: przypadki użycia, architektury zdarzeń atomowych i algorytmy (211)
  • 8.2.4. Przypadek specjalny: odwzorowanie ról obiektów na obiekty typu jeden do wielu (212)
• 8.3. Aktualizacja logiki dziedziny: rozwijanie metod, faktoryzacja i refaktoryzacja (212)
  
  • 8.3.1. Tworzenie nowych klas i wypełnianie istniejących namiastek funkcji (213)
  • 8.3.2. Powrót do przyszłości: po prostu stare, dobre programowanie obiektowe (215)
  • 8.3.3. Narzędzia analizy i projektowania (215)
  • 8.3.4. Faktoryzacja (216)
  • 8.3.5. Uwaga na refaktoryzację (216)
• 8.4. Dokumentacja? (217)
• 8.5. Do czego te wszystkie artefakty? (217)
• 8.6. Tło historyczne (218)

9. Kodowanie: architektura DCI (219)

• 9.1. Czasami inteligentne obiekty po prostu są niewystarczające (219)
• 9.2. DCI w pigułce (220)
• 9.3. Przegląd architektury DCI (221)
  
  • 9.3.1. Części modelu mentalnego użytkownika końcowego, o których zapomnieliśmy (221)
  • 9.3.2. Wprowadzenie ról obiektowych z metodami (223)
  • 9.3.3. Sztuczki z cechami (225)
  • 9.3.4. Klasy kontekstu: jedna w każdym przypadku użycia (226)
• 9.4. DCI na przykładzie (229)
  
  • 9.4.1. Dane wejściowe do projektu (229)
  • 9.4.2. Od przypadków użycia do algorytmów (230)
  • 9.4.3. Bezmetodowe role obiektów: framework dla identyfikatorów (232)
  • 9.4.4. Podział algorytmów pomiędzy role obiektowe z metodami (234)
  • 9.4.5. Framework kontekstu (241)
  • 9.4.6. Warianty i sztuczki w architekturze DCI (259)
• 9.5. Aktualizacja logiki dziedziny (261)
  
  • 9.5.1. Porównanie DCI ze stylem architektury zdarzeń atomowych (261)
  • 9.5.2. Szczególne aspekty logiki dziedzinowej w architekturze DCI (263)
• 9.6. Obiekty kontekstu w modelu mentalnym użytkownika końcowego: rozwiązanie odwiecznego problemu (265)
• 9.7. Do czego te wszystkie artefakty? (269)
• 9.8. Nie tylko C++: DCI w innych językach (272)
  
  • 9.8.1. Scala (272)
  • 9.8.2. Python (273)
  • 9.8.3. C# (273)
  • 9.8.4. ...a nawet w Javie (273)
  • 9.8.5. Przykład z rachunkami w Smalltalku (274)
• 9.9. Dokumentacja? (274)
• 9.10. Tło historyczne (275)
  
  • 9.10.1. DCI a programowanie aspektowe (275)
  • 9.10.2. Inne podejścia (276)

10. Epilog (277)

A. Implementacja przykładu architektury DCI w Scali (279)

B. Przykład implementacji rachunków w Pythonie (283)

C. Przykład implementacji rachunków w C# (287)

D. Przykład implementacji rachunków w Ruby (291)

E. Qi4j (297)

F. Przykład implementacji rachunków w Squeaku (299)

Bibliografia (307)

Skorowidz (317)

pokaż cały spis treści

ukryj recenzje