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.
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.
