Komunikacja i metodyka w projekcie

W ciągu ostatnich kilku lat widzę dość radykalne zmiany w zakresie potrzeb moich klientów. Kilka lat temu królowały szkolenia z UML, BPMN. Dziś nacisk jest położony na proces wytwórczy oprogramowania. Przede wszystkim problemem jest wykorzystywanie narzędzi CASE (np.: powszechnie stosowany Enterprise Architect). Wielu zespołom brakuje uporządkowanej metodyki pracy. Metodyki, która uwzględnia specyfikę pracy organizacji, jej strukturę, wytwarzane artefakty, narzędzia, stopień rozproszenia i sposoby komunikacji zespołu.

Bardzo często, w kontekście pracy zespołu, nacisk kładziony jest na narzędzia. Ale to nie narzędzia zbierają wymagania, projektują bazę danych, dokonuję wielu modyfikacji od projektu po kod aplikacji. Robią to ludzie. W moim odczuciu myśląc o pracy zespołu należy przede wszystkim myśleć o komunikacji. Z moich obserwacji wynika, że to jeden z kluczowych elementów.

Alistair Cockburn (chyba nie trzeba nikomu przedstawiać) w A Concise Theory of Software Development in Pictures  umieścił szereg obrazów prezentujących wpływ różnych czynników na komunikację.

Pozwolę sobie zamieścić kilka z nich.

koszty odległość zaufanie efektywność

Więcej na temat czynników wpływających na proces wytwórczy oprogramowania można znaleźć tutaj.

Z powyższych obrazów wprost wynika, że komunikacja jest jednym z kluczowych czynników. W związku z tym metodyka pracy analityków, projektantów, programistów i testerów musi uwzględniać ten czynnik. Zbudowanie samego repozytorium wiedzy na temat projektowanego bądź modyfikowanego rozwiązania to tylko część sukcesu. Druga część to określenie:

  • precyzyjnych ról w projekcie (nawet jak kilka ról przypada jednej osobie),
  • mechanizmów komunikacji pomiędzy członkami zespołu a także interesariuszami,
  • minimalnego zakresu poszczególnych artefaktów (przykładowo: plan zarządzania wymaganiami, zasady specyfikacji systemu itd. itp.),
  • mechanizmów eskalacji problemów,
  • mechanizmów walidacji wytworzonych artefaktów oraz zarządzania zmianą.

Jak widać z mojego subiektywnego i zapewne niepełnego zestawienia problem komunikacji przewija się niemal w każdym z punktów. W moim odczuciu kluczowe są dwa ostatnie czynniki. Nagminny brak rejestru problemów (nie piszę tu o bardzo często sztucznie utrzymywanym rejestrze ryzyk) oraz brak mechanizmów walidacji artefaktów (nie mam tu na myśli testów gotowej aplikacji) bardzo często skutkuje przekroczeniem budżetu i czasu trwania projektu.

Jak można walczyć z takim problemem?

Ważna wydaje się metodyka pracy zespołu analitycznego, która uwzględnia geolokalizacyjne aspekty pracy zespołu oraz jego liczebność. Do tego dochodzi sposób prowadzenia spotkań by były bardziej konkretne (kilka informacji można znaleźć tutaj pod hasłem efektywne spotkania).

I na koniec ostatni czynnik – decyzyjność interesariuszy. Decyzyjność ma wpływ na walidację artefaktów i wczesne wykrycie potencjalnych usterek. To także składnik mechanizmu eskalacji problemu.

Sprawne podejmowanie decyzji to integralny składnik każdej metodyki.

 

Podobne wpisy

  • Podkarpackie modelowanie Kolejny raz okazało się, że duży potencjał jest ukryty także poza dużymi ośrodkami takimi jak Warszawa, Kraków czy Gdańsk. O Wrocławiu nie wspominając. Tym razem miałem okazję i […]
  • Obsługa plików WSDL w Enterprise Architect – Część 2 W poprzedniej części wpisu rozpoczęliśmy definiowanie modelu naszego Web serwisu zgodnego ze strukturą WSDL. Zakończyliśmy zdefiniowaniem komunikatów jakie będą wymieniane z naszym […]
  • Wersjonowanie i automatyczny backup plików z modelami Pracując nad projektem staram się zawsze robić backup. Słowa staram się jest kluczowe. Do tego kopia musi być zaszyfrowana, gdyż zdarza się, że rzeczy są ważne i praca nad nimi wymaga […]
  • Modelowanie w Visual Studio 11 O modelowaniu w Visual Studio słyszałem już od dawna. Zawsze jednak brakowało mi czasu by zajrzeć do niego i sprawdzić czy warto jest modelować w tym narzędziu. Jako, że pojawiła się nowa […]
  • Akty normatywne a wymagania Jedną z bardziej żmudnych czynności realizowanych w fazie wymagań jest analiza aktów normatywnych. W mojej ocenie dużym błędem jest wskazanie w wymaganiach na system iż ma on być zgodny […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry