Wpis z mikrobloga

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
  • 27
@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.
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
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.
@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
@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ą
@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 ( ͡
@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
@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
@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
@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 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
@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