[cptKaladin]

Od marca mam przejąć mały zespół (3 osoby plus ja) po gościu co odchodzi z pracy. Generalnie jestem programistą i wcześniej nie musiałem bezpośrednio zarządzać ludźmi, raczej w projektach współpracowałem z innymi programistami nad jakimiś zadaniami, ale teraz mam mieć oddzielny zespół tylko do jednego projektu. I żeby nie było zespół się skłąda tylko z programistów plus testera jako dokładkę policzonego na część etatu, żadnego PO, SM nie ma (ale jeżeli chcę mogą być). Sam projekt ma jasne założenia do spełnienia i jest dobrze zdefiniowany.

Do tej pory pracowałem w zespole w dostosowanym do nas kanbanie, mój szef jest super gościem (przede wszystkim samemu programuje i zna realia) i słuchał tego jak chcemy pracować, więc wszelkie spotkania są ograniczone do minimum i po prostu mamy czas na robienie roboty. Mamy jedno na tydzień spotkanie, gdzie mówimy co zrobiliśmy, omawiamy i przydzielamy taski oraz jak są jakieś uwagi co do zarządzania itp. to też wtedy mówimy, wychodzi jakaś godzina. Reszta komunikacji przebiega po prostu między członkami zespołu bez tracenia czasu w angażowanie wszystkich.

Piszę, bo chciałbym poznać waszą opinię odnośnie tego jak się wam dobrze pracuje, co jest spoko do wprowadzenia w małych zespołach? Raz mieliśmy próbę wprowadzenia scruma, ale totalnie się nie sprawdził. Tutaj akurat z prespektywy czasu muszę powiedzieć, że było to wprowadzane nieudolnie, więc może dlatego. Osobiście nie do końca wierzę w tą metodykę (niemożliwe, że nie lubisz scruma, spróbuj innego różne są), chociaż część rzeczy niby jest spoko, na przykład retro. Dla mnie im więcej spotkań tym mniej czasu do robienia roboty, gdzie potem na spotkaniach omawiasz czemu robota nie jest zrobiona.

Myślałem, żeby wprowadzić coś na wzór tego jak teraz pracuję co opisałem wyżej, ale zespół jaki mam przejąć skłąda się z nowych osób zatrudnionych niedawno do tamtego projektu i nie jestem przekonany, czy się to dobrze sprawdzi. Nigdy z nimi nie współpracowałem, z tego co słyszałem to sam projekt szedł wolno. Programiści też są mocno zróżnicowani poziomem zaawansowania, czasem ktoś utyka na zadaniu na długi czas zamiast się spytać o radę samemu. W projekcie mam zarządzać i też być jako główny programista.

Na pewno na początek będę chciał pogadać z każdą osobą z zespołu jak się pracowało i co było spoko / słabe, ale może mireczki mi coś podpowiedzą? Co sądzicie? Co wam się podoba w zarządzaniu u was w pracy co mogę wprowadzić? Co jest słabe i nie chcielibyście tego u siebie w pracy?

#pracait #programowanie #programista15k #scrum #kanban

[qusqui21]

@cptKaladin: stworz wrazenie ze sam tez wszystkiego nie wiesz, glosno mysl itd. Oczywiscie wiadomo, ze wszystkiego nie wiesz. Jak jest zadanie, to opowiedz jak bys to widzial, jak ktos sie bedzie chcial wykazac, to sam bedzie proponowal rozwiazanie, jak nie to przyjnajmniej zrobi ktos z grubsza to co potrzebujesz.

[masterix]

le zespół jaki mam przejąć skłąda się z nowych osób zatrudnionych niedawno do tamtego projektu i nie jestem przekonany, czy się to dobrze sprawdzi.

@cptKaladin: dobry onboarding + daily (czyli to co wy robiliście jako weekly) powinno się sprawdzić

na przykład retro. Dla mnie im więcej spotkań tym mniej czasu do robienia roboty, gdzie potem na spotkaniach omawiasz czemu robota nie jest zrobiona.

@cptKaladin: gdy coś jest problemem to ważne

[cptKaladin]

@qusqui21: Dzięki słuszne uwagi

[masterix]

Co jest słabe i nie chcielibyście tego u siebie w pracy

@cptKaladin: scrum na siłę

[MilionoweMultikonto]

@cptKaladin: co Ci się najbardziej podoba w retro?

[maur]

@cptKaladin: to co opisujesz nie widze by sie sprawdzilo z nowymi ludzmi, zdecydowanie proponowalbym daily - jesli nie wprowadzac calego scruma to chociaz to :)

[groman43]

Myślałem, żeby wprowadzić coś na wzór tego jak teraz pracuję co opisałem wyżej, ale zespół jaki mam przejąć skłąda się z nowych osób zatrudnionych niedawno do tamtego projektu i nie jestem przekonany, czy się to dobrze sprawdzi. Nigdy z nimi nie współpracowałem, z tego co słyszałem to sam projekt szedł wolno. Programiści też są mocno zróżnicowani poziomem zaawansowania, czasem ktoś utyka na zadaniu na długi czas zamiast się spytać o radę samemu.

[cptKaladin]

@masterix: XD
@MilionoweMultikonto hmm nie chodzi mi tutaj o retro w stylu "jakim zwierzęciem nazwałbyś ostatni sprint" tylko o miejsce w którym patrzysz jak przebiegała praca ostatnio i co można poprawić. Na przykład coś zajęło długo, bo nie przewidzieliśmy czegoś, wymagania były z dupy, albo źle opisane zadania, albo bo ktoś mi zawracał dupę z innego zespołu, sprzęt nie był gotowy, a miał być itp i jak to można rozwiązać w

[cptKaladin]

@groman43: Dzięki za spostrzeżenia, też się właśnie obawiam, że jedno spotkanie może być przynajmniej na początku mało, dlatego myślałem nad wprowadzeniem daily. Samemu jak zaczynałem swoją przygodę z programowaniem to byłem zostawiany samemu sobie i wiem, że nie jest to efektywne i rozwojowe, dlatego chciałbym tutaj pracować w inny sposób jak mam szansę. Niestety ze względu na NDA nie mogę mówić jaki projekt, coś związanego z optymalizacją

[groman43]

@cptKaladin: Szybkie, krótkie daily powinno zrobić robotę. Jeśli zobaczysz, że ktoś ma problemy i będziesz chciał dopytać o szczegóły lub mu doradzić, to zrób to po spotkaniu (no chyba że uważasz że cały zespół powinnien to wiedzieć). Ale proszę zreyzgnuj proszę ze wszystkich scrumowych rytuałów. Na Twoim miejscu nawet nie nazywałbym tego spotkania "daily", ale "sync meeting".

Optymalizacja czegokolwiek poganiania grupą niedoświadczonych programistów może być wyzwaniem samym w sobie ( ͡

[cptKaladin]

@groman43: na szczęście deadline jest odległy i mam obiecane od mojego szefa, że jeżeli powiem, że potrzebuję kogoś dorzucić do zespołu kto będzie ogarniał, bo się nie wyrobimy to będzie to zrobione

[masterix]

@masterix: XD

@cptKaladin: z czego xd?

[cptKaladin]

@masterix: Po prostu jak mieliśmy próby wprowadzenia scruma u nas to powiedziałem dokładnie to na spotkaniu "co nam się nie podoba w obecnym zarządzaniu"

[masterix]

@cptKaladin: Ok :D

[NitrousOxide]

@cptKaladin nie przywiązuj się do definicji. Możesz wprowadzić scrumbana, kanbanfalla czy cokolwiek. Wszystko zależy od projektu, przydziału zadań i problemów. Jeśli daily będzie wyglądało jak spowiedź każdego programisty z każdej godziny ostatniego dnia, to ludzie szybko się wkurzą. Niemniej o problemach warto rozmawiać od razu jak się pojawią. Spotkania 1-1 to dobry pomysł. Czasem wkurzają, a czasem są bardzo przydatne. Niemniej nie zawsze jest o czym gadać. Jeśli deadline jest odległy to

[bb89]

@cptKaladin jeśli zdecujesz się na scrumowe ceremonie typu retro itp to pilnuj żeby raczej nie były odwoływane, często przekładane bo na nich ludzie maja chwile żeby powiedzieć co im się nie podoba w pracy co trzeba poprawić albo powiedzą wprost swoje pomysły, daily powinno być tylko od statusu

[cptKaladin]

@NitrousOxide: Dzięki za pomysły. Sam programuję, więc wiem jak jest, rozliczanie czasu pracy jest mocno bez sensu, czasem idzie super, a czasem człowiek siedzi i musi coś przepisać co już niby było zrobione, bo w przyszłości to zaprocentuje.

Daily nie chciałbym właśnie wprowadzać jako rozliczanie czasu pracy tylko szybkie podsumowanie co się robiło, co się będzie robić i ewentualne zakomunikowanie problemów jakie były / są. Szczególnie byłoby to na plus jak

[cptKaladin]

@bb89: Yeap jak pisałem wyżej daily chciałbym tylko dla statusu i potem ewentualnie w mniejszym gronie rozmawiać o problemach, dzięki

[NitrousOxide]

@cptKaladin co do tych kamieni milowych to w jakiś sposób powinny być spięte ze sprintami, ale to nie musi być 1:1. U nas na przykład mamy sprinty miesięczne i co miesiąc coś instalujemy na produkcji. Dzięki temu widać postęp. Niestety u mnie to jest masa pomniejszych projektow zamiast praca nad jednym produktem, niemniej na początku sprintu, czy tam release'a definiujemy co zrobimy i do kiedy mamy zakończyć tematy, aby testerzy mieli czas

[Sarpens]

@cptKaladin: Mógłbyś opisać czemu Scrum wiąże Ci się z ciągłym odrywaniem od pracy? Pytam, bo Scrum sam w sobie definiuje jedynie cztery wydarzenia w trakcie sprintu:
- daily - 15 minutowe codzienne spotkanie w celu ustalenia czy cel, który zdefiniowaliście na planowaniu nie jest zagrożony
- review - na którym podsumowujecie co się udało, co się nie udało wyprodukować przez sprint
- planning - na którym planujecie co chcecie osiągnąć w

[Zielony_Minion]

@cptKaladin: Ktoś już napisał, że przyznawanie się że czegos nie wiesz, może pomóc otworzyć się innym. Jeżeli wiedzą, że poproszenie o pomoc to nie tabu, to zaczną to robić.

Ale wtedy upewnilbym się że ta pomoc dostaną. Nie samo "idź do Piotrka on to robił", bo szansa jest, że Piotrek będzie zajęty i powie żeby przyjść za miesiąc. (Tu po zastanowieniu może to zalezec od osoby i ich metody działania. Obu:

[Oo-oO]

@cptKaladin: nie rób z daily raportowania statusu, taka moja sugestia - raczej krótkie ciekawostki, lub jeśli jest problem, to przedstawienie problemu. Jeśli są osoby które chcą pomóc rozwiązać problem - to po daily sobie mogą pogadać jak nie, cóż - jesteś ty.

Ogólnie widziałbym to w taki sposób - najpierw rozmowa 1-1 z każdym, by poznać swój zespół, jakie masz mniej więcej kompetencje w zespole.

Zdefiniuj kilka zadań o zróżnicowanym poziomie

[cptKaladin]

@Zielony_Minion: rzeczywiście jak robisz coś wizualnego to łatwiej się chwalić.

Co do tego, żeby osoba co może pomóc była dostępna to dobra rada, będę miał na uwadze

[cptKaladin]

@Oo-oO: bardzo fajnie napisane, dzięki za rady

[cptKaladin]

@Sarpens: jak pisałem było to prowadzone słabo u nas, niby 4 spotkania, ale jeszcze z każdej niewielkiej dyskusji wewnątrz zespołu też było podejście "to zrób spotkanie doproś X i Y" i potem była często bezsensowna dyskusja, która mogła być zakończona wcześniej w 10 minut. Robienie problemów tam gdzie ich nie ma (też spotkanie, bo klient coś chce się spotkać).

Pod koniec projektu było tak, że się opóźniało wszystko, bo termin realizacji

[WyjmijKija]

@cptKaladin: daily koniecznie. Najlepiej jak najwcześniej rano na start dnia. Do tego wcale nie byle na szybko. W małym zespole fajnie jest gdy wszyscy rozumieją dobrze ci robimy i dokąd zmierzamy. Warto czasem przegadać coś więcej. Czasem nawet 45 minut może zejść. Czasem 5. Ważne żeby potem w ciągu dnia co chwilę nie było przerywników. Najlepiej, żeby potem w ogóle nie było spotkań natomiast warto, żeby były momenty, że można się

[FiranMercury]

Ktoś wyżej super napisał. Daily to bardzo dobry sposób na update i poznanie sposobu pracy i myślenia innych. Warto wypracować w zespole otwartość do dyskusji.