a) można patrzeć co się dzieje w zespole, ale niekoniecznie wymaga to ustnej spowiedzi. osobiście jestem zwolennikiem stalinowskich metod -> patrzymy co kto pushuje do repozytoriów
b) (...) W każdym systemie raportowania ludzie ogarną jak udawać pracę, nawet jak będzie to sprawdzanie rezultatów. IMO im bardziej jednak sprawdzamy rezultaty, a nie opowieści tym bardziej udawanie robi się pracochłonne, aż do tego stopnia, że części przestanie się chcieć udawać (ale dla pewnego procenta do zawsze będzie ciekawy sport). (...)
to tak czy siak będzie pchanie sztucznie rozdmuchanych commitów. mam ziomków w zespole co pchają pierdylion commitów dziennie. kolejny nadpisuje poprzedni i summa summarum przez kilkadziesiąt commitów niewiele się zmieniło. niektóry mają takie podejście, że wolą rozwijać programy przez pchanie śmieciowych commitów i testowanie ich dopiero wtedy, niż przez testowanie lokalnie i pchanie dopiero porządnych commitów.
rozumiem że chodzi o patrzenie co jest wrzucane a nie tylko na ilość
jak pajacom nikt nie zwróci uwagi że pchają gówna to w firmie jest większy problem niż tylko ilość commitów
mało kto się przejmuje tym jak wygląda historia commitów. ja tego pilnuję, ale jestem wyjątkiem. nie zamierzam być don kichotem i walczyć z wiatrakami porządkować commity wszystkich ludzi.
jeśli chodzi o zapewnianie jakości to podstawą są u nas testy. testy poprawnościowe, wydajnościowe, ręczne, automatyczne, itp itd. jeśli testy padają lub są niekompletne to biznes nieraz (słusznie) blokuje release'y.
jakość kodu (w sensie bardziej 'elegancja') i commitów też jest w jakiś tam sposób ważna, ale żeby to zapewnić to ktoś kto o to dba musiałby robić review w kółko. nie mam czasu, żeby pilnować wszystkich i przekonywać na siłę, że solidna historia commitów jest ważna.
ponadto w mojej korpo jest sporo roboty, która nie wiąże się z pchaniem commitów. jak zaraportować negocjowanie rozwiązań problemów z innymi zespołami, mając do dyspozycji jedynie liczenie commitów?
no opisałeś jakiej - spotkania półgodzinne bez celu
w takim razie napiszę to inaczej: w jaki sposób zaraportować jakąkolwiek robotę, oprócz klepania kodu, mając do dyspozycji jedynie liczenie commitów? tej roboty oprócz klepania kodu jest dużo. może lubisz żyć w norze i unikać jakiegokolwiek kontaktu z ludźmi i wzbraniasz się przed tym na milion sposobów. niech ci będzie. jednak zdecydowana większość projektów polega w dużej mierze na kontakcie z ludźmi (włączając w to mocno przeciągający się kontakt z ludźmi, by rozwiązać blokujące problemy), który zabiera nieraz dużo czasu.
jestem zdania, że interaktywna codzienna rozmowa (czyli to 'spowiadanie się na daily') jest elastycznym i skutecznym sposobem na wyłapywanie problemów, pod warunkiem, że jest ktoś ogarnięty w zespole, kto faktycznie bierze na klatę obowiązki team leada i interesuje się tym co i jak ludziom idzie w projekcie. my mamy takiego team leada.
to po cholerę mu ta cała publiczność?
standup ma wiele różnych celów. opisałem je. wspólna rozmowa przynosi pewne korzyści.
masz jakieś lęki przed publicznością? potrzebujesz 'safe spaces'?
dodatkowo na standupie mogę wyłapać np. czy ktoś robi coś nieoptymalnie, czy wymyśla koło od nowa, czy robi coś ciekawego na co chciałbym popatrzeć, itp itd. gdybym miał to robić przez przeglądanie wszystkich commitów, które ludzie wrzucają to spędziłbym na takim wyłapywaniu rzędy wielkości czasu więcej. podczas pracy w zespole trzeba skupiać się na aspekcie zespołowym, a daily to dość dobrze uskutecznia. na telespotkaniu dużo skuteczniejsze są prośby o pomoc, o planowanie release'ów i wykorzystania infrastruktury żeby uniknąć konfliktów, czy ogólnie o pomysły jak sobie z jakimś nieintuicyjnym problemem poradzić. pytanie na czacie jest zwykle zbywane, bo po pierwsze można wyjść z założenia, że ktoś inny odpowie, a poza tym przede wszystkim mało kto śledzi czat na bieżąco, zwłaszcza po południu. jeśli na telespotkaniu następuje cisza to popycha to do odezwania się, a natomiast cisza na czacie to norma, nikogo to nie obchodzi. jest pewien kompromis - gadając o problemach na daily trzeba czekać, aż do tego daily, ale przynajmniej jest dużo większa szansa, że ktoś się do tego odniesie niż przy pisaniu na czacie. z drugiej strony, zwykle mam na tyle dużo roboty, że z większością problemów mogę czekać ten kawałek dnia, bo w międzyczasie zajmę się czymś innym, także potrzebnym. zawracanie gitary na standupie ma też tę zaletę, że standup jest od zawracania gitary (tzn. wiadomo kiedy jest standup, więc pracę rozplanowujemy tak, żeby nam jej nie rozpieprzał), natomiast zawracanie gitary w przypadkowych momentach w środku dnia mniej lub bardziej rozpieprza pracę. zależy od dyscypliny. ja mam problemy ze skupieniem.
asynchroniczność jest trudna dla coniektórych, takie nowatorski pomysł : ktoś pisze pytanie a ktoś inny odpowiada gdy ma wolną chwilę jeszcze chyba nie był tam wdrażany?
natomiast rozplanowywanie pracy pod standupy powoduje ze zamiast pół godziny tak naprawę zabiera on 1.5 h
testowałem tę asynchroniczność wielokrotnie i jednak nieraz wolę zawracanie gitary na spotkaniu przeznaczonym specjalnie na zawracanie gitary czyli standupie. czasami lepiej działa czat, a czasami telekonferencje. czasami lepiej działa zawracanie gitary pojedynczym osobom, a czasami pytanie wszystkich naraz.
jeśli masz standupy na 1,5h to znaczy, że nie potraficie organizować czasu. napisałem jak zarządzać czasem, żeby nie rozciągać standupów na 1h lub więcej.
jak nie, jak tak
co nie tak? napisz pełnym zdaniem jak normalny człowiek.
Jakieś półgodzinne standupy z menadżerką to nic innego jak zwykła kontrola, która nikomu oprócz menadżerce nie służy.
menedżerka zwykle tylko kibicuje 'z dala' i się nie wtrąca. co mnie obchodzi co ona robi ze swoim czasem, dopóki (z mojego punktu widzenia) wywiązuje się z obowiązków wobec zespołu?
jakby chciała to by się przypieprzała, np. pytałaby się czemu tak mało commitów wrzucam i wtedy musiałbym się z tego spowiadać. po co taki cyrk odwalać?
na standupie mówię do zespołu, a nie do menedżerki.
No i nadal to jest bez sensu i świadczy o braku fundamentalnego zaufania w zespole. Daily powinno być dla programistów i w zupełności wystarczy w formie asynchronicznej, kiedy w zespole ludzie darzą się zaufaniem. Tak jak wspomniałem wcześniej, to kwestia dojrzałości człowieka. Ufamy sobie i wiemy co wrzucamy, wszyscy pracujemy na jeden cel. Jak ktoś przestaje być dojrzały, to łatwo to wychodzi i można się z taką osobą pożegnać. Co do sprawdzania czatu to nadal jest to kwestia dojrzałości i pewnego nawyku. Jeśli się na coś umawiamy, to tego dotrzymujemy.
Problemem 95% zespołów scrumowych jest właśnie brak zaufania. Dobiera się ludzi z pierwszej łapanki i potem prowadzi interaktywne cyrki.
brzmi jakbyś miał jakąś nieprzepracowaną traumę i sama obecność menedżera na daily wzbudzała w tobie negatywne emocje. nasze daily jest dla programistów, a menedżerka tylko jest obecna i się nie wtrąca, no chyba, że jest jakieś 'ogłoszenie parafialne', tzn. dostała jakieś info, które należy ogłosić zespołowi, ale nie jest to zależne od tego co komu się udało od ostatniego standupu zrobić.
jak już napisałem, jeśli menedżer jest toksyczny i chce mikrozarządzać itd, to nie ma znaczenia jak zorganizowana jest komunikacja w zespole. to czy jest na daily, czy go nie ma, nie powstrzyma go przed mikrozarządzaniem i nie zahamuje jego toksyczności.
jeszcze wracając do samego czatu to wiadomości na czacie jest zdecydowanie zbyt dużo, żeby się wszystkiemu uważnie przyglądać. nie ma takiego zalewu spamu jak emailami, ale i tak jest dużo szumu. mamy mnóstwo współdzielonych czatów, bo współpracujemy z różnymi zespołami (więc rozdzielamy dyskusje tematycznie). tymczasem na daily nie da się 'zalać' rozmowy wielostronicowym szumem informacyjnym, bo zarządzamy czasem, tzn. grubsze tematy do szczegółowego przegadania oddzielamy od właściwego standupu.
