Czy zadania niezwiązane bezpośrednio z programowaniem to strata czasu? Statystyczny programista na zadania wprost związane z tworzeniem aplikacji poświęca średnio 19,1 godziny w typowym tygodniu pracy. Więcej czasu zajmują spotkania, prace planistyczne, rozmaite formalności i testy. Podobnie sytuacja wygląda w przypadku inżynierów oprogramowania.
Do najbardziej angażujących zadań ankietowani zaliczyli odpowiednio: burze mózgów (6,7 godziny w tygodniu), spotkania, prace administracyjne i wymiana korespondencji (5,8 godziny), oczekiwanie na wyniki testów (3,7 godziny), czy prace związane z kompilowaniem kodu źródłowego (3,5 godziny). Dodatkowo pracę programistów i inżynierów aplikacji utrudnia sam sposób organizacji pracy i konieczność równoległej realizacji wielu zadań. Są oni również często odrywani od prac związanych z projektowaniem aplikacji, bądź programowaniem. Jednocześnie średni tydzień pracy takich specjalistów liczy 41,5 godziny. Powyższe wnioski to wyniki, przeprowadzonego na grupie niemal 500 deweloperów badania firmy Electric Cloud.
Jeśli chodzi o poprawę efektywności podziału czasu, to znakomicie może pomóc temu metodyka Scrum. Konkretnie zaś, przewidziany w metodzie podział czasu w cyklu programowania na planowanie, odbiór, synchronizację pracy zespołu i samo wytwarzanie zmian.
Proces tworzenia oprogramowania składa się szereg działań związanych z: analizą potrzeb i określeniem wymagań, opracowaniem założeń aplikacji oraz jego architektury, komunikacją projektową, koordynacją prac i komunikacją z klientem, a także tworzeniem kodu i jego testowaniem. W zależności od skali zespołu i przyjętej metodyki działania powyższe działania są realizowane w ramach sztywno podzielonego zakresu obowiązków, w ramach jednego, elastycznego zespołu, bądź też wykorzystywane są pośrednie rozwiązania organizacyjne. W przypadku bardziej zwinnych metodyk programiści zaczynają pełnić inne role w projekcie. „Programowanie to ciągły cykl: pomysł – kod – testowanie – zmiana kodu albo pomysłu. Największą efektywność daje możliwość szybkiego powtarzania tego całego cyklu” – podkreśla Zbigniew Łukasiak, programista w Opera Software.
Stworzenie efektywnego środowiska pracy dla deweloperów wymaga przede wszystkim jasnego zdefiniowania roli takich osób w całym procesie tworzenia aplikacji. Potrzeba wobec tego m.in. określenia stopnia zaangażowania inżynierów i programistów w poszczególne elementy całego procesu. Wówczas łatwiejsze stanie się określenie, które zadania powinny być uznane za nieefektywne. Kluczowy często okazuje się też wybór metodyki. „Jeśli chodzi o poprawę efektywności podziału czasu, to znakomicie może pomóc temu metodyka Scrum. Konkretnie zaś, przewidziany w metodzie podział czasu w cyklu programowania na planowanie, odbiór, synchronizację pracy zespołu i samo wytwarzanie zmian. Jeśli metodę stosuje się konsekwentnie, tzn. między innymi, trzyma się ściśle timeboxów na poszczególne spotkania, efektywność wytwarzania kodu rośnie, w moim odczuciu, 2-4 krotnie względem tradycyjnego podejścia” – dodaje Marek Adamczuk, freelancer i specjalista rozwiązań SQL Server.
Efektywność prac związanych z tworzeniem oprogramowania w dużej mierze zależy również od umiejętności kierownika projektu i osób, które odpowiadają za sprawną wymianę informacji. „Najważniejszą jest osoba, która jest w stanie rozumieć biznes i odpowiednio przekazać to osobom technicznym. To dość częsty problem w dzisiejszych czasach. Ktoś coś mówi, ale nie zwraca uwagi na to, czy został zrozumiany. Efekt? Zwoływane są kolejne spotkania, a z każdym z nich ludzie mają coraz bardziej dosyć wałkowania tego samego. W takim układzie twórczość i kreatywność jest stłumiona przez zwykłą irytację” – uważa Rafał Goszyk, Business Development Manager w Arrow ECS.
Do najbardziej angażujących zadań ankietowani zaliczyli odpowiednio: burze mózgów (6,7 godziny w tygodniu), spotkania, prace administracyjne i wymiana korespondencji (5,8 godziny), oczekiwanie na wyniki testów (3,7 godziny), czy prace związane z kompilowaniem kodu źródłowego (3,5 godziny).
Jednocześnie – poza wymienionym wcześniej oczekiwaniem na skompilowanie kodu, czy wyniki testów – trudno takie obciążenia wprost uznać za stratę czasu. Wobec powyższego nie można udzielić jednoznacznej odpowiedzi na postawione w tytule pytanie. Wszystko zależy bowiem od faktycznej roli programistów oraz inżynierów aplikacji w procesie budowy oprogramowania.
Czy warto wychodzić poza sztywny podział ról? Według Marka Adamczuka – tak. „Jeśli zostawimy całą koordynację na barkach szefa projektu i uwolnimy od tej odpowiedzialności resztę zespołu w imię powiększenia wyspecjalizowanych efektywności, to szanse na urzeczywistnienie obrazka powyżej gwałtownie nam rosną. Innymi słowy: tak właśnie generujemy marnotrawstwo, przy którym te parę oszczędzonych godzin to, jak mawiał klasyk, taki pikuś mały” – kwituje Marek Adamczuk.
Dodatkowo, uelastycznienie metod pracy przekłada się zwykle na większą kreatywność zespołu. „Każdemu niebanalnemu projektowi na pewno przyda się pierwiastek geniuszu. Osoby, które go wnoszą dla projektu bezcenne, o ile nie występują w nadmiarze. I wcale nie koniecznie musi być to osoba pełniąca rolę menadżera. Bywa, że są nimi właśnie programiści. Jeśli mają odrobinę swobody, realizują pomysły, które zupełnie zmieniają obraz produktu czy projektu. Niestety to pozytywne zjawisko tłumią wszelkie metody kontroli czasu programistów, włączając w to Scruma. Firm, które potrafią to zauważyć lub wręcz zachęcić do działań wyrastających poza z góry ustalony zakres, jest bardzo mało” – mówi Marek Adamczuk.
Więcej na Grupie IT Professionals in Poland w serwisie LinkedIn.
