Zatwierdzanie kontroli wersji przez menedżera

Nasz menedżer monitoruje zobowiązania Git we wszystkich naszych projektach; zazwyczaj nie stanowi to problemu i uwielbiam fakt, że kontrola wersji zapewnia dziennik całej pracy, szczególnie do późniejszych audytów i analiz (na wypadek, gdyby coś poszło nie tak).

Jednak kierownik napisał kilka komentarzy, pytając, nad czym pracują ludzie, gdy widzi zatwierdzenie czytające „poprawki stylu” lub dowolną wiadomość zatwierdzenia, która nie odwołuje się do numeru zgłoszenia w naszym systemie zarządzania zadaniami.

Czy istnieje rozwiązanie społeczne lub techniczne?

Dalsze informacje: jest to projekt konserwacji, więc jest kilka „musiałem wykonać A, następnie B, następnie C, a następnie D, a następnie w końcu zrealizować zadania X”.

Więcej informacji: konkretny komunikat zatwierdzenia, który podniósł flagę z menedżerem, był zbliżony do „zawiera lepszy sposób na X, Y i Z”, który jest bardziej komunikatem refaktoryzującym niż zwykłą poprawką stylistyczną.

version-control management

— Peter Mortensen
źródło

możliwy duplikat Czy odniesienie do błędu / problemu w komunikacie zatwierdzenia jest uważane za dobrą praktykę?

— komara

Zgadzam się z twoim przełożonym. Patrzenie na dwuletni dziennik zatwierdzeń, aby dowiedzieć się, kiedy coś się zmieniło i zobaczenie zmian, takich jak „poprawki stylu”, jest cholernie denerwujące. Jeśli Twój menedżer nie pozwala Ci dodawać zadań refaktoryzacyjnych do systemu zarządzania zadaniami, to zupełnie inna sprawa.

— Gort the Robot

Prawdziwe refaktoryzacja jest jeszcze ważniejsza do uchwycenia niż zmiany stylistyczne. Przynajmniej komunikat zatwierdzenia powinien zawierać informację o tym, co jest refaktoryzowane, ale tak naprawdę chciałbym, aby było to śledzone, aby każdy wiedział, co jest refaktoryzowane, QA wiedział, co przetestować dokładniej itp.

— Gort the Robot

^^^ co powiedział @StevenBurnap - to bardzo dobra praktyka. Po prostu możliwość odsyłania identyfikatora biletu zamiast zanieczyszczania komunikatu zatwierdzenia z długimi objaśnieniami, jaki rodzaj ulepszeń / refaktoryzacji istnieje i dlaczego są one pożądane, sprawia, że warto. I jest jeszcze coś więcej, wysiłek śledzenia, komunikacja z zarządzaniem / QA itp. I nie zaczynaj mi, jak to jest wygodne, gdy tracker błędów integruje się z narzędziem VCS / przeglądu kodu

— gnat

Zależy to całkowicie od sytuacji. Czy menedżer reaguje na członka zespołu, który spędza 50% swojego czasu na refaktoryzacji lub na pojedyncze zatwierdzenie bez podania biletu?

— winkbrace,

Odpowiedzi:

Czy istnieje rozwiązanie społeczne lub techniczne?

Przypuszczam, ale to nie jest problem .

Twój menedżer powinien wiedzieć, co robicie. Powinni upewnić się, że nie wykonujesz pracy, która nie przynosi żadnej wartości, lub dlaczego priorytetem była praca bez biletów. Nie ma w tym żadnej szkody. W idealnym świecie przyniesie to korzyści, ponieważ Twój menedżer może ustalać oczekiwania w biznesie, abyś mógł wykonać całą tę pracę bez presji lub przerw.

Staje się to problemem tylko wtedy, gdy kierownik uważa, że należy wykonywać tylko prace związane z biletami, i wyklucza to, aby prace techniczne były biletami. Zawsze trzeba spłacić dług techniczny. Zawsze coś do poprawienia, ponieważ powinieneś, nawet jeśli nie zapewniają one wyraźnych, natychmiastowych korzyści biznesowych.

— Telastyn
źródło

Jeśli poprawka stylistyczna jest częścią biletu, nad którym pracujesz i jest powiązana, nie ma nic złego w oddzielnym sprawdzeniu go za pomocą tego samego numeru biletu, nad którym pracujesz, dla lepszej identyfikacji.

Jeśli dopiero odkrywasz zmiany, które należy wprowadzić i nie są one związane z biletem, nad którym obecnie pracujesz, sugerowałbym zrobienie biletów związanych z zadłużeniem technicznym i umieszczenie ich w zaległościach w celu późniejszego ponownego przeliczenia.

Podczas planowania możesz następnie przejrzeć bilety związane z zadłużeniem technicznym i dołączyć je do faktycznych biletów serwisowych, które planujesz w ten sposób, aby były bardziej powiązane.

Pomoże Ci to wyeliminować poprawki „znikąd” i sprawi, że wszystko będzie zamknięte w kategorii konkretnych problemów / zgłoszeń, nad którymi pracujesz.

— AvetisG
źródło

Ok, ale jeśli jest to trywialna poprawka, to jest to całkowicie głupie.

— Lekkość ściga się z Moniką

Zadłużenie technologiczne 99,99% czasu nie jest banalną zmianą. Dlatego mówię zrobić bilet zamiast nurkować w czymś innym, co jest dużym przełącznikiem kontekstu. Jeśli jest to coś trywialnego i niezwiązanego z tym, nad czym pracujesz, nadal możesz to sprawdzić pod nazwą biletu, nad którym pracujesz, z osobnym komentarzem. Albo jeszcze lepiej pomyśl o notacji, takiej jak QFIX, która ułatwi później identyfikację, dzięki czemu nie będziesz mieć przypadkowych, błahych zmian bez organizacji.

— AvetisG

co jeśli menedżer ogląda również JIRA w poszukiwaniu nowych biletów, a następnie je przesłuchuje? nie pyta, kiedy bilety zostaną przeniesione z przyszłego sprintu na bieżący, ale gdy tylko ktoś stworzy nowy bilet związany z długiem technicznym, jest on kwestionowany.

— Rudolf Olah

Notacja QFIX pierwsza jest czymś, o czym trzeba porozmawiać jako zespół przed wdrożeniem. Chodzi o komunikację, nie tylko wskakujesz i piszesz własne zasady. Więc najpierw porozmawiaj o tym jako zespole, a następnie, jeśli się nie zgadzają, przejdź do innego rozwiązania, które polega na sprawdzeniu go wraz z głównym biletem, nad którym pracujesz, z osobnym komentarzem. Pamiętaj jednak, po raz kolejny, tylko jeśli zmiana jest trywialna, co oznacza, że nie zawiera żadnych zmian logicznych ani dużych refaktoryzacji. Niewinne, nieszkodliwe, trywialne zmiany.

— AvetisG

@omouse Może się zdarzyć, że twój menedżer zarządza mikrozarządzaniem lub że nie zajmuje się odpowiednio długiem technicznym. Jednak menedżer jest ostatecznie odpowiedzialny za projekt jako całość i za sam kod, dlatego idealnie powinien być na pewnym poziomie świadomy każdej części pracy i dlaczego.

— Gort the Robot

To też mnie wkurza (nie ma zamiaru gry słów :).

Najbardziej pomocne zameldowania zawierają komentarze, które są unikalne i dotyczą nie tylko tego, co się zmieniło, ale również dlaczego. Czasami umieszczam komentarze do akapitu.

Od czasu do czasu wpadam w sytuacje, w których wymagania dotyczące interfejsu użytkownika odbijają się w przód iw tył po rozpoczęciu programowania, co wymaga ode mnie zasadniczo odskoczenia kodu (tak, czasami świat rzeczywisty jest do kitu). W takich przypadkach uważam za jeszcze ważniejsze, że moje komentarze wyjaśniają, dlaczego odrzucenie, a co ważniejsze, dlaczego kod kończy się tam, gdzie to robi. Następnie, kiedy kierownictwo wraca po rozmowie z klientami i chce wiedzieć, dlaczego, mogę im pokazać bez konieczności pamiętania całego doświadczenia.

— Worrystone
źródło