Metodyka agile jest obecnie bardzo często stosowana w realizacji projektów związanych z tworzeniem oprogramowania. Jej adaptacja w zespołach programistów według raportu Digital.ai wzrosła w 2020 r. z 37 do 86 proc. Kluczowym czynnikiem napędzającym agile jest dla 68 proc. organizacji przebadanych przez KPMG szybsze dostarczanie produktów.
Trudno zaprzeczyć, że podążanie za nowoczesnymi technikami zwinności jest jednym z najlepszych podejść do procesu wytwarzania oprogramowania. Czasami wymagania agile są jednak zbyt wysokie i trudne do realizacji w konkretnym projekcie, a nawet mogą opóźnić jego start produkcyjny. W takich wypadkach dobrze jest odejść od formalnych ograniczeń agile i skorzystać z techniki semi-agile, która poprowadzi do sukcesu nieco inną drogą.
Kiedy można pomyśleć o semi-agile
Semi-agile jest nowatorskim podejściem do realizacji projektu i nie jest to metodyka, którą można zastosować w każdym przypadku. Przede wszystkim wymaga zaufania pomiędzy partnerami, nie jest to więc metoda, którą można wykorzystać przy pierwszym projekcie z nowym dostawcą, a dla dostawcy – z nowym klientem.
Semi-agile minimalizuje formalności oraz tarcia związane z brakami budżetowymi, a także ogranicza niedopowiedzenia w koncepcji oraz jej zmiany w trakcie trwania projektu. Jednym słowem, pozwala w jak największym stopniu skupić się na pracy i dostarczaniu wartości, czyli tworzeniu rozwiązania jak najlepszego jakościowo zarówno w warstwie funkcjonalnej, jak i wizualnej.
Agile zakłada, że na początku projektu nie da się dokładnie zaplanować jego całego przebiegu, co skutkować może dodatkowymi godzinami pracy. W semi-agile łatwiej jest zapanować nad harmonogramem oraz budżetem, ponieważ podejście to pozwala odrzucić elementy, które kradną czas pracownikom merytorycznym, zostawiając kierownikom projektu pilnowanie harmonogramu i sprawdzanie, czy wszystko idzie zgodnie z planem. Architekt rozwiązania, programiści i konsultanci nie tracą więc czasu na utarczki związane z niedomkniętą koncepcją czy występującymi w niej lukami, tylko zajmują się rzeczywistą pracą. – Podczas innych projektów musiałem poświęcać dużo czasu na różnego rodzaju spotkania, zmiany koncepcji i nie mogłem skupić na najważniejszym, czyli na tym, jak przebiega realizacja projektu, oraz na tym, by na bieżąco kontrolować pracę programistów i konsultantów. Nie mogłem też uczestniczyć we wszystkich spotkaniach zespołu projektowego, bo równolegle miałem posiedzenia z PMO czy z zarządem. A podczas realizacji „niezorganizowanego” projektu 95 proc. czasu zajmowała praca z zespołem i z klientem. – mówi Filip Stankowski, Automotive Solution Architect w Hicron.
