Umiejętnie dobrana struktura, w ramach której pracują zespoły developerskie to ważny aspekt każdego przedsięwzięcia, w którym wytwarzane jest oprogramowanie. Które z podejść wybrać? Czy wybierać w ogóle?
W czasach panowania metodyk zwinnych odpowiedź nasuwa się samoistnie – feature-oriented góruje w całej rozciągłości nad – zdawać by się mogło już archaicznym – podejściem architecture-oriented. Warto zacząć od krótkiego zdefiniowania zakresów odpowiedzialności zespołów programistycznych, które pracują w ramach wyżej wymienionych struktur organizacyjnych.
SZYBKO?
Feature-oriented – zespoły programistów i testerów zorganizowane wokół aplikacji, grupy use case’ów, pojedynczego user story, czy choćby najmniejszej, namacalnej funkcjonalności są w stanie sprawnie dostarczyć działające oprogramowanie w rozsądnych ramach czasowych. Zespół A stworzy panel logowania, zespół B zajmie się oknem zakupowym, a zespół C w tym czasie napisze formularz reklamacyjny. Niestraszna im będzie analiza zależności, gdyż dzięki Continuous Integration wszyscy będą w stanie na bieżąco monitorować zmiany i ewentualne defekty. Odkąd każdy zespół jest odpowiedzialny za cały przekrój aplikacji, a co za tym idzie – za wszystkie jego warstwy, problem wydłużającego się procesu decyzyjnego praktycznie nie istnieje. Zrobią to jeden raz, dla jednego klienta, z jednym zestawem niezmiennych (oczywiście po wdrożeniu) wymagań. Sielanka, nieprawdaż?
DOBRZE?
Architecture-oriented – podejście najbardziej tradycyjne, do tego dobrze sprawdzające się w produktach wydawanych cyklicznie, skomplikowanych pod względem integracji, a przede wszystkim dedykowane aplikacjom, w których kładziony jest wysoki nacisk na jakość wytwarzanego oprogramowania. Zespół A odpowiada za warstwę UI, zespół B ma wszystkie serwisy w małym palcu, a władzę nad bazą danych sprawuje zespół C. Wszystko ma swoje miejsce – architektura i jakość kodu trzymana jest w ryzach przez samych programistów i czujnych testerów. Każdy zespół jest wysoko wyspecjalizowaną grupą w ramach konkretnej warstwy kodu. Co więcej, interfejsy są nienaganne, przejrzyste i spójne, co wspiera rozwój raz napisanej funkcjonalności. Czysto i porządnie.
CO MOŻE PÓJŚĆ NIE TAK?
Krótko rzecz ujmując – całkiem sporo rzeczy. Może się okazać, że klient postanowi zmienić wymagania po końcowym gwizdku, a my, przyznawszy mu rację, z zakasanymi rękawami zajmiemy się odgruzowywaniem naszego pobojowiska, bo przecież „miało być szybko!”. Równie dobrze może wstąpić w nas kapral, który nie pozwoli nam tworzyć, póki nie skończymy osiemnastej sesji planowania rozmieszczenia tekstu w rubryce „Kontakt”, a na każde code review będziemy szli jak na szafot.
A GDYBY TAK SZYBKO I DOBRZE?
Na całe szczęście świat nie jest czarno-biały. Implementacja podejść zorientowanych na funkcjonalności i architekturę zazwyczaj idzie ze sobą w parze, toteż trzeba zachować zdrowy rozsądek w organizowaniu zespołów programistycznych. Idąc za przykładem wielu doświadczonych programistów, architektów i menadżerów, warto zastosować podejście mieszane. Jak miałoby ono wyglądać?
Weźmy kliku doświadczonych programistów – w ich ręce powierzmy odpowiedzialność za design i dokumentację wysokopoziomowego poglądu na rozwój kodu od strony jakościowej. Tak otrzymane wytyczne stanowić będą podwaliny implementacji. Jakąkolwiek niejasność wyjaśnijmy na forum, a na pytania odpowiadajmy jasno i spójnie, posługując się przykładami użycia.
Tak sformułowana część jakościowa będzie mogła przerodzić się w fizyczny kod. Od teraz zaczyna się praktyczne użycie podejścia funkcjonalnego, oparte na przykład o metodykę XP czy Scrum. Szereg unit testów i wykorzystanie Continuous Integration pomoże zachować ciągłość integracji, jednak nie zawsze znajdzie to zastosowanie dla wszystkich zagadnień architekturalnych. Dla nich powoływane są nieformalne przeglądy kodu, który znalazł się na master-branch oraz organizowane są automatyczne pomiary jakości, by we wszystkich warstwach trzymać rękę na pulsie. Stosowane jest podejście mentorskie wprowadzające nowych programistów przez już doświadczonych starych wyjadaczy.
Nie jest to przepis na sukces. Każdy projekt wymaga indywidualnego podejścia do organizacji pracy. Niemniej jednak powyższy tekst może stanowić wspólny mianownik dla całego przekroju branży programistycznej.