Async Remote: sprinty, project management i depresja
Kiedy zaczęłam czytać Async Remote, już na początku uderzyło mnie coś, na co wcześniej nie zwracałam uwagi. Mimo kilkuletnich doświadczeń ze SCRUM'em, nigdy nie zauważyłam niszczącej mocy słowa sprint. Faktycznie jest tak, że kiedy scrumowy sprint się kończy, to od razu zaczynamy następny. Niektóre zespoły mają nawet demo, retrospektywę i planowanie tego samego dnia. Wrażenie ciągłego pośpiechu może i powoduje ekscytację i poczucie produktywności, ale na dłuższą metę bardzo męczy. Bo, jak po każdym sprincie, należy się długi odpoczynek, czas na regenerację mięśni i przewietrzenie głowy. Inaczej możemy doprowadzić do wypalenia. Jest jeszcze jedna nienaturalna rzecz w sprintach, czyli podział pracy. Zazwyczaj nie zaczynami, ani nie kończymy zadań w tym samym momencie, a do tego jesteśmy zmuszeni. Może to powodować frustracje, a nawet wzajemne obwinianie w przypadku "niedowiezionego" sprintu.
Ciekawe jest też podejście autorów książki do składu i obowiązków zespołu. Dopingują każdego kodera, żeby choć trochę wcielił się w postać PMa, zbierając wymagania i zarządzając taskami. Z moich doświadczeń wynika, że to bardzo trudne do wdrożenia w życie każdego zespołu. Owszem, większość koderów uważa, że praca analityków i managerów jest prosta (a nawet zbędna), ale z przejęciem ich zadań w praktyce jest już trochę gorzej. Po pierwsze, wszystko, co odciąga nas od pisania kodu, rodzi poczucie zmniejszonej produktywności. Bledsze kwadraciki na GitHub'ie, albo całkiem białe pola powodują dreszcz i zażenowanie u wielu programistów. Po drugie, znam wielu inżynierów, którzy uważają, że im bardziej praca z kodem jest oderwana od rzeczywistości, tym jest bardziej szlachetna (jeśli mi nie wierzysz, wybierz się na konferencję JVMową). Nierozsądne wymagania klienta i upierdliwość "ludzi biznesu" nie wpływają więc pozytywnie na pracę prawdziwego kodera. Mam jednak nadzieję, że będziemy szli, jako branża, w stronę lepszej komunikacji. Wyjście z przysłowiowej piwnicy i otworzenie się na innych, różnych od nas ludzi na pewno nas nie zdegraduje, a raczej otworzy nas jako społeczność.
Wreszcie temat, który mnie ostatnio bardzo dotyczy i wystawia moją cierpliwość na ogromną próbę, czyli (zbyt) duże taski. Zabrałam się za coś teoretycznie małego, ale w kodzie legacy (choć bardzo świeżym). W dodatku z algorytmem uczącym się. Początkowym wyzwaniem było to, że nikt w zespole nie miał głębszej wiedzy na temat tego serwisu. Jeśli narzekasz na czas kompilacji, albo wykonywania się testów, pomyśl sobie, że po każdej zmianie musiałam czekać kilkadziesiąt minut na informację zwrotną. Z kilku godzin normalnej pracy robi się kilka dni. Każdego dnia kończyłam pracę w poczuciu porażki. Nie mówiąc o piątku, kiedy zaczęłam weekend ze świadomością, że to samo będę robić w poniedziałek (bo nie należę do tych, co pozwalają pracy za bardzo wkradać się w czas wolny). Poznałam dobrze uczucie rodzącej się depresji, spowodowanej zbyt długim zajmowaniem się tym samym tematem, którą opisują autorzy książki. Chętnie wróciłabym do szmaragdowych kwadratów na GitHubie, ale najpierw muszę się uporać z godzinnymi buildami i posiąść wiedzę, której nikt z obecnych developerów obecnie nie ma. Morał z tej historii jest taki, że jeśli chcesz czuć się dobrze ze swoim kodem, mieć poczucie produktywności i wychodzić z pracy z czystym sumieniem, zadbaj o jak najmniejsze taski. One wprawiają w szybszy rytm i dają więcej satysfakcji.
Ciekawe jest też podejście autorów książki do składu i obowiązków zespołu. Dopingują każdego kodera, żeby choć trochę wcielił się w postać PMa, zbierając wymagania i zarządzając taskami. Z moich doświadczeń wynika, że to bardzo trudne do wdrożenia w życie każdego zespołu. Owszem, większość koderów uważa, że praca analityków i managerów jest prosta (a nawet zbędna), ale z przejęciem ich zadań w praktyce jest już trochę gorzej. Po pierwsze, wszystko, co odciąga nas od pisania kodu, rodzi poczucie zmniejszonej produktywności. Bledsze kwadraciki na GitHub'ie, albo całkiem białe pola powodują dreszcz i zażenowanie u wielu programistów. Po drugie, znam wielu inżynierów, którzy uważają, że im bardziej praca z kodem jest oderwana od rzeczywistości, tym jest bardziej szlachetna (jeśli mi nie wierzysz, wybierz się na konferencję JVMową). Nierozsądne wymagania klienta i upierdliwość "ludzi biznesu" nie wpływają więc pozytywnie na pracę prawdziwego kodera. Mam jednak nadzieję, że będziemy szli, jako branża, w stronę lepszej komunikacji. Wyjście z przysłowiowej piwnicy i otworzenie się na innych, różnych od nas ludzi na pewno nas nie zdegraduje, a raczej otworzy nas jako społeczność.
Wreszcie temat, który mnie ostatnio bardzo dotyczy i wystawia moją cierpliwość na ogromną próbę, czyli (zbyt) duże taski. Zabrałam się za coś teoretycznie małego, ale w kodzie legacy (choć bardzo świeżym). W dodatku z algorytmem uczącym się. Początkowym wyzwaniem było to, że nikt w zespole nie miał głębszej wiedzy na temat tego serwisu. Jeśli narzekasz na czas kompilacji, albo wykonywania się testów, pomyśl sobie, że po każdej zmianie musiałam czekać kilkadziesiąt minut na informację zwrotną. Z kilku godzin normalnej pracy robi się kilka dni. Każdego dnia kończyłam pracę w poczuciu porażki. Nie mówiąc o piątku, kiedy zaczęłam weekend ze świadomością, że to samo będę robić w poniedziałek (bo nie należę do tych, co pozwalają pracy za bardzo wkradać się w czas wolny). Poznałam dobrze uczucie rodzącej się depresji, spowodowanej zbyt długim zajmowaniem się tym samym tematem, którą opisują autorzy książki. Chętnie wróciłabym do szmaragdowych kwadratów na GitHubie, ale najpierw muszę się uporać z godzinnymi buildami i posiąść wiedzę, której nikt z obecnych developerów obecnie nie ma. Morał z tej historii jest taki, że jeśli chcesz czuć się dobrze ze swoim kodem, mieć poczucie produktywności i wychodzić z pracy z czystym sumieniem, zadbaj o jak najmniejsze taski. One wprawiają w szybszy rytm i dają więcej satysfakcji.
Komentarze
Prześlij komentarz