W środowisku zwinnym, odpowiedzialnym za architekturę oprogramowania

W zwinnym zespole, kto jest odpowiedzialny za podejmowanie decyzji dotyczących architektury i projektowania na wysokim poziomie, które wpływają na cały system, a nie tylko prace wykonywane w bieżącym sprincie?

Może właściciel produktu, mistrz scrum, zespół scrum lub ktoś inny?

„Architektura oprogramowania jest wykonywana przez cały zespół. Ta praktyka nie eliminuje potrzeby architekta oprogramowania, oznacza tylko, że architekt przyczynia się do dyskusji z szerszą i prawdopodobnie bardziej doświadczoną perspektywą, niemniej wszyscy członkowie zespołu przyczyniają się do architektura oprogramowania ”.

• Źródło: http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

Architekci, oczywiście, ale może nie tradycyjni architekci.

Nie mam na myśli architekta naczelnego, który robi wszystko, a potem zostawia małpy, żeby pisały na maszynie. Mam na myśli doświadczonego głównego programistę, który rozumie koszty i korzyści wynikające z trudnych do cofnięcia decyzji i który doradza zespołom, co robić.

Trudno znaleźć skutecznych architektów, ale może to być fantastyczna pozycja, więc prawdopodobnie masz przynajmniej jednego doświadczonego, przemyślanego programistę, który mógłby to zrobić dobrze. Taka osoba musi

• Podejmuj oczywiście dobre decyzje dotyczące architektury, ale także
• Wiedzieć, jak skutecznie udzielać porad, aby inni mogli się czuć swobodnie, a także
• Powoli deleguj decyzje dotyczące architektury zespołom

Ten ostatni punkt wprawia w osłupienie wielu ludzi. Kiedy agileści o dobrych intencjach mówią takie rzeczy, jak „Zespół jest właścicielem architektury”, mają to „prawo”, ale moja rada jest prawie całkowicie pozbawiona znaczenia. Jeśli zaufałeś zespołom, że wezmą odpowiedzialność za własną architekturę, to nie zadawałbyś tego pytania, prawda ?! W związku z tym zakładam, że zadajesz to pytanie, ponieważ istnieją pewne obawy

• Nikt nie weźmie odpowiedzialności, a my będziemy mieć słabą architekturę, lub
• Niewłaściwi ludzie wezmą na siebie odpowiedzialność, a my będziemy mieć słabą architekturę, lub
• Ktokolwiek bierze odpowiedzialność, stanie się kozłem ofiarnym i masz nadzieję tego uniknąć

Jeśli potrzebujesz kogoś, kto weźmie na siebie odpowiedzialność, daj to komuś , kto chce to zaakceptować. Poważnie. Tej osobie przynajmniej zależy. Daj tej osobie zasoby potrzebne do wykonania pracy i pomóż jej, kiedy będą jej potrzebować. Prawdopodobnie nie ma znaczenia, jak kompetentna jest ta osoba, ponieważ jeśli ją to obchodzi, spróbuje dowiedzieć się, czego musi się nauczyć. Oczywiście taka osoba potrzebuje wsparcia w postaci dobrych książek do przeczytania oraz społeczności rówieśników i mentorów, których mogą poprosić o pomoc i porady.

Jeśli martwisz się, że niewłaściwa osoba bierze na siebie odpowiedzialność, mam nadzieję, że wiesz, kim jest „właściwa osoba” i będzie walczył o zainstalowanie jej jako architekta. Książka taka jak The New Strategic Selling pomoże ci nauczyć się technik sprzedaży, aby tak się stało.

Jeśli potrzebujesz tylko kozła ofiarnego, cicho szturchnij innych, aby ponieść odpowiedzialność za karierę, którą chciałbyś najbardziej zniszczyć lub osłabić. Przynajmniej bądź szczery.

Wracając do pracy skutecznego architekta, mogą myśleć o swojej pracy jako o stanowisku kierowniczym, a nie tylko o stanowisku decyzyjnym. Jeśli nie przekażą przynajmniej najbardziej rutynowych decyzji zespołom, staną się wąskim gardłem i spowolnią całą organizację . Dodanie większej liczby architektów u góry nie przyspiesza tego. Podejmie się od podstaw podejmowanie lepszych decyzji dotyczących architektury. Deska delegacja technika pomoże Twojemu architekt stać się bardziej komfortowo w miarę upływu czasu coraz więcej delegowanie decyzji zespołom jak te zespoły zdobyć zaufanie pokazując kompetencji.

Myślę o wielkim architekcie jako o kimś, kto pomaga mi zrozumieć, jak lepiej projektować moje systemy, który doradzi mi cierpliwie, kiedy o to poproszę, i który czasami powstrzyma mnie od podjęcia bardzo złej decyzji. Taki architekt działa jak lider w najprawdziwszym tego słowa znaczeniu: ktoś, za kim inni dobrowolnie podążają .

Wiem, że to dużo.

Bibliografia

Miller, Nowa sprzedaż strategiczna . Ta książka zawiera model pozwalający zrozumieć, dlaczego nie udało Ci się zamknąć określonej sprzedaży. Uważam to za bezcenne w zrozumieniu, dlaczego współpracownicy nie zrobią oczywiście cudownej rzeczy, którą sugeruję.

Weinberg, zostając liderem technicznym . Ta książka pomogła mi nauczyć się, jak wykonywać niearchitekiczną część pracy skutecznego architekta.

Appelo, tablice delegacji i poker delegacyjny . Nie lekceważ, jak trudna jest delegacja i jak wiele jej to drażemy. Naucz się robić to bardziej efektywnie i wygodniej.

Najlepsze architektury , wymagania i projekty powstają z samoorganizujących się zespołów

- Manifest Agile

Zespół samoorganizuje się, aby podejmować decyzje architektoniczne w sposób, który uzna za stosowny. Nie ma twardej i szybkiej reguły, może obejmować konsensus, „radę” członków najwyższego szczebla, wyznaczenie jednego konkretnego członka jako organu ds. Architektury, pozwolenie architektowi na wybór, czy istnieje członek o takim stanowisku. .

Czuję, że odpowiedź na pytanie „kto jest odpowiedzialny za podejmowanie decyzji dotyczących architektury i projektowania na wysokim poziomie?” Zależy od wielkości i liczby zespołów.

W przypadku jednej lub dwóch drużyn z 3-7 w każdej drużynie zespół samoorganizujący może poradzić sobie z prowadzeniem starszych członków.

W przypadku 3 lub więcej zespołów zwiększona złożoność prowadzi do potrzeby zespołu architektury, który może sprawdzić, czy różne podgrupy wykonują prace, które będą współpracować z innymi zespołami. Z mojego doświadczenia wynika, że ​​punkt ten osiąga się, gdy jest około 8 drużyn lub około 50 osób.

Istnieje kilka świetnych zasobów ze Scaled Agile Framework (SAFe).

Zasadniczo pomaga skalować się sprawnie w całej organizacji, wychodząc poza pojedyncze wydanie i planując portfolio i program. Ich dokumentacja pokazuje sugestie, w jaki sposób zaangażować architektów korporacyjnych i systemowych w proces wprowadzania epopei architektonicznych do serii wydawniczej.

Edytuj dla jasności, aby bardziej bezpośrednio odpowiedzieć na pytanie:

W skalowanym, zwinnym środowisku istnieje wiele poziomów własności architektury. Zwinny zespół wdrożeniowy będzie właścicielem powstającej architektury niskiego poziomu poprzez refaktoryzację w razie potrzeby, aby kontynuować wdrażanie zaległości. Decyzje architektoniczne na wyższym poziomie (obsługiwane systemy operacyjne, przeglądarki, platformy, biblioteki) leżą w gestii systemu i architektów przedsiębiorstwa. Przedstawią przypadki biznesowe, w których należy wprowadzić te zmiany, i zalecą dodanie tych zmian architektonicznych do pakietu wydawniczego dla zespołów wdrożeniowych.

Tak więc, jeśli chodzi o decyzje dotyczące architektury na wysokim poziomie, które wykraczają poza sprint, zwykle będziesz musiał podejmować je na poziomie powyżej zespołu. Ci profesjonaliści tradycyjnie już pełnią rolę „architekta” w przedsiębiorstwie.

Myślę, że większość innych odpowiedzi myśli o tym z perspektywy bycia w projekcie.

Jeśli jest to jedyny poziom architektury w organizacji, rezultatem będzie szczerze chaos. Byłem świadkiem tego chaosu z pierwszej ręki, niestety się zdarza.

Według TOGAF, Departament Architektury Korporacyjnej opracowuje plany na wysokim poziomie dla i wraz z biznesem w celu stworzenia i zastąpienia środowiska IT. Architekt Enterprise zdefiniuje zasady architektury i sprawi, że zostaną podpisane na najwyższych szczeblach organizacji, i pomoże stworzyć architekturę wysokiego poziomu i wymagania dla każdego projektu. Każdy projekt jest inicjowany w celu zapewnienia architektonicznego elementu składowego w tej architekturze wysokiego poziomu.

Tak więc na poziomie projektu architekt rozwiązań utworzy architekturę projektu (ewentualnie iteracyjnie) i otrzyma podpis od Enterprise Architect.

Teraz skoncentruj się na zwinnym projekcie. Zwinny projekt ma wymagania. Nie są one w formie ogromnego „dokumentu wymagań”, ale są epickie i opowiadania. Te Epiki nadal wymagają planowania. Nie wysyłasz zespołu programistów na kilka sprintu w nieznane. Na wysokim poziomie wiesz, co powinien zrobić system, z jakimi innymi systemami musi współpracować oraz z jakim sprzętem / systemem operacyjnym / językowymi ograniczeniami ma organizacja, a to prowadzi i ogranicza możliwości architektoniczne dostępne dla Solution Architect. Na przykład, jeśli jesteś zaangażowany w .NET i SQL server, musisz zrobić bardzoprzekonująca sprawa do wdrożenia witryny e-commerce opartej na Magento z wykorzystaniem PHP i MySQL ze względu na koszty związane z obsługą dwóch baz danych, dwóch języków, dwóch serwerów WWW itp. Alternatywnie, jeden projekt może wybrać użycie zupełnie innej biblioteki lub innego wyglądu i czuć to, co może mieć wpływ na wszystkie inne projekty w locie. Konieczne jest sprawowanie nadzoru nad architektem korporacyjnym, aby zapobiec powstaniu tego rodzaju „długu architektonicznego”.

Zależy od projektu organizacyjnego organizacji i tego, czy produkt jest w portfelu. Większe organizacje zorientowane na role mogą wyznaczyć starszych architektów do prowadzenia tego rodzaju działań.

Zasadniczo starszy architekt będzie ułatwiać i kierować decyzjami projektowymi, ponieważ nie tylko wpływają one na zaległości produktowe, ale mogą wpływać na kilka produktów w portfolio produktów.

Mniejsze, sprawne firmy mogą polegać na programistach będących ekspertami systemowymi, którzy poprowadzą zespół programistów do dostosowania się do projektu architektonicznego.

Ostatecznie decyzje architektoniczne muszą zostać uzgodnione przez zespół dostarczający, który pracuje nad produktem. Doświadczeni architekci i kierownicy techniczni bardziej skupią się na ułatwieniu dyskusji na temat tego, jak powinien wyglądać projekt, niż na dyktowaniu projektu.

Myślę, że większość odpowiedzi już podkreśla, że zespół ani jedna osoba nie powinna podejmować tych decyzji.

To, czego nie dotykają, to kolejna zasada Agile:

Prostota - sztuka maksymalizacji ilości niewykonanej pracy - jest niezbędna.

Myślenie o architekturach wysokiego szczebla i decyzjach projektowych często nie jest podejmowane z myślą o prostocie, co może prowadzić do marnowania dużo wysiłku i dodawania niepotrzebnej złożoności, która może utrudnić rozszerzenie.

Pomyśl „ogrodnictwo” nad „architekturą” - stwórz kulturę życia, rozwijającego się designu

Podczas bieżącej iteracji powinieneś podejmować decyzje dotyczące architektury i projektowania zgodnie z bieżącymi potrzebami. Zamiast patrzeć w przyszłość, która może nigdy nie być, skoncentruj się na tym, czego potrzebujesz teraz. Prawdopodobnie YAGNI jest teraz dobrze przemyślaną architekturą, niech zespół poradzi sobie z tym po .

Inne teksty:

• https://less.works/less/technical-excellence/architecture-design.html