Architektura Lean w projektach Agile
Tempo rozwoju aplikacji wymusza stosowanie elastycznych sposobów wytwarzania
oprogramowania.
Książka ta została poświęcona architekturze Lean, która usprawni ten proces
dzięki nowatorskiemu podejściu. Wykorzystaj je i przygotuj swoją aplikację na zmiany
funkcjonalne, by użytkownicy mogli w pełni wykorzystać jej potencjał!
W trakcie lektury zapoznasz się z duchem Agile i Lean oraz przydzielisz najważniejsze
role członkom projektu. Po tym niezwykle interesującym wstępie rozpoczniesz
pasjonującą podróż po świecie architektury Lean. Dowiesz się, czym jest system, jak
podzielić projekt na części i wybrać jego styl. W kolejnych rozdziałach zorganizujesz
swój kod i przetestujesz zaprojektowaną architekturę. Znajdziesz tu wiele przykładów,
które w najlepszy sposób przedstawiają założenia i intencje architektury Lean, z
dużym naciskiem na sam kod. To obowiązkowa lektura dla wszystkich programistów i
projektantów systemów informatycznych.
Dzięki tej książce:
poznasz filozofię Agile i Lean
zbudujesz kod odporny na zmiany
zrozumiesz paradygmat DCI
poznasz współczesne metody wytwarzania oprogramowania!
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.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)
320 stron, oprawa miękka
