Czy są jakieś najlepsze praktyki dotyczące przejścia z architektury na rozwój?

Szukamy usprawnienia procesu przekazywania zadań z architektury na rozwój.

Na jednym końcu skali nie ma żadnych wskazówek dotyczących architektury, w których ryzykujesz chaos, a każdy programista robi swoje po swojemu.

Na drugim końcu skali, gdzie wszystko jest określone, specyfikacja trwa dłużej niż programowanie i ryzykujesz bardzo nudnymi zadaniami programistycznymi.

Czy ktoś znalazł optymalny środek między tymi skrajnościami? Jakie artefakty dostarczasz do rozwoju? Na przykład: moduły, struktura klas lub diagramy sekwencji?

Zacznę od stwierdzenia, że ​​sama koncepcja osobnego zespołu „Architektury” jest obrazą dobrych praktyk tworzenia oprogramowania. Zespoły architektury w środowiskach korporacyjnych wydają się być zwieńczeniem najgorszym wieży z kości słoniowej-pseudo-intelektualne byka * * artystów można znaleźć wśród puli deweloperów.

Inne organizacje traktują grupy Architektów jak nagrodę polityczną i uzasadnienie ogromnej pensji dla starszych członków bez względu na zasługi, wiedzę i umiejętności. Większość składa się z obu typów.

Każdy programista może i powinien być architektem i powinien brać udział w projektach wysokiego szczebla firmy. Sama myśl, że jedna grupa ma pełną dyktatorską kontrolę nad każdym aspektem projektowania oprogramowania, i należy ją przekazać programistom, którzy nie przyczynili się do projektu, nie rozumieją powodów wyboru projektu i mogą zrozumieć krytyczne wady ponieważ projekt jest bardziej wygodny i bliższy faktycznej implementacji i istniejącego kodu, jest szczerze całkowicie wadliwy od samego rdzenia i konsekwentnie skutkuje jednym z trzech scenariuszy:

• Deweloperzy nie rozumieją projektu lub całkowicie go odrzucają ze względu na realia obecnej implementacji, a ostatecznie określają własny nieudokumentowany projekt i zamiast tego go wdrażają. Sytuacja dotyczy formalnych dokumentów projektowych, które nie odzwierciedlają wdrożenia oprogramowania.

• Programiści ślepo podążają za projektem, który może brać pod uwagę bieżące wymagania lub unikalne aspekty historii użytkowników, co może powodować błędne i niskiej jakości wdrożenie.

• Inteligentni programiści, którzy rozumieją dokumenty projektowe i potrafią je wdrożyć, szybko się nudzą, nie angażując się w dyskusje na temat projektu. Prawdopodobnie zostali wykluczeni z uczestnictwa w grupie Architektonicznej ze względu na kwestie polityczne lub starszeństwa, więc stają się sfrustrowani, znudzeni i wyjeżdżają na zielone pastwiska. Wpływa to negatywnie na projekt, powodując drenaż mózgów, powodując kontynuowanie błędnego cyklu niskiej jakości oprogramowania.

Najlepszym sposobem na złagodzenie tego problemu jest ZMIANA grupy Architektury i ewentualnie umieszczenie ich na czołowych stanowiskach technologicznych. Rola grupy Architecture powinna być mniej więcej „scrum of Leaders of Technology”, jeśli chcesz. Powinny one rzadko spotykać się i omawiać tylko kwestie techniczne najwyższego poziomu, np. przemyśl dyskusję migrując z Javy do Scali, porzucając Oracle dla MySQL, prawdopodobnie pisząc wspólne biblioteki narzędziowe, które nakazują pewien TYP procesu projektowania nad innym, przechodząc z StarUML na Altova UML.

Rzeczywiste i rzeczywiste projektowanie oprogramowania będzie procesem społecznościowym obejmującym WSZYSTKICH twórców oprogramowania, wyznaczonym przez niezwykle wysoki poziom kierownictwa grupy Architecture.

Zawsze pojawiały się problemy z przepływem informacji od architektury do testów i operacji programistycznych. Sposób rozwiązania tych problemów zależy od kilku czynników, takich jak:

• rozmiar oprogramowania
• złożoność
• kultura w twojej organizacji
• wiara.

W przypadku niektórych kombinacji tych czynników właściwe jest podejście zwinne międzyfunkcyjne zespoły o nowym wyglądzie. Informacje płyną dzięki współpracy. Dyscypliny dokumentują to, czego potrzebują.

W przypadku innych kombinacji tych czynników niewielki zespół architekta, testera, eksperta operacyjnego i wiodących programistów może zacząć od iteracji architektury, powoli budując architekturę, dokumentując i uzyskując natychmiastowe informacje zwrotne na temat swoich decyzji dotyczących architektury. Powoli coraz więcej programistów wdrażających funkcje może zostać dodanych do zespołu, a pierwotny zespół podstawowy może zostać zmniejszony.

Przede wszystkim w przypadku projektów rządowych i finansowych wymagane jest wcześniejsze sporządzenie większej ilości dokumentacji, co może zająć dużo czasu bez rzeczywistych informacji zwrotnych na temat twoich wyborów. Moim zdaniem największym powodem niepowodzenia wielu z tych projektów. Mimo to, jeśli taka jest twoja sytuacja, przygotowałbym dokumentację tak, aby spełniała wymagania. Następnie używałbym opcji 1 lub 2, aby faktycznie zbudować oprogramowanie i udoskonalić / dostosować dokumentację.

Mam nadzieję że to pomoże.

Wiem, że to nie będzie zbyt popularne, ale skomentowałeś

Na drugim końcu skali, jeśli wszystko jest określone, specyfikacja trwa dłużej niż rozwój. Ryzykujesz bardzo nudnymi zadaniami programistycznymi.

jest czymś, o co powinieneś dążyć. Jeśli projekt i specyfikacja są na tyle solidne, że zadania programistyczne są nudne, wówczas koszty rozwoju spadają. Naprawianie specyfikacji jest znacznie tańsze niż naprawianie kodu, a największym kosztem projektów oprogramowania nie jest kompilacja, lecz wsparcie długoterminowe. Obsługa kodu opartego na solidnej specyfikacji jest znacznie tańsza.

Nie do końca zgadzam się z odpowiedzią maple_shaft, ale w komentarzu nie było wystarczająco dużo miejsca, aby powiedzieć cały mój kawałek! ;-)

Zgadzam się, że każdy programista może i powinien być architektem, ale to nie znaczy, że każdy programista powinien być odpowiedzialny za architekturę całego produktu lub systemu. Co więcej, nie sądzę, aby można było pomalować każdy zespół architektoniczny za pomocą tego samego szerokiego pędzla, a po prawidłowym wykonaniu zespoły architektoniczne mogą wnieść wielką wartość do całego procesu opracowywania produktu. Błędne przekonanie jest takie, że architekci powinni dyktować każdy aspekt projektu systemu. Zamiast tego powinni skupić się na projekcie wyższego poziomu i pozostawić szczegóły implementacji swoim zespołom programistycznym. Nie oznacza to jednak, że programiści nie powinni być zaangażowani w proces planowania i projektowania od samego początku.

Im większy i bardziej modułowy, a ostatecznie bardziej złożony produkt, tym bardziej prawdopodobne jest, że znajdziesz różne części produktu obsługiwane przez różne zespoły programistów. Takie zespoły nie muszą rozumieć systemu jako całości, pod warunkiem, że mają pełne zrozumienie części systemu, za które są odpowiedzialne. Często te dodatkowe zespoły są zatrudniane jako podwykonawcy w konkretnym celu opracowania modułu w konkretnym obszarze technologii, w którym architekci lub inne zespoły mogą nie mieć specjalistycznej wiedzy. Moje szczególne talenty polegają na opracowywaniu interfejsów API, a ja jeszcze nie widziałem dobrze przemyślany interfejs API, który został opracowany całkowicie ekologicznie, nie powodując jednocześnie bałaganu pod względem użyteczności lub nie wymagało to, aby ktoś się wyróżniał jako osoba, która zapewniła poziom jednolitości między różnymi aspektami API. Mogę wymienić wiele przykładów i powodów, ale nie sądzę, że takie sytuacje to BS z wieży z kości słoniowej, że wielu może tak uważać. Niestety, istnieje wiele miejsc, szczególnie w sektorach obrony, medycyny i finansów, w których paranoja korporacyjna skutkuje słabo określonym i jeszcze słabiej zarządzanym rozwojem produktu, którego jestem pewien, że najbardziej interesował go wałek klonowy. Sądzę, że są to rzeczy, które nadają architektom trochę źle zasłużone złe imię (ogólnie rzecz biorąc). Niestety, istnieje wiele miejsc, szczególnie w sektorach obrony, medycyny i finansów, w których paranoja korporacyjna skutkuje słabo określonym i jeszcze słabiej zarządzanym rozwojem produktu, którego jestem pewien, że najbardziej interesował go wałek klonowy. Sądzę, że są to rzeczy, które nadają architektom trochę źle zasłużone złe imię (ogólnie rzecz biorąc). Niestety, istnieje wiele miejsc, szczególnie w sektorach obrony, medycyny i finansów, w których paranoja korporacyjna skutkuje słabo określonym i jeszcze słabiej zarządzanym rozwojem produktu, którego jestem pewien, że najbardziej interesował go wałek klonowy. Sądzę, że są to rzeczy, które nadają architektom trochę źle zasłużone złe imię (ogólnie rzecz biorąc).

Więc gdzie jest środek, którego szukał PO? Odpowiedzią jest otwarcie kanałów komunikacji. Architekci muszą przekazać specyfikacje opisujące ich projekty wystarczająco szczegółowo, aby zapewnić, że zespoły programistów zrozumieją, gdzie są granice. Historie i scenariusze fabularne w najszerszym tego słowa znaczeniu, w których wszystko uważa się za czarną skrzynkę. Architekci muszą wtedy zapewnić zespołom dostęp do czasu architekta, aby potwierdzić wszelkie założenia i odpowiedzieć na wszelkie pytania dotyczące specyfikacji, które wydają się zbyt szerokie lub niejasne. Potem naprawdę chodzi o upewnienie się, że poszczególne zespoły są świadome tego, nad czym pracują inne zespoły, i że wiedzą, z kim współpracować z innymi zespołami, aby zapewnić, że każda część systemu będzie dobrze grała z innymi częściami. Te zespoły spotykają się bezpośrednio. Gdy system zostanie zaprojektowany na najszerszym poziomie, architekci powinni być po prostu ludźmi, do których zwracają się zespoły, kiedy potrzebują kontroli poczytalności i aby zapewnić utrzymanie „wizji” produktu. Powinny również uwzględnić każdy wymagany proces integracji i zapewnić bardzo potrzebną „ochronę powietrzną” dla zespołów programistycznych od menedżerów, klientów i innych zainteresowanych stron, zapewniając jednocześnie, że te różne osoby mogą się spotkać, aby wypracować między im, jak rzeczy powinny działać.

Architekci IMHO powinni przede wszystkim być facylitatorami i komunikatorami, a projektantami - drugimi. Co do poziomu specyfikacji? Myślę, że najlepsi architekci to ci, którzy pytają swoje zespoły o poziom szczegółowości, jaki chce zespół, i między nimi znajduje równowagę, która działa. Różne zespoły mogą mieć różne wymagania w zakresie wymaganej ilości dokumentacji lub kierunku. Zespoły seniorów mogą znaleźć z grubsza narysowany schemat i szybka rozmowa może być wystarczająca, aby zacząć, podczas gdy zespoły zapełnione stosunkowo młodymi programistami mogą wymagać nieco więcej, aby je uruchomić. Przede wszystkim architekt musi zachęcać programistów do wykorzystywania własnych talentów projektowych, aby uzyskać najlepszy efekt końcowy z każdego zespołu.

Ponieważ starasz się coś poprawić, już wyczułeś problem w swoim procesie. Przyczyną tej konkretnej sytuacji mogą być następujące: programiści nie mogą identyfikować się z architekturą, ponieważ została narzucona przez kogoś zewnętrznego. Przekazanie architektury rozwojowi najprawdopodobniej nie rozwiąże tej podstawowej przyczyny.

Uczyń architekturę częścią zespołu programistów. Zburz granicę między architektem a deweloperem. Zapewnia to przepływ informacji. Jeśli zespół programistów uczestniczy w kształtowaniu architektury, nie będzie uważał jej za coś obcego. Przekaż zespołowi wiedzę o architekturze. Naucz ich czynników napędzających architekturę korporacyjną, aby uniknąć wspomnianego chaosu. Zaangażuj programistów w decyzje architektoniczne, aby uniknąć nudy, o której wspominałeś. Przekazanie nie jest już wymagane i spełniłeś swoją rolę architekta w zespole programistycznym.

Musisz podać jak najwięcej informacji, aby przyszły zespół mógł zachować kod. Jeśli na przykład nie masz diagramów sekwencji, programista jest zmuszony śledzić kod krok po kroku, marnując w ten sposób czas.

Jest też miejsce dla nowego zespołu, który przyjmuje błędne założenia.

Zasadniczo powinien istnieć dokument dotyczący tego, czym jest projekt, specyfikacji technicznych, przypadków testowania jednostkowego oraz schematów sekwencji / klas.

Powiedziałbym, że widoki diagramów klas, które tworzą zarówno model, jak i kod, są rozwiązaniem. Diagram klas przedstawia statyczny widok architektury projektu. Mam na myśli, że masz pakiety> klasy, interfejsy, wyliczanie> atrybuty, mehtods itp ...> itd. Jeśli dobrze wyglądasz, metamodel UML2 ma dokładnie taką samą strukturę jak projekt java lub dotnet.

W naszych projektach używamy po prostu schematów klas zapisanych w jednym modelu. Generujemy widoki modelu, jeśli klasyfikator już istnieje, lub tworzymy nowy w wersji graficznej, jeśli jest nowy. Programiści mogą zobaczyć nasze diagramy i model, ponieważ zostały zapisane w katalogu głównym folderu projektu w CVS. Podoba mi się to, że programista może modelować, ponieważ jeśli coś zostanie zmienione na poziomie kodu, model zostanie automatycznie zaktualizowany w CVS dla całego zespołu.

Działa naprawdę dobrze i nie trzeba znać UML, ponieważ schemat klas jest naprawdę prosty, a inżynieria odwrotna wykona zadanie i utworzy graficzny widok kodu. Prosta nawigacja, zaawansowane i szczegółowe widoki, w których można dodawać mnóstwo komentarzy z diagramami zawsze aktualnymi i widocznymi w CVS bezpośrednio w projekcie. Mój diagram klas UML jest teraz Magic :-)