Blog naukowy z Warszawy. Zdobądź wiedzę z języka francuskiego, nauki gry na perkusji...

SACKMAN, ERIKSON I GRANT CZ. II

Z jednej strony nie zbliża się ono do ideału małego, bystrego zespołu, który według powszechnej, zgodnej opinii nie powinien liczyć więcej niż 10 osób. Nasz zespół jest tak duży, że potrzeba w nim co najmniej dwóch szczebli kierowania, czyli około 5 kierowników. Ponadto potrzebne jest wsparcie finansowe, kadrowe, powierzchnia biurowa, sekretarki i operatorzy maszyn.

Z drugiej strony pierwotny 200-osobowy zespół jest zbyt mały, żeby budować na siłę naprawdę duże systemy. Weźmy na przykład OS/360. W szczytowym momencie pracowało nad nim ponad 1000 osób: programiści, autorzy, operatorzy maszyn, pracownicy biurowi, sekretarki, kierownicy, grupy wsparcia. W latach 1963-1966 zużyto prawdopodobnie jakieś 5000 osobolat na zaprojektowanie, budowę i dokumentację systemu. Gdyby można było zamiennie traktować ludzi i miesiące nasz 200-osobowy zespół musiałby pracować 25 lat, żeby doprowadzić produkt do obecnej postaci!

Na tym właśnie polega problem związany z koncepcją opartą na małym, bystrym zespole: zespół taki jest zbył powolny do tworzenia naprawdę dużych systemów. Zastanówmy się, jak mógłby się on zabrać do pracy nad OS/360. Weźmy zespół 10-osobowy. Przyjmijmy, że ponieważ jego członkowie są bystrzy, są siedmiokrotnie wydajniejsi niż przeciętni programiści – i to zarówno w programowaniu, jak i w opracowywaniu dokumentacji. Załóżmy, że OS/360 był budowany jedynie przez przeciętnych programistów (co znacznie odbiega od prawdy). Przyjmijmy dalej, że współczynnik poprawy wydajności, wynikający ze zmniejszenia liczby działań komunikacyjnych, w małym zespole wynosi 7. Załóżmy też, że całą pracę wykonuje ten sam zespół. Mamy zatem 5000/(10 x 7 x 7) = 10. Wynika stąd, że członkowie tego zespołu mogą wykonać pracę wymagającą 5000 osobolat w ciągu 10 lat. Czy po 10 latach od wstępnego zaprojektowania produkt nadal będzie interesujący? A może okaże się przestarzały w wyniku gwałtownego rozwoju techniki programowania?

Jest to okrutny dylemat. Biorąc pod uwagę efektywność i koncepcyjną jednorodność systemu woli się mieć kilka zaledwie sprawnych umysłów projektujących i budujących system. W wypadku jednak dużych przedsięwzięć programistycznych szuka się sposobów wykorzystania znacznej liczby ludzi w nadziei, że produkt pojawi się w wyznaczonym terminie. Jak zatem pogodzić te dwie sprawy?

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.