Blog naukowy. Zdobądź wiedzę z języków obcych, jazdy na łyżwach...

Zespół chirurgiczny

Bardzo dobrzy zawodowi programiści są dziesięciokrotnie wydajniejsi niż słabi, mając to samo wyszkolenie co tamci i podobne, dwuletnie doświadczenie (Sackman, Grant i Erickson). Dane Sackmana, Granta i Ericksona wskazują, że nie ma żadnej korelacji między doświadczeniem a wydajnością. Mam wątpliwości, co do powszechności tego spostrzeżenia.

Najlepszy jest mały, bystry zespół – liczący jak najmniej osób. Często najlepszym rozwiązaniem jest stworzenie zespołu dwuosobowego z jednym przywódcą. [Zwróćmy uwagę na projekt małżeństwa przygotowany przez Boga].

Mały, bystry zespół jest zbyt powolny do budowania naprawdę dużych systemów. Doświadczenia z pracy nad naprawdę dużymi systemami wskazują, że zwiększanie skali zadań „na siłę”, przez przydzielanie do nich coraz większej liczby ludzi, jest kosztowne, zajmuje dużo czasu, jest nieefektywne i prowadzi do powstania systemów, którym brakuje koncepcyjnej jednorodności.

Zorganizowanie zespołu tworzącego oprogramowanie na wzór zespołu chirurgicznego z naczelnym programistą zapewnia koncepcyjną jednorodność pracy oraz łączną większą wydajność wielu pomocników, przy jednoczesnym wyraźnym zmniejszeniu liczby czynności komunikacyjnych.

„Zachowanie koncepcyjnej jednorodności jest w projektowaniu systemu wymogiem najważniejszym”. „Ostatecznym sprawdzianem projektu systemu jest stosunek funkcji do złożoności koncepcyjnej”, a nie bogactwo funkcji. [Stosunek ten jest miarą łatwości użytkowania – ważną zarówno w wypadku prostych, jak i trudnych produktów].

Koncepcyjna jednorodność wymaga, żeby projekt był dziełem jednego umysłu albo malej grupy zgodnych umysłów. „Rozdzielenie prac nad architekturą systemu i jego implementacją to skuteczna droga do zapewnienia koncepcyjnej jednorodności bardzo dużych zamierzeń programistycznych”. [Małych także].

„Jeśli system ma się cechować koncepcyjną jednorodnością, to ktoś musi panować nad koncepcjami. Za istnienie takiej arystokracji nie trzeba przepraszać”. Dyscyplina sprzyja sztuce. Dostarczenie architektury z zewnątrz wzbogaca, a nie ogranicza, twórczą pracę grupy wdrożeniowej.

System jednorodny koncepcyjnie powstaje szybciej i wymaga krótszego okresu testowania. Znaczna część prac nad architekturą, implementacją i realizaqą może przebiegać równolegle. [Podobnie jest z pracami nad sprzętem i nad oprogramowaniem].

Wcześnie nawiązana i ciągła komunikacja między architektem i wykonawcą zapewnia temu pierwszemu możliwość trafnego oszacowania kosztów, a temu drugiemu zaufanie do projektu – bez zamazywania wyraźnego podziału odpowiedzialności między nimi.

W jaki sposób architekt może skutecznie wpływać na implementację projektu? Musi pamiętać, że to budowniczy ponosi twórczą odpowiedzialność za implementację, a on sam jedynie proponuje rozwiązania.

Musi zawsze mieć w zanadrzu metodę na implementację tego, co wyspecyfikował: musi być przygotowany na przyjęcie każdego innego równie dobrego rozwiązania. Przy przedstawianiu swoich propozycji powinien postępować spokojnie i dyskretnie.

Powinien być przygotowany na to, że uznanie za proponowane rozwiązania może przypaść komuś innemu. Powinien wysłuchać propozycji budowniczego dotyczących udoskonalenia architektury. Drugi system jest najniebezpieczniejszy ze wszystkich, jakie człowiek projektuje: daje o sobie znać tendencja do wprowadzania w nim upiększeń. System OS/360 to znakomity przykład syndromu drugiego systemu w życiu. [Wydaje się, że w latach dziewięćdziesiątych takim przykładem jest Windows NT]. Dobrym obyczajem jest przypisanie z góry każdej funkq’i wartości w bajtach i mikrosekundach.

Nawet wtedy, kiedy zespół projektowy jest duży, wyniki prac powinny być opisywane przez jedną lub dwie osoby: chodzi o to, żeby minidecyzje były spójne. Ważne jest wyraźne staranne zdefiniowanie zarówno nie nakazanych części architektury, jak i tych nakazanych.

Potrzebna jest zarówno formalna definicja projektu, która jest precyzyjna, jak i definicja w języku naturalnym, która jest zrozumiała. Jedna z definicji, formalna albo w języku naturalnym, musi być standardem, a druga pochodną. Każda może pełnić jedną funkcję albo drugą.

Implementacja, włącznie z symulacją, może służyć jako definicja architektoniczna: takie podejście ma jednak poważne wady. Bezpośrednie włączenie to czysta technika narzucenia standardu architektonicznego w oprogramowaniu. [Dotyczy to też sprzętu – pomyślmy o interfejsie Mac WIMP wbudowanym w ROM],

Architektoniczna „definicja będzie precyzyjniejsza, a dyscyplina ściślejsza, jeżeli na początku zbuduje się co najmniej dwie implementacje”. Architekt powinien mieć możliwość udzielania przez telefon odpowiedzi na wszystkie pytania wdrożeniowców: bardzo waż- ne jest zapisywanie ich i publikowanie. [Obecnie najlepszym środkiem przekazywania informacji jest poczta elektroniczna], „Najlepszym przyjacielem architekta jest jego przeciwnik na co dzień, czyli niezależny zespół testowania produktu”.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.