Jak wygląda dobra „definicja wykonania” dla dojrzałego zespołu?

Patrząc na przykłady definicji wykonanych w różnych źródłach, zwykle zawierają one punkty podobne

• kod ukończony
• uruchamiane testy jednostkowe
• kod sprawdzony lub sparowany
• kod zalogowany
• zaktualizowana dokumentacja
• …

W naszym zespole mamy podobną listę, ale nikt nigdy na nią nie patrzy, ponieważ te punkty wydają się tak rażąco oczywiste, że nikt nie pomyliłby się, aby pominąć którykolwiek z tych kroków. Zastanawialiśmy się więc, czy jest to głównie narzędzie dla zespołów przechodzących do sprawnego procesu i czy nie powinniśmy się go po prostu pozbyć.

Z drugiej strony wiele literatury twierdzi, że wszystkie zespoły o wysokiej wydajności mają silną definicję „zrobione”. Tego rodzaju podpowiedzi, których moglibyśmy przegapić, aby poprawić tutaj.

Jakie są zatem przykłady mocnych definicji zrobionych przez dojrzały zespół? Jakie punkty zawierają zazwyczaj?

Wytyczne są dostępne dla wszystkich. Jak wspomniałeś, w dojrzałym zespole wszyscy to robią, więc to nie znaczy, że nie ma na to miejsca. Załóżmy, że dołącza nowy członek, który wcześniej nie był narażony na tę metodologię. Posiadanie odpowiedniej struktury byłoby dla niego niezbędne. Nie musiałby niepokoić innych członków ani nie „zapomniałby” o dostawie.

Moim zdaniem, Wymień wszystko, w tym oczywiste. Być może przygotuj „krótką listę oszustów” dla nieoczywistych, jeśli pomoże to tym, którzy chcą krótszej listy, ale rozważ przypadek nowych członków wskakujących.

Jest to proces iteracyjny, za każdym razem, gdy zobaczysz coś, co możesz poprawić, dodaj go do definicji gotowego. W godzinach nadliczbowych opracujesz listę, która jest odpowiednia dla Twojej firmy. Anann wspomniał już o niektórych, które są warte zachodu.

To, że punkty są rażąco oczywiste, nie oznacza, że ​​ludzie zawsze je wykonają. Weźmy dwa inne przykłady - pilotów i chirurgów. Kokpit komercyjnego samolotu lub sali operacyjnej ma wiele osób, z dużym wykształceniem i doświadczeniem między nimi. Jednak nadal coś idzie nie tak - kroki są wykonywane poza kolejnością, coś jest zapomniane, coś jest robione niepoprawnie. Widziałem witrynę z wieloma źródłami, że dużej liczbie (do 70%) wypadków lotniczych przypisanych do błędu pilota można było zapobiec za pomocą listy kontrolnej . Według naukowców w świecie medycznym można było zapobiec nawet 29% postępowań sądowych dotyczących nadużyć w Holandii przy użyciu listy kontrolnej. Chociaż ci ludzie zostali przeszkoleni i z perspektywy czasu prawdopodobnie z łatwością mogliby ustalić, co zrobili źle, wydarzyło się coś, co spowodowało ich upadek. Jeszcze go nie przeczytałem, ale Manifest listy kontrolnej powinien być odpowiedni. Jest napisany z zawodu lekarza, ale zalety wyświetlania listy kontrolnej lub schematu blokowego jako przypomnienia o tym, co należy zrobić, dotyczą każdego zawodu.

Tak więc pierwszym krokiem byłoby stworzenie listy rzeczy, które są częścią twojej definicji ukończenia i uczynienie go widocznym. Nie ma znaczenia, jak oczywiste jest to zadanie, jeśli musi być kompletne, aby historia mogła zostać uznana za ukończoną, musi znajdować się na tej liście. Lista musi być gdzieś widoczna dla zespołu. Pamiętaj, że nie musi to być nic wymyślnego ani formalnego - być może po prostu seria pytań, które każdy musi sobie zadać, zanim opowieść może zostać nazwana skończoną.

Krok drugi polega na podjęciu decyzji o tym, co znajduje się na liście kontrolnej dla Twojej definicji ukończenia. Wszystko, co musisz zrobić, aby wykonać zadanie, powinno być konkretne, jednoznaczne, akceptowalne i realistyczne. Musi także mieścić się w kontekście czasu na rozważenie ukończenia. Na przykład nie musisz uwzględniać „modyfikuj kod” lub „modyfikuj projekt” w definicji gotowego - jeśli nie trzeba zmieniać produktu roboczego, historia nie jest potrzebna.

Podejrzewam, że dobra lista kontrolna, która posłuży jako podstawa do definicji zrobionego, to:

• Czy wszystkie powiązane testy jednostkowe, integracyjne, systemowe i akceptacyjne zostały zaktualizowane?
• Czy produkt roboczy został przekształcony w uwalnialną formę? Na przykład zbudowany kod, dokumentacja w formacie pliku do eksportu itp.
• Czy wszystkie powiązane produkty pracy zostały przejrzane? Przykłady produktów roboczych obejmują kod źródłowy (produkcja i test), komentarze, dokumenty projektowe, procedury testowe i podręczniki użytkownika.
• Czy wszystkie powiązane testy (na wszystkich poziomach testów) zostały wykonane i przeszły pomyślnie?
• Czy kod został scalony z repozytorium integracji?

Oczywiście musisz wymyślić dobrą definicję wykonania, która obejmuje wszelkie inne działania, które Twój zespół i klient uważają za wartość dodaną. Jeśli znajduje się na liście kontrolnej, powinno to być coś, co należy zrobić, aby dodać wartość komuś (zespołowi, klientowi, użytkownikowi). Przez wyraźne wyliczenie tego, co robisz, możesz także zidentyfikować i wyeliminować zewnętrzne działania w celu usprawnienia procesu.

To właściwie brzmi, jakbyś był szczęściarzem:

W naszym zespole mamy podobną listę, ale nikt nigdy na nią nie patrzy, ponieważ te punkty wydają się tak rażąco oczywiste

Twój zespół jest już „dojrzały” ;-). Ale zawsze jest miejsce na ulepszenia!

Na twoje pytanie:

Jakie są zatem przykłady mocnych definicji zrobionych przez dojrzały zespół? Jakie punkty zawierają zazwyczaj?

Na górze listy możesz dodać:

Różne wskaźniki jakości kodu: - niestabilność, abstrakcja - LOC vs DLOC (udokumentowane) - itp ...

Ogólna zasada może oznaczać, że wskaźnik nie powinien się pogarszać wraz z zatwierdzeniem. Ponadto możesz sformułować „gotowe: z doskonałością”, jeśli ktoś rzeczywiście ulepszy wskaźniki. Chociaż to (wskaźniki stają się coraz lepsze) zwykle nie jest częścią faz rozwoju (nowe funkcje), ale fazami refaktoryzacji.

W jednej z moich wcześniejszych firm mieliśmy definicję „zrobione”, która mówiła, że ​​Twoje wskaźniki muszą pozostać poniżej pewnych progów, jeśli przekroczysz ten poziom, jeszcze nie skończyłeś. (Cyklomatyczna złożoność nigdy nie powinna przekraczać 15, chyba że masz bardzo, bardzo dobrą wymówkę, na przykład skomplikowane cielęta).

To samo dotyczy naruszeń typu Checkstyle, szczególnie jeśli masz niestandardowy zestaw reguł, aby sprawdzić styl kodu swoich zespołów. Jeśli naruszasz standard kodowania, jeszcze tego nie zrobiłeś.

Wtedy nie tylko możesz wykonać UnitTest, możesz zmierzyć pokrycie kodu. Jeśli nie obejmuje to co najmniej 50%, nie jesteś gotowy. Chociaż jest to rodzaj błędnej definicji zrobionej, ponieważ powinieneś mieć testy dla podstawowych / głównych / krytycznych metod, i niekoniecznie dla 100% twojej bazy kodu.

O tak ... a jeśli masz (powinieneś) serwer CI z automatyczną integracją gałęzi ... zrobisz to tylko wtedy, gdy zatwierdzenie w Oddziale DEV połączy się z bieżącym Oddziałem LIVE i nie spowoduje również błędów. (Testy jednostkowe itp.)

hmmm ... to wszystko, co pamiętam, dobrze wiem z poprzednich firm / projektów, o których nie wspomniano na twojej liście.

Mam nadzieję, że to dało ci kilka pomysłów ;-)

Twoje zdrowie,

anann

W środowisku TDD / BDD definicja „zrobione” (technicznie „Kod zakończony”, ponieważ definicja „naprawdę” wykonana przez Matta S jest poprawna) jest dość prosta:

• Wszystkie zautomatyzowane testy przeszły pomyślnie (te zautomatyzowane testy powinny obejmować nowe napisane dla danej historii, aby sprawdzić, czy wymagana funkcjonalność lub zachowanie istnieje i działa)
• Przegląd kodu przeszedł pomyślnie (co najmniej jeden starszy programista w zespole jest zadowolony z tego, że Twoja praca może stać się częścią bazy kodu i że nie „oszukiwałeś” ani „nie rąbałeś” swojej historii)
• Zatwierdzenie zakończyło się sukcesem (w tym bota kompilacji, który przeszedł wszystkie automatyczne testy, wskaźniki pokrycia kodu, kontrole stylu itp.

W tym momencie możesz przejść dalej. Te trzy punkty są krytyczne, ale to wszystko, czym musi zajmować się przeciętny programista zespołu. Pisemne lub niepisane są nienaruszalne w środowisku TDD. Dokumentacja, gdy koderzy wykonują dokumentację, stanowi dodatkowy punkt. W moim ostatnim zespole Agile dokumentacją zajmowały się BA / QA; wiedzieli, czego chce klient, uruchomili UAT, a zatem mogli najlepiej udokumentować nową funkcję w sposób znaczący dla klienta, więc dokumentacja nie była częścią definicji „zrobionej” kodera, chociaż była częścią definicji zespołu.