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
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top