21 lip 2009

EA - zespół który koduje system musi go projektować

Poprzednim razem pisałem ogólnie o architekturze w projektach zwinnych. Generalna zasada jest taka, że nad architekturą staramy się zastanawiać nie (wyłącznie) na początku, ale w każdej iteracji. Ale żeby móc coś takiego osiągnąć zespół który koduje system musi go projektować. By decyzje architektoniczne były świadome a nie tylko pobożnymi życzeniami muszą być podejmowane na podstawie danych - faktów. A te ujawniają się w dużej mierze w czasie developmentu. Również informację o kosztach (w sensie czasowym) decyzji i zmian architektonicznych zna tylko zespół. Tak więc to zespół jest najbliżej wszystkich danych niezbędnych do podejmowania decyzji.

Podejmowanie decyzji architektonicznych przez zespół ma poza tym wpływ na jego zaangażowanie w projekt i wzmaga odpowiedzialność za projekt. Przekazywanie władzy "w dół" (team empowerment) to dobry sposób budowania zespołu. Kto nie chciałby pracować przy projekcie ze zmotywowanymi i zaangażowanymi współpracownikami? Jak poza tym pomagać mniej doświadczonym członkom zespołu zwiększać swoją wiedzę jak nie przez angażowanie ich w takie dyskusje?

Architektura projektu w przypadku większych rozwiązań czy firm o zdefiniowanej polityce w tym zakresie może wymagać uczestnictwa architekta. To on dba o zachowanie zgodności z polityką architektoniczną firmy, ale również może służyć zespołowi swoim doświadczeniem - ale do tego celu musi on być obecny w zespole przez cały czas developmentu. Czasem wymaga to zmiany funkcjonowania organizacji - gdy w firmie jest dział architektury, który zajmuje się tworzeniem dokumentacji architektonicznej przed rozpoczęciem developmentu, może być ciężko zaangażować architekta w działania zespołu - najpewniej ma on już kolejne systemy do projektowania.

Oczywiście w przypadku dużych projektów nie ma możliwości by cały zespół projektowy (np. parędziesiąt osób) podejmowało wszystkie decyzje. Wtedy możliwe są rozwiązania takie jak zespół architektoniczny złożony z programistów z poszczególnych podzespołów. Pozwala to na zachowanie spójnej architektury całego systemu przy zachowaniu decyzji co do jego kształtu na właściwym poziomie (dalej robią to programiści aktywnie zaangażowani w development). Rotowanie osób w tym zespole pomaga dodatkowo rozprzestrzeniać wiedzę o produkowanym systemie oraz zwiększać ogólną wiedzę i doświadczenie w zespole.

W niektórych projektach widziałem spotkania w rodzaju "architecture review" podczas których architekt który zaprojektował system siedział z zespołem i przeglądał system pod kątem realizacji jego założeń. Takie spotkania oczywiście zwiększają szansę na to, że system będzie zgodny z założoną architekturą, ale nie koniecznie wpływają na to, że będzie ona zgodna z wymaganiami co do systemu. Poza tym takie przeglądy są zwykle dość powierzchowne. To coś a'la code review - dobrze je robić jeśli się nie korzysta z programowania w parach i TDD. Jeśli jednak uda nam się wprowadzić te techniki, code review jest w większości przypadków zbędne. Co więcej przeglądy architektury (podobnie jak przeglądy kodu) mają formę hierarchiczną: o to architekt sprawdza czy programistyczna masa nie zniszczyła jego dzieła - architektury (no, może trochę przerysowałem...) Praca architektów w zespole ręka w rękę z mniej doświadczonymi programistami dużo lepiej wpływa na pozyskiwanie wiedzy tych drugich i całościową pracę zespołu umożliwiając dużo efektywniejszą jego pracę.
Ciągłe dbanie o utrzymywanie, weryfikowanie i modyfikowanie architektury umożliwia jej lepszą jakość i odpowiedniość wymaganiom, do tego zmiejszając szanse na to, że będzie niezbędna jej gruntowna (kosztowna) zmiana.

Brak komentarzy: