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

  • Czym jest model? Model to nic innego jak reprezentacja pewnej rzeczy lub systemu charakteryzującego się miedzy innymi tym, że model: jest podobny do modelowanej rzeczy lub systemu gdyż różni się pod […]
  • TORMIGO – wymagania w chmurze Jakiś czas temu prezentowałem TORMIGO. Już za kilka dni będzie dostępna nowa wersja (2.0) tego narzędzia. Poprawiono wiele błędów i pojawi się kilka nowości. Jedną z nich jest […]
  • Jakość dokumentu wymagań Aby dokument wymagań mógł stanowić podstawę dla poszczególnych etapów cyklu życia oprogramowania musi on spełniać podstawowe kryteria jakości. Podstawowe kryteria jakości dla dokumentu […]
  • Raportowanie zmian w modelu w Enterprise Architect Zmiany w oprogramowaniu i modelach są nieuniknione. Poniżej kilka słów na temat jak je przedstawić w EA i jak je raportować. Przyjąłem, że zmiany dotyczą zmian w istniejącym już […]
  • Enterprise Architect 12 – Zmiany w menu głównym aplikacji – część 1 12 lutego firma Sparx Systems udostępniła wersję 12 (zbieg okoliczności daty i numerku wersji?) systemu Enterprise Architect. Wśród zmian znalazły się m.in. zmiany w wyglądzie aplikacji […]
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