Programuj i organizuj kod z metodykÄ… Lean!

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!

Twój przewodnik po architekturze Lean!

Osoby które kupowały "Architektura Lean w projektach Agile", wybierały także:

• Mapa Agile & Scrum. Jak si 57,69 zÅ‚, (15,00 zÅ‚ -74%)
• TDD. Sztuka tworzenia dobrego kodu 48,54 zÅ‚, (19,90 zÅ‚ -59%)
• Doskona 67,00 zÅ‚, (33,50 zÅ‚ -50%)
• Miejsce przy stole. Przywództwo w IT w czasach Agile 49,00 zÅ‚, (24,50 zÅ‚ -50%)
• Czysty Agile. Powrót do podstaw 47,00 zÅ‚, (23,50 zÅ‚ -50%)

Spis treści

Architektura Lean w projektach Agile -- spis treści

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)