Badanie 7-R. Weryfikacja warstwy adaptacji modelu (dobór dobrych praktyk)

przy znanym poziomie dojrzałości zespołu dostawcy, dojrzałości klienta oraz entropii projektowej. Na środowisko przeprowadzenia badania wybrano projekt dotyczący integracji narzędzi Rational wspomagających cykl wytwarzania oprogramowania. Klientem projektu była firma IBM. Dostawcą w tym projekcie było Uniwersyteckie Centrum Kompetencyjnego Technologii Rational powołane na Politechnice Gdańskiej, a wykonawcami członkowie koła naukowego podległego temu Centrum.

Klient (firma IBM) zlecił sprawdzenie możliwości integracji technologii Rational. W tabeli 5.14 przedstawiono założenia do przeprowadzania badania.

Tabela 5.14 Założenia do badania 7-R

Kod badania 7-R

Cel

Celem eksperymentu jest sprawdzenie możliwości realizacji projektu informatycznego, dla którego pomierzony jest poziom dojrzałości dostawcy oraz klienta, a także znany jest poziom entropii z uwzględnieniem dobrych praktyk zarządzania. Eksperyment powinien wykazać, na ile zmienne decyzyjne pozwalają na dobieranie dobrych praktyk zarządzania projektami w zależności od wartości tych zmiennych oraz czy dobranie dobrych praktyk pochodzących z różnych metod zarządzania projektami jest możliwe (czy możliwa jest adaptacja dobrych praktyk).

Środowisko badania

Środowiskiem eksperymentu był projekt informatyczny polegający na integracji narzędzi w cyklu wytwarzania oprogramowania. Zadaniem osób uczestniczących było sprawdzenie możliwości integracji narzędzi jednego z większych producentów oprogramowania oraz stworzenie modelu integracji na poziomie danych lub na poziomie plików (model API).

Poziomy modelu

Początek realizacji: Kwiecień 2011 wykonano Termin

zakończenia:

Wrzesień 2011 Zakończono pierwszy etap-analiza możliwości integracyjnych

Źródło: opracowanie własne

Opis przebiegu eksperymentu

Przeprowadzone badania integracji narzędzi wspomagających procesy organizacji (w tym przypadku proces wytwarzania oprogramowania) miały wykazać przydatność modelu szczegółowego a2M dla warunków dużego projektu o znanych wartościach zmiennych decyzyjnych (entropii projektu, dojrzałości klienta oraz dojrzałości zespołu dostawcy) przy jednoczesnym dopasowaniu dobrych praktyk zarządzania projektami. Taka potrzeba wynikała z wniosków poprzedniego eksperymentu, 7-R, gdzie zauważono konieczność dobierania dobrych praktyk w zależności od tych zmiennych. Okazało się także, że projekt integracji narzędzi, który stanowił środowisko dla eksperymentu, pozwala na uwzględnienie także wszystkich wcześniejszych założeń dla modelu szczegółowego a2M (dotyczących poziomu definiowania oraz zarządzania). Dlatego też podczas opisu tego badania zwrócono uwagę na szczegóły dotyczące także niższych poziomów modelu.

Po dokonaniu wstępnych ustaleń z przedstawicielem klienta określono zakres projektu.

Wiadomym było, że należy opracować model pozwalający integrować narzędzia w cyklu wytwarzania oprogramowania. Niestety, od początku trwania projektu nie było wiadomo, na jakim poziomie tej integracji należy dokonać. Czy tylko w oparciu o przesyłanie plików między narzędziami za pomocą funkcji API, czy też w niższej warstwie (na poziomie danych w formacie XML). Z uwagi na fakt, że rodzina narzędzi Rational, które miały zostać poddane analizie, była stosunkowo duża, uznano także, że prace będą realizować pracownicy Zakładu Zarządzania Technologiami Informatycznymi oraz studenci kierunków informatycznych i menedżerskich Politechniki Gdańskiej w ramach kilkuosobowych grup (zespołów). Dla każdego z tych zespołów określono poziom dojrzałości oraz wyłoniono lidera. Był to pierwszy krok do zastosowania podejścia agentowego (definiowanie agentów, ich cech oraz zachowań). Liderom przypisano takie zachowania jak komunikacja

z członkami zespołu czy raportowanie wyników do kierownictwa projektu. W celu odzwierciedlenia agentowej struktury zarządzania, którą założono w modelu szczegółowym a2M, powołano również taką strukturę w ramach tego projektu. Kierownikiem projektu (agent menedżer) był Profesor kierujący Centrum Kompetencyjnym. Funkcje agenta koordynatora oraz agenta wnioskującego powierzono dwom asystentom Profesora. Zadaniem agenta koordynatora było nadzorowanie prac poszczególnych zespołów poprzez komunikację z liderami. Rolą agenta wnioskującego w tym projekcie było dobieranie dobrych praktyk zarządzania projektem w zależności od zmiennych decyzyjnych nowego trójkąta ograniczeń.

Podczas badania realizowanego w ramach projektu integracji narzędzi Rational zastosowano kompleksowo model szczegółowy a2M. Zastosowanie podejścia agentowego było konieczne również ze względu na rozproszone środowisko realizacji projektu (klient przebywał w innym mieście, kontaktowano się z nim za pośrednictwem wideokonferencji, zespoły złożone z uczestników pracujących w różnych rejonach Gdańska). Kolejnym typowym zjawiskiem dla podejścia agentowego było wyłonienie mentora, który służył pomocą w określonych momentach projektu. Miał być zatem

„uruchamiany” w zależności od sytuacji, na zasadzie typowego agenta (stan i akcja jako odpowiedniki cech i zachowań uczestnika projektu). Zadaniem mentora było reagowanie na zlecenia koordynatora (np. dostarczenie przewodników po narzędziach informatycznych analizowanych przez zespoły, zarządzanie licencjami oprogramowania itp.).

Tak zdefiniowana struktura projektu, a tym samym środowisko przeprowadzenia eksperymentu, pozwoliła na realizację kolejnego etapu projektu: pomiaru dojrzałości poszczególnych zmiennych decyzyjnych. Klient, z uwagi na duże doświadczenie, okazał się być klientem zarówno dopasowanym, jak i odpowiednim. Potrafił bowiem sprecyzować wszystkie swoje oczekiwania, a nawet zawrzeć sugestie co do tego, jak wykonać określone zadania związane z integracją narzędzi będących przedmiotem analiz w omawianym projekcie. Zespoły, z racji tego, że złożone były głównie ze studentów (zarówno kierunków menedżerskich, jak i informatycznych), wykazywały się dużą wiedzą merytoryczną i dość dobrymi cechami członków związanymi z pozycjami w zespole (ponad połowa osób miała wyraźnie określone pozycje zespołowe na podstawie testu Belblina, takie jak lider czy skrupulatny wykonawca). Jednak brakowało członkom zespołu doświadczenia związanego z realizacją projektów. Udało się jednak ocenić poziom dojrzałości zespołów, który przedstawiał się na poziomie małym bądź średnim (w przypadku jednego zespołu). Wreszcie dokonano również analizy entropii projektu, która w omawianym case’ie badawczym została uznana za wysoką. Wynikało to z tego, że o ile poszczególne zadania związane z analizą technologii informatycznych były jasne, o tyle dokładna wizja projektu i forma ostatecznego produktu była do końca niejasna. Próbowano oprzeć finalny produkt na zasadach szyny ESB (ang. Enterprise Service Bus) albo na modelu XML, ale od początku kierownik projektu wraz z klientem nie byli przekonani, który z wariantów jest słuszny. W związku z taką entropią postanowiono zastosować dobrą praktykę zarządzania projektem, która pozwoli na uruchomienie prac projektowych przy wysokim poziomie entropii. Zdecydowano się więc zastosować pracę w sprintach (zaczerpniętą z metody SCRUM). Pierwszy sprint dotyczył analizy technologii i możliwości ich wzajemnego powiązania (które technologie warto integrować z innymi).

Zaproponowano, aby podejście do modelowania integracji technologii opracować w kolejnych sprintach. W ten sposób dobrano dobrą praktykę zarządzania projektem do nowego trójkąta ograniczeń. Przy czym okazało się konieczne uwzględnienie także poziomów dojrzałości zespołów.

Gdyby realizować projekt zgodnie z metodą SCRUM, zespoły powinny same zaplanować realizację zadań. Jednakże po uwzględnieniu poziomów dojrzałości zespołów (trzy zespoły o małym poziomie dojrzałości — zarządzany i jeden o średnim — ilościowo zarządzany według skali przyjętej dla pomiaru dojrzałości zespołu) uznano, że zespoły nie są w stanie samoorganizować się ze względu na brak wystarczającego doświadczenia w zarządzaniu projektami. O ile bowiem poziom kompetencji zespołowych pośród uczestników był duży, o tyle poziom doświadczeń projektowych mały. Stąd też uznano za konieczne dopasowanie odpowiednich dobrych praktyk zarządzania projektami

w zależności od poziomów dojrzałości zespołu. W tym celu pozyskano dobre praktyki zarządzania projektami według PMBoK, zalecając zespołom ocenę zadań z perspektywy wejścia, przetwarzania i wyjścia. Postawiono poddać modyfikacji tę dobrą praktykę o zalecenia metody RUP dotyczące definiowania zadań razem z oczekiwanymi produktami pracy. Takie podejście pozwoliło zespołom na realizację zadań w oparciu o przygotowany wcześniej plan działania. Zespoły definiowały razem z agentem koordynatorem zadania, określały, jakich produktów oczekuje się po ich zakończeniu, i dzięki temu zadania powierzone zespołom zostały wykonywane terminowo. Po kilku tygodniach okazało się, że zachodzi konieczność gromadzenia wyników badań na potrzeby późniejszych publikacji tych wyników. Stąd też przygotowano odpowiedni dokument (zgodnie z zaleceniami podejść ciężkich) zawierający zapis doświadczeń wszystkich uczestników (agentów) realizujących prace.

Przy kolejnej weryfikacji postępów w ramach zespołów postanowiono zaadaptować dobrą praktykę pochodzącą z metody XP polegającą na pracy parami. Każdemu uczestnikowi z wiedzą zarządczą, ale o mniejszym doświadczeniu w aspektach technicznych, przydzielono uczestnika o dużej wiedzy technicznej (ale mniejszym doświadczeniu w zarządzaniu). Dzięki takiemu podejściu uzyskano efekt wspólnego pozyskiwania wiedzy i możliwa stała się kontynuacja realizacji zadań.

Projekt zakończył się w wyznaczonym harmonogramie oraz zakresie (w projekcie nie przewidziano budżetu, prace były wykonywane w ramach bezpłatnych praktyk).

Wnioski

Przeprowadzone badanie pozwoliło na zweryfikowanie relacji pomiędzy agentami przy realizacji projektu. Umożliwiło identyfikację i sprecyzowanie relacji na poziomie zarządzania modelu szczegółowego a2M oraz warstw wiedzy, przetwarzania i funkcjonalności. Wskazało mechanizmy współpracy agentów. Podczas analizy relacji agentów oceniano procesy adaptacji tych relacji w oparciu o wiedzę i przetwarzanie tej wiedzy o relacjach zespołu projektowego. Wnioski z badania 7-R przedstawiono w tabeli 5.15.

Tabela 5.15 Wnioski z badania 7-R

Kod badania: 7-R

Na podstawie przeprowadzonych badań stwierdzono, że możliwe jest adaptowanie dobrych praktyk zarządzania projektami informatycznymi w zależności od zmiennych decyzyjnych nowego trójkąta ograniczeń. Zaobserwowano jednocześnie, że adaptowanie dobrych praktyk przynosi spodziewane korzyści tylko przy znanym poziomie dojrzałości klienta, zespołu dostawcy oraz entropii projektowej. Uznano również na podstawie badania, że adaptowanie dobrych praktyk z różnych metod (jak założono w modelu szczegółowego a2M) jest nie tylko możliwe, ale wręcz konieczne dla poprawnego przebiegu projektu informatycznego.

W sytuacji, kiedy poziomy dojrzałości są zróżnicowane (dojrzały klient, niedojrzały zespół dostawcy), należy dopasowywać dobre praktyki z różnych metod (zarówno lekkich jak i ciężkich).

Dzięki takiemu podejściu zastosowanemu w eksperymencie udało się zrealizować omawiany projekt.

Warto wspomnieć, że trwają przygotowania do kontynuacji tego projektu.

Należy zaznaczyć także, że podczas rozmów z niektórymi uczestnikami zwrócono uwagę, że jakość pracy poprawiła się znacznie dopiero po zastosowaniu dobrej praktyki związanej z pracą w parach. Jest to bardzo ważna wskazówka dla kierowników projektów, aby w zespołach o mniejszym doświadczeniu próbować integrować uczestników poprzez właśnie takie działanie. Dzięki temu uczestnicy mają więcej pewności co do tego, co robią (jest druga osoba, współodpowiedzialna), a jednocześnie wzajemnie się uczą. To pokazało również, że stosowanie założeń modelu szczegółowego a2M czy adaptowanie dobrych praktyk zarządzania projektami informatycznymi w odniesieniu do wartości zmiennych decyzyjnych (dojrzałość klienta, zespołu, entropia) wpływa na jakość pracy uczestników projektu. Tym samym buduje relacje między nimi i poprawia poziom tych relacji.

Warte podkreślenia jest również to, że dobre praktyki były adaptowane wraz z rozwojem projektu. Kiedy bowiem okazywało się, że zespół nie radzi sobie z zadaniami, stosowano pracę w parach, która pozwoliła na wznowienie prac. Jest to kolejna cenna wskazówka dla kierowników projektu, żeby dobre praktyki adaptować nie tylko na początku projektu, ale również w trakcie jego realizacji. Aby jednak było to możliwe, konieczne wydaje się stosowanie podejścia agentowego.

Tylko bowiem na podstawie komunikatów przesyłanych pomiędzy agentami (uczestnikami) możliwe jest zauważenie potrzeby podjęcia nowych decyzji odnośnie adaptacji kolejnych dobrych praktyk.

Takie podejście też wydaje się wnosić nowe spojrzenie na zarządzanie projektami informatycznymi. O ile bowiem zakładano do tej pory, że kierownik projektu wybiera metodę zarządzania projektami i dostosowuje prowadzenie prac do jej zasad, o tyle w podejściu agentowym mamy działanie w drugą stronę. To w zależności od rozwoju sytuacji dopasowuje się dobre praktyki.

Przy stosowaniu metod zarządzania projektami niemożliwe jest zmienianie zasad projektu (uczestnicy dostosowują się do z góry narzuconych reguł), o tyle w podejściu agentowym to zasady realizacji dostosowuje się do warunków. Następuje więc adaptacja dobrych praktyk do ograniczeń tego projektu.

Przeprowadzone badanie pozwoliło również na wskazanie pola do modyfikacji modelu szczegółowego a2M. Zastanawiano się (bazując na doświadczeniach z tego projektu), w jaki sposób kierownik projektu powinien dobierać dobre praktyki według jakich zasad. W omawianym projekcie wykorzystano doświadczenia i wiedzę agenta koordynatora. Rozważano opracowanie formalnego rozwiązania pozwalającego na adaptowanie dobrych praktyk. Uznano za konieczne sprawdzenie także możliwości sformalizowania adaptacji dobrych praktyk. Formalizacja adaptowania dobrych praktyk powinna zostać oparta na odpowiedniej funkcji (takiej jak proponowana w rozdziale II funkcja A_MATCH).

5.2 Podsumowanie — konstrukcja modelu po procesach badania