Jak odbywa się projektowanie architektoniczne w zwinnym środowisku?

59

Przeczytałem Zasady dla zwinnego architekta , w których zdefiniowano kolejne zasady:

Zasada nr 1 Zespoły kodujące system projektują system.
Zasada nr 2 Zbuduj najprostszą architekturę, która może działać.
Zasada nr 3 W razie wątpliwości należy je zakodować.
Zasada # 4 Budują to, testują.
Zasada nr 5 Im większy system, tym dłuższy pas startowy.
Zasada # 6 Architektura systemu to współpraca roli.
Zasada nr 7 Nie ma monopolu na innowacje.

Artykuł mówi, że większość projektowania architektury jest wykonywana podczas fazy kodowania, a tylko projekt systemu wcześniej. W porządku.

Jak więc odbywa się projektowanie systemu? Używasz UML? Lub dokument definiujący interfejsy i główne bloki? Może coś jeszcze?

BЈовић
źródło
11
Nie wykonujesz projektu w UML. Wykonujesz projekt, a następnie używasz języka UML, aby go zapisać lub przekazać.
tdammers
4
@tdammers: ściślej mówiąc, próbujesz użyć UMLa, aby go zapisać i zauważyć, że UML nie jest wystarczający.
Doc Brown

Odpowiedzi:

77

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):

  1. 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.
  2. 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.
  3. 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.
  4. 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.

akton
źródło
3
To świetna odpowiedź na to, jaką rolę powinna odgrywać architekt w zespole Agile, ale tak naprawdę nie odpowiada na pytanie o to, czym jest Projektowanie Systemu przed rozpoczęciem rozwoju sprintu i najlepszych praktyk, aby to zrobić.
wałek klonowy
@maple_shaft Rozszerzyłem swoją odpowiedź, aby bardziej skupić się na projektowaniu.
akton
3
Warto zwrócić uwagę na to, że jako kolejny architekt, który od kilku lat pracuje w zwinnych środowiskach w dużych międzynarodowych korporacjach.
Rex M
12

Oświadczenie: Nie jestem zwinnym trenerem / architektem - to właśnie widziałem w zwinnych projektach, nad którymi pracowałem i myślę, że działa dobrze.

Nie sądzę, że jest to całkiem zdefiniowane przez Agile, jak robisz architekturę - zwinny koncentruje się na metodologiach i praktykach programistycznych. Z drugiej strony, UML to tylko język komunikacji z architekturą, która jest poza zwinna (używasz go, jeśli pasuje do twojego projektu i twojego zespołu).

Jedną z zasad architektury, która naprawdę ma zastosowanie, jest podjęcie decyzji w ostatnim możliwym odpowiedzialnym momencie - co oznacza, że ​​będzie dobrze, jeśli nie podejmiesz wszystkich decyzji na początku projektu, zwłaszcza, że ​​na tym etapie masz najmniej informacji. Z czasem możesz podejmować decyzje, które „rozwijają” architekturę. Tak, może to wyglądać na przeróbkę, ale wynika to również z faktu, że nauczyłeś się nowych rzeczy na temat środowiska, wymagań, co jest możliwe, czego nie ma itp.

Najważniejszą rzeczą, której chciałbyś uniknąć, jest zgnilizna architektury - gdzie kod tak naprawdę nie jest zgodny z żadną konkretną architekturą i jest tylko splątanym bałaganem. Główną różnicą w porównaniu do ewolucji architektury jest to, że w tym drugim przypadku podejmujesz okresowe świadome decyzje i dokumentujesz je z jasnych powodów, a następnie postępujesz zgodnie z tym, aby upewnić się, że kod podąża za nim.

Roopesh Shenoy
źródło
0

Podczas programowania opartego na testach tworzysz kod testowy, który testuje twoje moduły w izolacji (= możliwie najbardziej niezależny od innych modułów)

Aby ułatwić tworzenie kodu testowego, wprowadzasz interfejsy do innych modułów, które można łatwo wyśmiewać.

W ten sposób jako efekt boczny automatycznie otrzymujesz architekturę, w której sprzężenie między modułami jest tak małe, jak to możliwe.

Moim zdaniem tdd to także dzieło architektoniczne.

k3b
źródło
Tak, TDD jest dziełem architektonicznym, ale dotyczy komponentów oprogramowania. Moje pytanie jest naprawdę, w jaki sposób architektura dużego projektu jest tworzona przy użyciu zwinnych zasad.
BЈовић