Skocz do zawartości
  • Zarejestruj się za darmo i naucz się zarabiać online!

    • Dostęp do darmowych poradników pokazujących krok po kroku jak zarabiać w Internecie
    • Sposoby zarabiania niepublikowane nigdzie indziej
    • Aktywna społeczność, która pomoże Ci rozwiązać problemy i doradzi
    • Profesjonalne treści na temat SEO, social media, afiliacji, kryptowalut, sztucznej inteligencji i wiele więcej!

SzinekDev

  • wpisy
    4
  • komentarzy
    53
  • wyświetleń
    5 439

Programista bez studiów część 4


Szinek

3 473 wyświetleń

Część 4 już była, ale komuś nie podobała się zawarta w niej teza i usunął (czyli zniknoł) na zawsze ;|

Część 4, czyli jak wygląda codzienna praca programisty w korpo.

Młody dynamiczny zespół. Agile. Scrum. Mogliście spotkać się z tymi wyrażeniami. Tak jak pierwszy z reguły jest zagrywką pijarową, tak zwinność i scrum często okazują się rzeczywistością. I nie są one adaptowane w firmach, bo rzeczywiście przyniosą jakąś korzyść, ale dlatego, że jest to teraz modne i wszyscy tego używają. Niestety.
Aha, jeżeli MDZ okaże się rzeczywistością, to może być jeszcze gorzej - to znak, że zespół składa się z ludzi niedoświadczonych i firma oszczędza na najważniejszym - pracownikach. :)

Ale pozostańmy przy Scrumie i o tym jak się w nim pracuje, jakie są wady, korzyści i po co to komu w ogóle.

Podstawą tej metodologii są samodzielne zespoły deweloperskie. Oprócz nich jest product owner, czyli właściciel produktu, który ustala najważniejsze rzeczy do zrobienia w produkcie w określonym przedziale czasowym (np. w danym kwartale). Taką listę przekazuje do zespołu (który składa się z 3-9 uzupełniających nawzajem jednostek). Teamy dostają taką listę priorytetów od ownera, jednak to one ustalają co, ile oraz jak zrobią.
Praca w Scrumie polega na przeprowadzaniu tzw. sprintów, czyli małych okresach podczas których zespół jest w stanie zapewnić dostarczenie jakiegoś rzeczywistego usprawnienia do produktu. U nas są one dwutygodniowe.
Przed całym sprintem zespół wspólnymi siłami ustala ile jest w stanie zrobić, szuka ewentualnych blokerów, które uniemożliwią dostarczenie rzeczy na czas, ustala wewnętrzne kompetencje i demokratycznie deklaruje product ownerowi co zrobi w danym sprincie. Na końcu każdego sprintu jest demo, czyli zaprezentowania tego co udało się zrealizować. Podczas trwania sprintu codziennie odbywa się standup (daily scrum) podczas którego następuje synchronizacja zespołu w kwestii postępu prac.

To tyle w teorii. Jak to wygląda w praktyce? Multum spotkań. Scrum definiuje pewny maksymalny czas, który może być przeznaczony na mityngi. W trakcie dwutygodniowej pracy jest to: 
- planowanie, max. 10%, czyli 8h,
- standup - 15minut*8dni -> 2h,
- demo - godzina,
- sprint review - godzina.
Łącznie daje nam to praktycznie dwa dni wyjęte z pracy na wysiedzenie dupogodzin. No ale tragedii nie ma, 8 dni ciągłej developerki na 10 dni pracy? Haha, nie ma tak dobrze.
Niestety często w zespołach brakuje kompetencji na dany temat, potrzebna jest konsultacja, upewnienie się czy na pewno dobrze zrozumieliśmy temat, zasygnalizowanie product ownerowi ew. blokerów, brak potrzebnych narzędzi - cokolwiek. I tym samym ten czas się przedłuża (i trzeba zamulać na makekaszu :|).
Ale na tym się nie kończy. Zmiany w priorytetach powinny nie odbywać się, ale jeżeli już, to co sprint, nie w trakcie. Jak się domyślacie - tak nie jest. Często otrzymujemy jakieś wrzuty, bo "to zajmie moment", "możesz na to spojrzeć", "a ty kojarzysz ten temat", "no jak już spojrzałeś to sie tym zajmij" itd., itp. I tym samym nierzadko główny plan sprintu nie może zostać dotrzymany i kolejna seria pytań "ale jak to", "wyciągnijcie lekcję z tego sprintu", "postarajcie sie nie dopuścić do takiej sytuacji ponownie". ;|
;|
Kolejną sprawą jest, że zespół jako drużyna powinna łączyć siły w pracy nad zadaniami. Aktualnie większość iteracji odbywa się na zasadzie takiej, że team jest tworem formalnym, a każdy jego członek pracuje nad czymś innym. A potem czas na standup i synchronizacji - na pewno pół teamu nie wie czym ja się zajmuje od strony technicznej (znają tylko nagłówek zadania), z kolei ja nie wiem co robi drugie pół teamu :)  Tak być niepowinno.


Wracając do planowania i kolejnego naruszania zasad Scruma - zespół powininen sam określać co zrobi w danym okresie i potem to raportować do ownera. Ostatnio "z góry" przyszło rozporządzenie, że menedżer liniowy (czyli bezpośredni przełożony) ma również uczestniczyć w planningach i ew. wpływać na końcowy commitment, tak aby zapewnić 100% dostarczenia wartości w sprincie. Wiecie jak to się skończyło? Tak, że zespoły deklarują absolutne minimum do zrobienia, a resztę robią "na czarno", bo jakby znowu jakaś nieplanowana rzecz wpadła, to będzie świecić się na czerwono "u góry". ;)
Jeszcze taki przykład real-life: PO rzucił nam tematy na kwartał i mieliśmy się w nie wdrożyć we własnym zakresie. Spoko, już wiemy co chcemy zrobić, mamy propozycje implementacji, ale potrzebujemy konsultacji z architektem systemu, żeby zapewnić odpowiedni performance i zapewnić jak najmniejszy wpływ na zasoby serwera. Od 3 sprintów rezerwujemy czas na to - nigdy nie dostalismy architekta i te zadeklarowane godziny przepadają na nic nie robienie. Fajnie? Sami zdecydujcie.


To tyle o Scrumie. Czy dobrze mi się w nim pracuje? Tak - tak długo jak jego zasady sa zachowane i nie ma niespodzianek. Czyli nigdy. :P Znacznie bardziej do mnie przemawia Waterfall, czyli z góry określone wymagania i jedno duże planowanie, a dogadywanie szczegółów na bieżąco - jednak to sprawdza się w małych projektach (rocznych?), a nie 20 letniej kobyłce :)

  • Super 6

8 komentarzy


Rekomendowane komentarze

tl;dr:

Scrum - po co to komu w ogóle. Samodzielny product owner. Multum dni wyjetych z pracy. Brakuje kompetencji, czas sie przedluza. Zmiany w priorytetach to sprint druzynowy, powinnismy laczyc sily. Waterfall.

  • Super 1
Odnośnik do komentarza

Dobrze powiedziane, testowalem scrum w 3 firmach z dwóch sie zwolnilem bo project manager urwal sie z choinki - w zadnej nie wypalilo i wracali do waterfall. Moim zdaniem scrum masterem powinien byc programista z doswiadczeniem jakims, a nie ktos  kto zostal project managerem bo nie nauczyl sie programowac. Zle sie z takim kims wspolpracuje, bo nie rozumie  komplikacji jakie moga wystapic na kazdym kroku  - i nie rozumie jak rozwiazywac problemy w projekcie, i nie rozumie kiedy trzeba cos rozbic na pod zadania, nie rozumie tez co do niego mowisz w kontekscie programistycznym.  Wydaje mu sie w mozgu, ze jego zadaniem jest wypytywac codziennie jak idzie - kiedy mu omowisz co robisz, i jak masz problem to z czym masz problem to patrzy jak cielak a i tak dalej cie nie rozumie i wydaje mu sie ze swoje zadanie spelnil.

  • Super 1
Odnośnik do komentarza

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Ta strona korzysta z ciasteczek, aby świadczyć usługi na najwyższym poziomie. Dalsze korzystanie z witryny oznacza zgodę na ich wykorzystanie. Polityka prywatności .