Zastrzeżenie: ja jestem architektem w agile środowiska, ale jak Helmut Karl Bernhard von Moltke mówi: „Żaden plan bitwy przetrwa kontaktu z wrogiem”. Innymi słowy, praktyczność oznacza, że nie zawsze można przestrzegać dokładnej litery wytycznych.
Większość punktów zebranych powyżej jest przestrzegana najlepiej, jak potrafi drużyna. Jednak zasada 1 (Zespoły, które kodują system projektujący system) jest naprawdę trudna do przestrzegania, gdy zespół składa się z dziesiątek (lub setek) programistów podzielonych na różne kontynenty i strefy czasowe . Nie ma to nic wspólnego z umiejętnościami i postawami programistów, a bardziej z logistycznym problemem ich obecności w celu zebrania wymagań od klientów i zrozumienia istniejących złożonych systemów.
Jak więc odbywa się projektowanie systemu? Używasz UML? Lub dokument definiujący interfejsy i główne bloki? Może coś jeszcze?
Często architekt identyfikuje główne komponenty, a następnie definiuje interfejsy między nimi (w tym niefunkcjonalne wymagania, takie jak bezpieczeństwo, szybkość i niezawodność) i przekazuje wewnętrzny projekt komponentów poszczególnym zespołom . Jest to dobry kompromis między pozwoleniem zespołom na projektowanie własnych komponentów bez konieczności od wszystkich posiadania wiedzy na temat systemu.
Każda organizacja ma swój własny zestaw standardów dla projektów architektonicznych, który czasem różni się w zależności od projektu w organizacji. Ten projekt wykonany przed rozpoczęciem kodowania przez zespół lub tak wcześnie, jak to możliwe i zwykle zawiera (i nie jest to pełna lista):
- Rozszerzone wymagania i definicja zakresu. Należą do nich przypadki użycia lub historie użytkowników, które spełniają wyższe wymagania biznesowe. Osobiście lubię używać RFC 2119 do wymagań niefunkcjonalnych. Projekt opiera się na nich i wywodzi się z nich. Chociaż może nie pasować do wspólnej definicji projektu, są one często równie ważne.
- Przegląd składający się z diagramu sieci wysokiego poziomu lub komponentu oraz strony tekstu. To jest dla bardzo szerokiego grona odbiorców, od wyższej kadry kierowniczej po deweloperów i QA. To rzadko używa UML lub określonej notacji ze względu na szerokie grono odbiorców.
- Szczegóły dotyczące poszczególnych komponentów, często koncentrując się na interfejsach lub interfejsach API między nimi, jak wspomniano powyżej. Interfejsy mogą być określone jako sygnatury metod w języku docelowym ze szczegółowymi warunkami wstępnymi i późniejszymi. Komponenty mogą mieć diagramy sieciowe, na przykład przedstawiające układ maszyn wirtualnych w chmurze lub centrum danych i ich układy sieciowe. Relacyjne bazy danych zwykle zawierają diagramy relacji encja.
- Lista ryzyk architektonicznych i ich złagodzenie, jeśli są znane. Podobnie jak wymagania, wykazują one decyzje projektowe i kompromisy.
Krótko mówiąc, konstrukcja systemu w zwinnym procesie jest dokładnie taka sama jak w tradycyjnym procesie wodospadowym. Jednak w zwinnych środowiskach mniej prac projektowych odbywa się z góry, a więcej jest przekazywanych zespołom składowym . Kluczem jest określenie, jak głęboko sięgać początkowo, które decyzje odłożyć na później i określenie, kiedy należy podjąć decyzję. Decyzje mające wpływ na wiele zespołów programistycznych powinny być podejmowane wcześniej, zwłaszcza na skalowalność i bezpieczeństwo. Decyzje takie jak dodanie dodatkowych języków do już umiędzynarodowionego produktu można odłożyć na później.
Po utworzeniu wstępnego projektu architekt współpracuje z każdym z zespołów i sprawdza ich projekty. Jeśli dla jednostki pracy wymagane są dodatkowe zmiany konstrukcyjne lub projektowe (takie jak sprint scrum), architekt dąży do tego, aby była ona dostępna do czasu rozpoczęcia tej jednostki pracy. Architekt jest również odpowiedzialny za przekazywanie wszelkich zmian zespołom lub interesariuszom, których to dotyczy.