„DDD jest prawicą!”

Za tym prowokacyjnym stwierdzeniem (idealnym do zorganizowania sesji unconf i posiadania ludzi) Simon Chaveneau chciał zadać sobie pytanie o wpływ Domain Driven Design (DDD) na naszą organizację (Product-Tech) do produkcji oprogramowania. Stało się to podczas naszej pierwszej niekonferencji w Agicap, zorganizowanej po to, aby ludzie Produktu i Tech mogli się spotkać, aby dyskutować, uczyć się, dzielić, śmiać się, ale przede wszystkim nabrać dystansu do naszego codziennego życia.

Podczas unkonferencji program ustala publiczność. Odbywa się to podczas wstępnej sesji „Market Place” rano. Podczas tej pierwszej sesji plenarnej każdego dnia każdy może chwycić lepki, marker, a następnie przedstawić swoje sesje przed wszystkimi. Następnie ludzie umieszczają je w programie dnia (więcej informacji na temat tej niekonferencji można znaleźć w tym wątku na Twitterze )

Wróćmy jednak do tematu i intrygującej sesji zaproponowanej przez Simona.

Panowanie własności prywatnej?

Podsumowując wstęp Simona: jeśli całe sekcje naszego SI należą do zespołów — z których każdy odpowiada za jeden lub więcej Bounded Context (BC) — czy nie mamy do czynienia z wersją oprogramowania własności prywatnej (z drutem kolczastym wokół BC itp.) .)? Stąd jego prowokacyjne „ DDD jest prawicowe!

I z pytaniem dodatkowym: „Czy nie bylibyśmy bardziej wydajni, mając organizację opartą na zespołach fabularnych? (z każdym zdolnym do pracy na wszystkich BC w drodze do ich przypadków użycia)”

Cóż… Muszę przyznać, że ta sesja okazała się znacznie bardziej owocna niż początkowo zakładałem, ponieważ wywiązała się naprawdę fascynująca dyskusja na temat naszego trybu organizacji Produkt/Technologia.

Ale zamiast szczegółowo opisywać ścieżkę, jaką przebyła ta sesja, na której było nas bardzo dużo (z pewnością interesujące do opisania w kontekście innego postu), opiszę bezpośrednio to, co zachowałem i myślę na ten temat.

Kilka obserwacji

• Efektywne oprogramowanie to oprogramowanie dostosowane do wyzwań biznesowych . Przez dopasowanie rozumiemy oprogramowanie, które zapożycza właściwe terminy z dziedziny domeny, które poprawnie wyraża kluczowe koncepcje biznesowe i przywołuje w jak najmniejszym stopniu przypadkową złożoność wynikającą z problemów technicznych. Jest to jedno z głównych wyzwań związanych z projektowaniem opartym na domenach (DDD), które wyjaśniono tutaj w 3 minuty .
• Prawo Conwaya nie jest opcją, z której można zrezygnować.‍♂️ Działa trochę jak pewne prawa fizyczne, takie jak przyciąganie grawitacyjne. Można próbować z tym walczyć ;-) ale na ziemi nadal obowiązuje. Prawo Conwaya to prawo z 1967 r., które stwierdza, że
  ​​„Każda organizacja, która projektuje system (zdefiniowany szeroko), stworzy projekt, którego struktura jest kopią struktury komunikacyjnej organizacji”.
  Innymi słowy, architektura oprogramowania jest z konieczności wynikiem sposobów komunikacji osób zaangażowanych w jego projektowanie. Na przykład kompilator opracowany przez 3 zespoły najprawdopodobniej będzie działał w 3 przejściach lub będzie miał 3 odrębne moduły.
• Odwrotny manewr Conwaya (ICM) pozwala myśleć, że można kontrolować prawo Conwaya. Początkowo ten odwrotny manewr mądrze zalecał „ rozbijanie silosów, które ograniczają zdolność zespołu do efektywnej współpracy”. Ale przez lata została przekształcona w głupią rekomendację: „ zmień swoją organizację, aby osiągnąć docelową architekturę ”. Głupie, bo pamiętaj: „Kultura zjada strategię od śniadania”. Więcej informacji tutaj w tym ciekawym wątku.
• Domain Driven Design nie narzuca żadnej organizacji. Daje klucze umożliwiające przetrwanie, także w przypadku organizacji dysfunkcyjnych (z zespołami, które toczą wojnę lub ignorują się nawzajem). DDD pomaga nam zrozumieć kwestie władzy i problemy społeczne między zespołami. W rezultacie jest raczej narzędziem wyzwolenia przeciwko naszym determinizmom ( stąd powiedziałbym, że lewicowym narzędziem ;-) )
• Z drugiej strony DDD daje nam narzędzia, dzięki którym możemy zaprojektować wydajne oprogramowanie, które jest jak najbardziej dopasowane do domeny. Wśród nich koncepcja Bounded Context (BC), która proponuje nam projektowanie modeli do zastosowań, otaczanie ich i zabezpieczanie przed nieporozumieniami/fałszywymi przyjaciółmi/nieporozumieniami wynikającymi z innych kontekstów.
• W celu lepszego dostosowania i wydajności DDD zdecydowanie zaleca również regularne kwestionowanie naszej wizji i modelowania rozwiązania. Oznacza to również rewolucjonizację i zmianę modeli od czasu do czasu po eurece (nazywanej Przełomem Projektowym ). Dlatego regularnie organizujemy tutaj sesje z mapą kontekstu, podczas których stale udoskonalamy naszą wizję pola z pracownikami Produktu.
• Zespoły deweloperskie mają kruche wyważenie. Potrzeba około 6 miesięcy wspólnego życia i relacji międzyludzkich, aby zespół programistów był naprawdę skuteczny. Dodajesz lub usuwasz jedną osobę z tego zespołu i nie jest to już ten sam zespół (zobacz Dynamiczne ponowne tworzenie zespołu ). Jeśli chodzi o efektywność, wolę zespoły, które trzymają się razem i zmieniają tematy, niż zespoły, które są po prostu eksplodowane / redystrybuowane według tematów. Oczywiście, jeśli ktoś ma dość swojego zespołu lub swoich poddanych, należy zrobić wszystko, aby umożliwić mu zmianę zespołu (dobre samopoczucie osobiste jest jeszcze ważniejsze dla naszej zbiorowej efektywności)
• Nasza obecna organizacja i nasze zespoły tutaj w Agicap są raczej powiązane z jednym lub kilkoma ograniczonymi kontekstami, aby uwzględnić złożoność problemu i maksymalnie wykorzystać naszą specjalistyczną wiedzę biznesową. Od czasu do czasu niektóre zespoły mogą mieć zbyt duży zakres i musimy lepiej wyciąć i przypisać nasz ograniczony kontekst. Z drugiej strony ten podział BC musi pozostać powiązany z koncepcjami biznesowymi (pamiętaj DDD)
• Nic nie stoi na przeszkodzie, aby mieć zespoły fabularne w organizacji, która wykonuje DDD , o ile wszyscy szanują granice ograniczonych kontekstów.
• Na razie zdecydowanie preferujemy praktykę Swarming (rodzaj grupy zadaniowej utworzonej z ludzi z kilku zespołów, ale gdzie odpowiedzialność i własność ostatecznego artefaktu (narzędzia, api, biblioteki) jest zdefiniowana od samego początku. Pomaga aby uniknąć syndromu „Dobrze, mamy coś razem, ale kto to teraz utrzyma?!?”). Poza skutecznością pozyskiwania odpowiednich ludzi do współpracy w zależności od tematu, rój wnosi do naszej organizacji duży kapitał społeczny , tymczasowo promując relacje interpersonalne między zespołami (bardzo przydatne w przyszłości, gdy wszyscy wrócą do swojego zespołu).
• Nasza obecna organizacja produktu jest ustawiona na 1 menedżera produktu (PM) na zespół programistów, ale może byłoby interesujące, gdyby PM byli bardziej związani z tematami biznesowymi niż z własnym zespołem?

Na koniec powiedziałbym, że w organizacji nie ma więcej srebrnej kuli niż w dev. Ciągła informacja zwrotna, zadawanie pytań i eksperymentowanie są naszymi towarzyszami na ścieżce ciągłego doskonalenia, aby skutecznie tworzyć oprogramowanie odpowiednie dla naszych użytkowników.

Uwaga: ten post jest tłumaczeniem francuskiego artykułu napisanego w zeszłym tygodniu (14 października 2022 r.)

Więcej informacji o Agicap:

• Pokaż mi swoją domenę ( sesja mapy kontekstowej monitorowania i prognozowania przepływów pieniężnych )
• https://agicap.com/
• https://career.agicap.com/