Witajcie w pilotażowym odcinku podcastu Dev:Cast. Pierwszym poruszanym tematem jest długi, rozciągający się w czasie Daily Scrum. Czasem pojawiają się tematy, które powinny zostać jedynie zasygnalizowane i kontynuowane już po tzw. standupie. Niestety stają się niezłą odskocznią od głównego wątku rozmowy, zajmując czas, a nie raz wyzwalając zażartą dyskusję. Rozważamy jak można zapobiec takiemu problemowi bez osoby sprawującej roli supervisora. Jeśli pracujesz w scrumie i czujesz, że Twoje daily stało się za długie oraz „wymemłane” – to idealne trafiłeś. Niech pierwszy odcinek Dev:Cast pomoże Ci w rozwiązaniu tego problemu.
Dodatkowy odsłuch Dev:Cast
Różnorodność używanych mediów do śledzenia podcastów jest jeszcze dla nas nowością. Dlatego na początek, podcast Dev:Cast możesz słuchać:
- w serwisie Spreaker (odsłuch u góry),
- w serwisie YouTube,
- w wersji bezpośredniej, pobierając plik MP3.
Udział wzięli
Chcemy aby podcast tworzony był przez różne osoby. Dlatego, też będziemy się starać rozmawiać w różnorodnym składzie, zapraszając do pogawędki także osoby z poza grona naszej rodziny DevEnv. W pierwszym odcinku usłyszycie głosy następujących osób:
- Adrian Piętka,
- Bartłomiej Michalski,
- Tomasz Niemiec – Team Leader w Future Processing.
Masz pomysł na temat?
Jeżeli chcesz abyśmy porozmawiali na jakiś konkretny temat, zgłoś go za pośrednictwem komentarza pod tym odcinkiem lub za pomocą naszego fanpage w serwisie Facebook.
Mam pytanie dotyczące 'problemów’, o których wspominacie w podcascie. Czy daily nie jest najlepszym miejscem do wspominania o zaistniałych problemach? Nawet jeśli dotyczy on aspektów technicznych, tak?
Myślę że ludzie mają obawę przed wspominaniem o rzeczach, z którymi sobie nie radzą, gdyż problem z reguły odbierany jest jako zła rzecz.
Tutaj chciałbym też zaproponować kolejny temat na podcast. Problemy. Nie każdy o nich daje znać, nie każdy też reaguje na zgłoszone problemy. Jak zakomunikować problem tak, by spotkał się on z pozytywnym odzewem i chęcią pomocy.
Czy najlepszym? To zależy, natomiast na pewno jest miejscem gdzie powinno się mówić reszcie zespołu o problemach w dowiezieniu celu sprint przez zespół do mety. W dyskusji chciałem zaznaczyć, że klasyczna/dawna forma pytań na daily (choć właściwie pytań być nie musi) powinna być skierowana na cel sprint całego zespołu, a nie wyłącznie na „moich” zajęć. Dzięki temu a) unikniemy sytuacji, schodzenia z tematów nie związanych z aktualnie toczącą się iteracją, b) unikniemy postrzegania daily jako spowiedzi świętej przed kolegami lub (najgorzej) liderem/SM.
Ważne by pamiętać, że daily to timebox 15min. Problemy, których nie jesteśmy w stanie samodzielnie ubić, oczywiście trzeba poruszyć, aczkolwiek niekoniecznie je rozwiązać.
Mam nadzieję, że to nieco rozwiało Twoje wątpliwości, a o problemach na pewno kiedyś pogadamy na podcastcie 😉
Dzięki za komentarz tomatlover. Pozwólcie, że wtrącę jeszcze swoje trzy grosze.
O problemach powinniśmy w ramach zespołu rozmawiać cały czas. Nie czekać na daily. Każde wspólne wyjście na kawę, chwila oderwania się od wzroku wbitego w monitor to odpowiedni moment na rozmowę o problemach. Jeżeli nie chcemy przeszkadzać w skupieniu możemy poinformować o problemie i poprosić o pomoc na komunikatorze.
„gdyż problem z reguły odbierany jest jako zła rzecz”
Z takim podejściem należy pracować i starać się je wręcz wybijać z głowy. Praca programisty to głównie rozwiązywanie „jakiś problemów” 🙂
Czasem się śmiejemy w zespole to „nie problemy” to „wyzwania” 😀 Pozdrawiam.