Tworzenie architektury oprogramowania. Wspieranie zespołów w podejmowaniu trafnych decyzji Gliwice

Rola architekta oprogramowania się zmienia. W miarę jak systemy stają się coraz bardziej złożone, tradycyjny model działania architekta przestaje wystarczać. Zadań jest zbyt wiele, a ich zaniedbanie w końcu doprowadzi do punktu krytycznego. Kluczowe staje się współdziałanie architekta z zespołem projektowym - tylko wtedy możliwe jest tworzenie trwałej, elastycznej i efektywnej architektury. Oto książka pełna praktycznej mądrości, trafiająca w sedno tego, czym jest architektura. Grady Booch, IBM Fellow Tę książkę doceni każdy, kto praktykuje architekturę w ramach i na rzecz zespołu. Dzięki niej zrozumiesz wady scentralizowanych praktyk architektury w zdecentralizowanym świecie. Poznasz też kluczowe aspekty zdecentralizowanego podejścia do architektury opartego na informacji zwrotnej i zasady wdrażania takiego podejścia. Znajdziesz tu omówienie czynników wpływających na efektywność decyzji architektonicznych, a także ich społeczny wymiar - dobra architektura bowiem to nie tylko struktura kodu, ale również jakość współpracy. Dzięki opisanym metodom rozwiniesz sposób myślenia, który pozwala każdemu w zespole praktykować architekturę i budować lepsze systemy. Najciekawsze zagadnienia: jak się zmienia nowoczesny proces dostarczania oprogramowania metodologia łączenia architektury oprogramowania z jego rozwojem współzależność decyzji, architektury i informacji zwrotnej z działających systemów wprowadzanie praktyk maksymalizacji korzyści i minimalizacji ryzyka dostrajanie podejścia do architektury, umiejętności osób w zespole i kultury firmy Najlepsza architektura oprogramowania ewoluuje dzięki zaangażowaniu wszystkich. Martin Fowler, główny badacz w Thoughtworks Spis treści: Słowo wstępne Przedmowa 1. Praktyki dotyczące scentralizowanej architektury w zdecentralizowanym świecie Kluczem do sukcesu jest zarówno praktyka, jak i końcowy rezultat architektury oprogramowania Jakie są praktyki w przypadku tradycyjnej architektury? Architekci z wieży z kości słoniowej Architekci praktyczni Na czym polega problem z obydwoma tradycyjnymi podejściami? Pięć rewolucji, które uwolniły moc oprogramowania Wpływ pięciu rewolucji na praktykę architektury Rozkwit decentralizacji Zmierzch scentralizowanych praktyk architektury Co musi zapewniać każda nowa praktyka architektury? Żadne podejście nie ochroni przed siłami chaosu Architektury powinny uwzględniać niepewność Architektury powinny dopuszczać emergencję Podsumowanie Część 1. Podstawowe zasady 2. Projektowanie architektury to podejmowanie decyzji Decyzje są podstawą architektury oprogramowania Co stanowi decyzję architektoniczną? Struktura Cechy wielofunkcyjne Zależności Interfejsy Techniki budowania Przykłady decyzji architektonicznych i niearchitektonicznych Kto podejmuje te decyzje architektoniczne? Istotne decyzje architektoniczne Co sprawia, że decyzja architektoniczna jest "istotna"? Czego nie należy brać pod uwagę przy ocenie znaczenia z punktu widzenia architektury? Znaczenie architektury w kontekście wdrożonego oprogramowania Przykłady istotnych decyzji architektonicznych Podsumowanie 3. Podejmowanie decyzji na dużą skalę Procesy decyzyjne Etap 1: wymagana decyzja Etap 2: proces podejmowania decyzji Etap 3: wdrożenie decyzji Gdzie znajduje się stan równowagi władzy w procesach decyzyjnych? Tradycyjne podejścia architektoniczne niewystarczająco angażują zespoły w etap tworzenia opcji w procesie decyzyjnym Procesy decyzyjne na dużą skalę Standardowe podejścia przy podejmowaniu decyzji na dużą skalę Procesy decyzyjne w zrewolucjonizowanym świecie Podsumowanie 4. Proces doradztwa w kwestii architektury Potrzeba szybszego i zdecentralizowanego procesu decyzyjnego Proces doradztwa w kwestii architektury: jedna reguła, dwie grupy doradcze i jedna umowa Proces doradztwa w kwestii architektury jest szybki Proces doradztwa w kwestii architektury jest zdecentralizowany Proces doradztwa w kwestii architektury prowadzi do umowy społecznej Dwa przykłady praktycznego zastosowania procesu doradztwa w kwestii architektury Historia 1: zespół projektowy decyduje się na użycie przełączników wersji Historia 2: architekt postanawia rozwiązać problem z przepływem pracy Kluczowa rola porad Porady to sugerowane wskazówki wraz z uzasadnieniem Wspomaganie radą decydentów i osób tworzących opcje Odpowiedzialnym czyni Cię nie udzielanie porady, lecz podejmowanie decyzji Znaczenie rozmów Znaczenie zaufania Podsumowanie 5. Wdrażanie procesu doradztwa w kwestii architektury Pierwsze kroki Jeśli już masz uprawnienia do podejmowania decyzji Jeśli obecnie nie masz uprawnień do podejmowania decyzji Niezależnie od punktu wyjścia zacznij od czegoś niewielkiego Pokonywanie początkowych wyzwań Wyjaśnij proces doradztwa dotyczącego architektury wszystkim zaangażowanym osobom Szukaj porad u właściwych osób Pytaj właściwe osoby i otrzymuj uzasadnienie Ustal wprost, kto odpowiada za poszczególne decyzje Obawy dotyczące wiarygodności wynikające z procesu doradztwa w kwestii architektury Brak pewności co do podejmowania decyzji Brak pewności siebie w szukaniu i udzielaniu porad Brak pewności co do pełnego obrazu sytuacji Podsumowanie 6. Dokumenty ADR Wprowadzenie do dokumentów ADR Struktura dokumentu ADR Tytuł Elementy meta Decyzja Kontekst Opcje Konsekwencje Porady Przygotowywanie dokumentu ADR w celu wsparcia podejmowania decyzji Krok 1: utwórz pusty dokument ADR i ustaw jego metadane Krok 2: utwórz kontekst Krok 3: opracuj opcje i rozważ ich konsekwencje Krok 4: zaproponuj wybraną opcję Użycie dokumentów ADR w celu ułatwienia procesu doradztwa Kiedy i jak szukać porad? Przygotowywanie sekcji porad Uzyskiwanie porad Aktualizowanie dokumentu ADR w celu uwzględnienia wkładu innych osób Podejmowanie decyzji i finalizowanie dokumentu ADR Wybierz opcję decyzji Utwórz sekcję swojej decyzji i zaktualizuj tytuł Zmiana statusu dokumentu ADR na Zaakceptowano Poinformowanie o decyzji Cykl życia dokumentu ADR Standardowe statusy: Wersja robocza, Proponowane, Przyjęto i Zastąpiono Niestandardowe statusy dokumentu ADR Zarządzanie dokumentami ADR Fundamentalne aspekty zarządzania dokumentami ADR Dokumenty ADR na stronach wiki i pliki tekstowe z formatowaniem w systemie kontroli wersji Dokumenty ADR w systemach obsługi zgłoszeń Nadzór nad dokumentami ADR Podsumowanie Część II. Kształtowanie i rozwijanie kultury zdecentralizowanego zaufania 7. Zastępowanie hierarchii zdecentralizowanym zaufaniem Zmiana zakresu odpowiedzialności Większość tradycyjnych praktyk nadzoru staje się przestarzała Proces doradztwa jest zgodny z istniejącymi strukturami architektury korporacyjnej Bezpośrednia odpowiedzialność za dokument ADR jako zabezpieczenie przed lekkomyślnością Zespoły nie muszą podejmować decyzji Rozszerzanie obszaru praktyki architektury Tworzenie przestrzeni dla kultury uczenia się i zaufania Dwa przykłady zaufania (lub jego braku) w praktyce Nie można zakładać, że kultura zaufania i nauki pojawi się sama z siebie Kulturę zaufania i nauki trzeba starannie kształtować Zmieniająca się dynamika w firmach o różnej wielkości Adaptowanie elementów wspierających w celu ochrony przestrzeni zaufania Ochrona przestrzeni praktyki architektury Brak standardowego zalecenia dotyczącego elementów wspierających Dostosuj dowolny element wspierający Przemyśl swoją motywację, zanim coś dodasz Netflix: przykład sposobu myślenia zmierzającego do znalezienia przepływu Strzeż się zwodniczych obietnic pewności i przewidywalności Eksperyment w celu znalezienia przepływu w Twojej firmie Podsumowanie 8. Forum porad architektonicznych Wprowadzenie do forum porad architektonicznych Prosty plan spotkania Czym forum porad różni się od tradycyjnych spotkań dotyczących architektury? Prowadzenie forum porad architektonicznych Przed rozpoczęciem forum porad architektonicznych Udostępnianie planu Rozpoczęcie sesji forum porad architektonicznych Prezentowanie dokumentu ADR Udzielanie i przyjmowanie porad Rejestrowanie porad Dynamiczne elementy społeczne na forum porad Interakcje związane z architekturą są z natury antagonistyczne i hierarchiczne Argumentacja koalescencyjna: alternatywa podejścia konfrontacyjnego Proces doradztwa architektonicznego i dokumenty ADR jako spójne podejście do podejmowania decyzji Fora porad przyspieszają skuteczną dynamikę grup Doświadczenie w przypadku osób udzielających porad Doświadczenie w przypadku osób poszukujących porady Doświadczenie w przypadku uczących się obserwatorów Wspólne uczestnictwo w praktycznej kreatywności Fora porad architektonicznych wspierają integrację koncepcyjną i spójność społeczną Decentralizacja wykonywania przy jednoczesnej centralizacji koordynacji Obszerna wiedza z danej dziedziny: kiedy centralizacja sprawdza się najlepiej? Przejrzystość w kwestii spójności społecznej i zaufania Rytuał wzmacniania rytmu Rozpoczynanie procesu doradztwa z wykorzystaniem forum porad Zakres działań Użycie forum porad do rozpoczęcia procesu doradztwa Kto zwołuje pierwsze forum porad? Czym pierwsze forum porad będzie się różnić od kolejnych? Podsumowanie 9. Możliwe do przetestowania wymagania CFR oraz strategia technologiczna Znaczenie dopasowania organizacyjnego Dopasowanie nie gwarantuje skuteczności Wykrywanie niedostatecznego dopasowania organizacyjnego Cztery sposoby zapewnienia dopasowania Istnieje dopasowanie, gdy nic Cię nie zaskakuje Minimalnie satysfakcjonujące porozumienie Wymagania CFR Strategia technologiczna Dążenie do minimalnie satysfakcjonującego porozumienia w Twojej firmie Podsumowanie 10. Zasady architektoniczne oparte na doświadczeniu grupy Pozyskuj zasady architektoniczne od wszystkich zaangażowanych osób Przykłady zasad architektonicznych Cechy dobrych zasad architektonicznych Cechy kiepskich zasad architektonicznych Zasady mogą być ukrytymi wymaganiami CFR Zasady architektoniczne uzupełniają proces doradztwa i dokumenty ADR Określanie zasad architektonicznych podczas warsztatów Przygotowanie danych wejściowych na warsztaty dotyczące zasad Przygotowywanie warsztatów dotyczących zasad Prowadzenie warsztatów dotyczących zasad Prezentacja zasad gotowych do zastosowania Zachowanie użyteczności zasad Informacje zwrotne z decyzji powinny wpływać na zasady architektoniczne Aktualizacja i utrzymywanie zasad Informacje zwrotne z decyzji mogą wpływać na strategię techniczną Podsumowanie 11. Zastosowanie radaru technologicznego Rozpoznawanie trendów technologicznych i wytycznych dotyczących wychwytywania Radary technologiczne nieustannie zbierają i udostępniają wytyczne Sposób działania radaru technologicznego firmy Thoughtworks Twój wewnętrzny radar technologiczny będzie miał inną strukturę Miejsce Twojego radaru w procesie doradztwa Tworzenie własnego radaru technologicznego Gromadzenie punktów Sortowanie i sprawdzanie poprawności punktów Doprecyzowanie punktów Pozycjonowanie punktów Dokumentowanie punktów Publikowanie radaru Aktualizowanie punktów Okresowe przeglądy Doraźne aktualizacje oparte na wspólnych doświadczeniach Gromadzenie poprzednich punktów i ich historii Podsumowanie Część III. Poruszanie się w środowisku decyzyjnym 12. Sztuka podejmowania decyzji Znaczenie "miękkich" aspektów Ustalanie ram kontekstu Wykluczanie jest równie ważne jak dołączanie Pytania usprawniające ocenę sytuacji podczas ustalania ram Zaangażuj właściwe zainteresowane osoby Analiza opcji i ich konsekwencji Nie pozwól, aby ramy ograniczały Twoją kreatywność Szukaj inspiracji Doprecyzuj kontekst i opcje dzięki poradom Rozwijaj swoje umiejętności metapoznawcze Ćwiczenie 1: podziel się swoimi powodami Ćwiczenie 2: reagujesz odruchowo czy świadomie? Ćwiczenie 3: celowo szukaj porad, które są dla Ciebie wyzwaniem Radzenie sobie z osobami, które nie współpracują Wybór opcji decyzyjnej Pokonywanie strachu Przezwyciężanie uprzedzeń Podejmowanie decyzji Moment podejmowania decyzji Gdy inni podejmują decyzję Podsumowanie 13. Radzenie sobie ze zmiennością architektoniczną Wpływ zmienności na praktykę architektury Zmienność utrudnia projektowanie systemów Zmienność to fundament projektowania oprogramowania Skuteczne radzenie sobie ze zmiennością architektoniczną Radź sobie ze zmiennością przez szybkie podejmowanie i testowanie decyzji Dokładne testowanie decyzji w ich kontekście funkcjonalnym Użycie przemieszczających się prototypów do testowania najwcześniejszych decyzji w ich kontekście funkcjonalnym Radzenie sobie ze zmiennością przez podejmowanie mniejszych decyzji Wpływ decyzji architektonicznych na przyszły przepływ Dobra infrastruktura techniczna umożliwia podejmowanie małych decyzji Dobra infrastruktura socjotechniczna także umożliwia podejmowanie drobnych decyzji Wykorzystanie procesu doradztwa do eliminacji sprzężenia decyzji pod kątem przepływu Wykorzystanie zmienności do eliminowania ryzyka i ujawniania wartości Lepiej szybko i źle niż wolno i poprawnie Zwróć uwagę na wartości odstające Najpierw podejmuj najbardziej wartościowe decyzje Podsumowanie 14. Zmienność i wzajemne powiązania decyzji Odnajdywanie ścieżki w zmienności Wprowadzenie do techniki spike Technika spike umożliwia radzenie sobie ze zmiennością architektoniczną w tańszy sposób Gdzie w procesie decyzyjnym stosuje się technikę spike? Zastosowanie techniki spike w odniesieniu do dokumentów ADR Dokumenty ADR z użytym elementem techniki spike nadal przestrzegają procesu doradztwa Sprawdzanie wzajemnych powiązań decyzji Decyzje to seria Hierarchia decyzji jest odwrócona Decyzje są atomowe Decyzje to dwustronne konwersacje Powiązane decyzje są społecznie skomplikowane Podsumowanie Część IV. Umieszczenie elementu społecznego w centrum swojej praktyki architektury 15. Zmiany w zakresie władzy i odpowiedzialności Zmiany władzy nigdy nie są proste Przejście w przypadku osób zdobywających władzę Czy każdy wierzy w to, że ma prawo decydować? Czy wszyscy rozumieją zakres swojej odpowiedzialności? Dlaczego ludzie nie korzystają z udostępnionych im uprawnień? Znaczenie bezpieczeństwa Zmiana dla osób, które muszą dzielić się władzą Strach wśród tych, którzy oddali władzę Zachowanie osób niezadowolonych z podziału władzy Zmiany bywają niewygodne Podsumowanie 16. O przywództwie Błędne wyobrażenia o przywództwie Błędne przekonanie numer 1: przywództwo jest wrodzone Błędne przekonanie numer 2: przywództwo jest związane z hierarchią Błędne przekonanie numer 3: przywództwo działa tylko w jednym kierunku Błędne przekonanie numer 4: przywództwo to zarządzanie Czym jest przywództwo? 14 zasad Deminga Przywództwo służebne Przywództwo adaptacyjne Przywództwo partnerskie Wyzwania związane z przejściem na model przywództwa partnerskiego Potrzeba ciągłego przywództwa moralnego Radzenie sobie z wyzwaniami moralnymi Bądź wrażliwy na wszystkie obecne kultury, ale nie bądź im podporządkowany Nie ma "stałych liderów" Podsumowanie 17. Dopasowanie procesu doradztwa do Twojej firmy Subkultura inżynierii oprogramowania Powód 1: projektowanie oprogramowania nie podąża za standardowymi modelami myślowymi procesu twórczego Powód 2: tempo zmian w działach informatycznych jest znacznie wyższe niż gdziekolwiek indziej Powód 3: punkty styku między inżynierią oprogramowania i resztą firmy są nieliczne i wyraźne Powód 4: podział kulturowy między działem inżynierii oprogramowania i resztą firmy jest już akceptowany "Bańki" procesu doradztwa "Bańki" są widoczne tylko dla tych, którzy ich szukają "Bańki" organizują się same "Bańki" są przepuszczalne Zewnętrzne oczekiwania wobec osób wewnątrz "bańki" Oczywiste oczekiwania Mniej oczywiste oczekiwania "Bańki" zapewniają interfejs niezależny od implementacji Kontrakt interfejsu "bańki" Uwidocznij wartościowe działania związane z translacją Powiększające się "bańki" Rozwój przyrostowy zespół po zespole Zadbaj o ochronę podstawowych celów swojej praktyki architektury Dzielenie "baniek", gdy stają się zbyt duże Nic nie może rosnąć w nieskończoność Podziel "bańkę", gdy zagrożone są główne cele Twojej praktyki architektury Sposób podziału "bańki" Zachowanie spójności między "bańkami" Chroń i wspieraj różnice między "bańkami" Podsumowanie O autorze: Andrew Harmel-Law jest głównym specjalistą technicznym w firmie Thoughtworks. Zajmuje się projektowaniem opartym na domenach, modernizacją na dużą skalę i transformacjami organizacyjnymi. Pasjonuje się oprogramowaniem open source, dzieli się swoją wiedzą w ramach szkoleń online, artykułów, publicznych prelekcji i mentoringu.