Jak zatrzymać / uniknąć z czasem w zespole Scrum?

Właściwie pomagam niewielkiemu sklepowi z oprogramowaniem w zakresie wdrażania Scrum. Niedawno Scrum Master poinformował mnie, że ma problem, ponieważ Zespół pracuje z czasem, aby osiągnąć Zakres (Zatwierdzone Zaległości). Więc mają Unreal Velocity .

Moje formalne pytania dotyczą:

1. Oprócz mówienia na spotkaniu retrospektywnym; czy uważasz, że to dobry pomysł, aby wdrożyć pewne twarde bloki, aby uniknąć z czasem?

2. Jeśli tak, jakie techniki / narzędzia proponujesz?

   • System kontroli wersji (SVN, GIT, HG itp.), Bloki według godzin (od 8 do 5)
   • Bloki stanowisk pracy według godzin (od 8 do 5) lub łącznych godzin (do 8 godzin / dzień)?
   • Inne (s) ...

3. A może nie blokuj tego rodzaju rzeczy; ale wdrożyć „System kar” za nieuzasadnione dodatkowe godziny ?

@Baqueta (i inni z podobnymi pytaniami): Nie, nie są płaceni za dodatkowe godziny. Moją pierwszą radą dla nich było przejrzenie ich szacunków, ponieważ być może nie docenili. To była moja ulubiona rada:

Jeśli są zainteresowani pracą w nadgodzinach, usuń ją. Rozwój nie jest czymś, co można zrobić przez 60 godzin w tygodniu i utrzymać produktywność, a istnieją liczne badania, które to potwierdzają. Jeśli problemem jest wynagrodzenie za godziny nadliczbowe, pozbądź się go i popraw swoje wynagrodzenie podstawowe, aby dostawały tyle, ile są warte.

Myślę też, że głównym problemem (dla tego zespołu) jest kombinacja następujących elementów:

1. Deweloperzy dowiadują się, co muszą osiągnąć podczas sprintu / nie są konsultowani, co jest osiągalne / są ignorowani, gdy mówią, że jest za dużo pracy.
2. Deweloperzy konsekwentnie nie doceniają czasu wykonania zadań / liczby jednostek pracy zaangażowanych w każde zadanie.

Podsumowanie: Porozmawiam z Zespołem w celu przeglądu ich szacunków oraz z PO, ponieważ uważam, że nie konsultowano ich w sprawie zakresu, jak wspomniałeś.

Szczerze mówiąc, te „twarde bloki”, o których wspomniałeś w punkcie 2, to najgorszy pomysł, jaki słyszałem od dłuższego czasu. Co się stanie, jeśli błąd o najwyższym priorytecie zostanie znaleziony o godzinie 16.45, a facet, który ma możliwość obejścia twoich bloków, jest chory? Co do nr 3 - sugerujesz karanie ludzi za wykonywanie pracy .

Jeśli zespół konsekwentnie pracuje w godzinach nadliczbowych, aby ukończyć sprinty, oznacza to, że jest zainteresowany pracą w godzinach nadliczbowych - np. Wynagrodzeniem za nadgodziny lub otrzymywaniem nadgodzin po wakacjach - lub zobowiązuje się do wykonywania zbyt dużej pracy w sprintach.

Jeśli są zainteresowani pracą w nadgodzinach, usuń ją . Rozwój nie jest czymś, co można zrobić przez 60 godzin w tygodniu i utrzymać produktywność, a istnieją liczne badania, które to potwierdzają. Jeśli problemem jest wynagrodzenie za godziny nadliczbowe, pozbądź się go i popraw swoje wynagrodzenie podstawowe, aby dostawały tyle, ile są warte.

Jeśli w sprintach jest za dużo pracy, dzieje się tak zwykle z jednego z trzech powodów:

1. Deweloperzy dowiadują się, co muszą osiągnąć podczas sprintu / nie są konsultowani, co jest osiągalne / są ignorowani, gdy mówią, że jest za dużo pracy.
2. Deweloperzy konsekwentnie nie doceniają czasu wykonania zadań / liczby jednostek pracy zaangażowanych w każde zadanie.
3. Programiści są ciągle wciągani w zadania, które nie są częścią scrum.

Jeśli to numer 1, robisz to źle . Nie ma na to dwóch sposobów!

Jeśli jest to numer 2, zwykle przyczyną jest brak doświadczenia - albo przy szacowaniu czasu, albo przy opracowywaniu systemu. Dobrym sposobem na obejście tego jest zaprzestanie szacowania czasu i rozpoczęcie szacowania „jednostek pracy”. Użyj jakiejś abstrakcyjnej jednostki, po prostu upewnij się, że nie są to godziny rzeczywiste (ostatecznie reprezentujesz przedział czasu, ale abstrakcja jest ważna!). Następnie możesz zacząć obliczać, ile jednostek pracy faktycznie wykonano w ciągu tygodnia, a następnie skonfigurować sprinty na podstawie tych danych.

Jeśli jest to numer 3, musisz jakoś zacząć uwzględniać te inne zadania. Jeśli jest spójne, powinno być łatwe do rozliczenia (patrz # 2 powyżej). Jeśli jest to częste, ale nieprzewidywalne, znacznie trudniej sobie z tym poradzić. Będziesz chciał dowiedzieć się, dlaczego tak się dzieje (np. Poważne błędy w kodzie „na żywo” => czy testowanie jest wystarczające?), Ale jeśli nie można tego naprawić, ostatecznie scrum może nie być dla ciebie odpowiednim podejściem. Mój zespół niedawno przeszedł na Kanban z tego właśnie powodu ...

Edycja: Wyjaśniłem moją krytykę pomysłów przedstawionych w pytaniu.

Przede wszystkim wygląda na to, że mieli zbyt dużo pracy na sprincie, jeśli musieli pracować w nadgodzinach, aby to zrobić. Czy wszystkie godziny są zalogowane? Jeśli tak, to możesz policzyć, ile rzeczywistej pracy stanowi punkt fabularny, i użyć tej liczby do obliczenia pracy do następnego sprintu.

Ważne jest również, aby upewnić się, że zespół rozumie, że szkodzi tylko sobie, biorąc zbyt dużo pracy. Nawet zwinny manifest mówi o zrównoważonym tempie: „Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność”. Praca w nadgodzinach przez cały czas nie jest zrównoważona.

Podsumowując, sugerowałbym komunikację zamiast siły i kar. Wyobrażam sobie, że doprowadziłoby to tylko do demoralizacji zespołu.

Twórcy pracujący w nadgodzinach prawdopodobnie reagują na jakąś zachętę, faktyczną lub postrzeganą. Chodzi o usunięcie zachęty, jeśli jest ona rzeczywista, lub poinformowanie, że postrzegana zachęta nie działa.

Każdy sugerowany twardy limit zawiera pewne obejścia lub inne problemy. Bloki kontroli źródła prowadziłyby po prostu do utrzymywania przez deweloperów ich zatwierdzeń, dopóki okno się nie otworzy. Bloki stacji roboczych musiałyby działać, gdy tylko pojawił się problem z obsługą lub jeden z deweloperów musiał z jakiegoś powodu przesunąć swoje godziny pracy. Systemy kar doprowadzą po prostu do ukrywania się lub chowania w nadgodzinach.

Myślę, że problem jest bardziej fundamentalny - zespół ma motywację (lub uważa, że ​​ma motywację) do pracy w godzinach nadliczbowych.

To właśnie należy rozwiązać. Czy ich oceny wyników są powiązane z ich liczbami prędkości? Czy zarząd pracuje w nadgodzinach? Czy promocje i nagrody są przyznawane osobom, które pracują przez wiele godzin? Czy są to kontrahenci, którzy otrzymują wynagrodzenie za nadgodziny?

Po prostu powiedz zespołowi, aby nie pracował w nadgodzinach. Kropka.

Może to spowodować, że nie będą w stanie dokończyć niektórych prac. To nie problem, to punkt danych. Następnie mogą wykorzystać ten punkt danych do planowania następnego sprintu. Ponownie, nie pozwól im pracować w nadgodzinach. Niezależnie od tego, czy kończą, czy nie, mają inny punkt danych. Spłucz, spłucz, powtórz.

Nie są wymagane żadne sztuczki ani limity. Po prostu nie pracuj w nadgodzinach. Dowiedz się, ile pracy możesz wykonać, i odpowiednio dostosuj swoje planowanie sprintu.

Może jest problem nie tyle, ile „pracują”, ale kiedy. Może to stanowić problem w przypadku zaplanowanego dnia pracy, ale większość normalnych godzin składa się ze spotkań i innych rozrywek społecznych i osobistych. Czy pracują w nadgodzinach, ponieważ po prostu czują się bardziej produktywni.

Zmniejsz ilość pracy podczas sprintu i rozpocznij pracę na czas elastyczny. Pozwól im przyjść później. Osoba odpowiedzialna musi po prostu powiedzieć ludziom, aby poszli do domu; w porządku. Istnieje kilka kultur korporacyjnych, które tworzą środowisko, w którym wczesne odejście może wywołać zmarszczenie brwi.

Walczyłem z tym, kiedy po raz pierwszy przeszedłem na scrum. Jest rzeczą naturalną, że chcemy włożyć dodatkowy wysiłek w terminie, ale scrum ma terminy co dwa tygodnie, więc jest to korekta. Oprócz sugestii innych osób, aby zmniejszyć liczbę punktów historii podczas każdej iteracji, sugerowałbym również, aby opowieści były wystarczająco podzielone, aby każdy programista mógł ukończyć co najmniej dwa lub trzy w jednej iteracji.

To nie tylko zapewnia, że ​​każdy programista czuje się, jakby osiągnął coś w każdej iteracji, ale także daje pewien luz w zakresie. Kiedy twój wypalenie pokazuje, że nie będziesz w stanie ukończyć historii, możesz ją wyciągnąć i przenieść ludzi do historii, które można ukończyć. Gdy ludzie zobaczą, że zakres można dostosować, rzadziej będą się stresować o nierealistycznych terminach. Jeśli zaczniesz iterację z każdą trwającą historią, nie będziesz mieć miejsca na zmiany.

Idealny skumulowany schemat przepływu powinien wyglądać mniej więcej tak, jeśli każdy kończy dwie historie na iterację:

Nigdy tak nie wygląda, ponieważ w rzeczywistości bardzo trudno jest ustalić czas, aby wszystkie historie zakończyły się ostatniego dnia, jednocześnie zajmując wszystkich, ale to dobra zasada. Jeśli jesteś nadmiernie zaangażowany, czerwony obszar będzie większy i będziesz mógł usuwać historie. Jeśli nie jesteś zaangażowany, niebieski obszar będzie większy i będziesz mógł dodawać historie. Jeśli twoje historie są zbyt duże, zielony obszar będzie większy i powinieneś podzielić historie.

Aby uniknąć nadgodzin, musisz ograniczyć zakres projektu.

Poniższa tabela pokazuje, gdzie niepewność leży w projekcie:

Jeśli zauważysz, na etapie definiowania produktu i wymagań, masz dużą rozbieżność w szacowaniu nakładu pracy. Nie możesz być pewien, czy wdrożenie zajmie miesiąc, czy dzień.

Założę się, że żadne z zadań nie zostało wykonane, ponieważ są po prostu zbyt duże i nieokreślone, a jest ich zbyt wiele.

Jeśli Twój zespół jest w stanie obsłużyć 10 biletów w ciągu 5 dni, a przydzielono im 20 biletów, zmniejsz ten numer, wykop go właścicielowi produktu / kierownikowi projektu / kierownikowi / klientowi i powiedz mu, aby ustalili priorytety.

W tym momencie jest to jedyny sposób na uratowanie zespołu przed nadgodzinami. Nie możesz dostarczyć wszystkiego, ale cokolwiek zrobisz, będzie mniej błędów.

Radziłbym również poszukać nowej pracy i pomóc kolegom z zespołu zrobić to samo oraz naprawić ich CV i profesjonalne portfolio. Firma, która spodziewa się nadgodzin, to taka, dla której nikt nie powinien pracować, a wyprodukowane oprogramowanie będzie paskudne.

Odradzam zdecydowanie „twarde bloki”. Takie kontrole mogą być postrzegane jako mikrozarządzanie i mogą nie uwzględniać podstawowej kwestii.

Sugeruję, aby dowiedzieć się, dlaczego programiści pracują w nadgodzinach. Odpowiedź może cię zaskoczyć. Wygląda na to, że jesteś „outsiderem” (a nie pracownikiem firmy), a programiści mogą być z tobą szczerzy, jeśli spotkasz się z nimi prywatnie (jeden na jednego).

Czy powód pracy w godzinach nadliczbowych jest naprawdę obciążeniem, czy może jest bardziej związany z kulturą lub oczekiwaniami?

Przyczyny obciążenia pracą mogą być

• Zatwierdzone zaległości są za duże
• Programiści lub właściciel produktu „pozłacają” (co sprawia, że ​​funkcje są bardziej złożone niż potrzeba)

Oczekiwania mogą być

• Jakaś nagroda finansowa lub nagroda za pracę w godzinach nadliczbowych
• Strach przed porażką. Programiści obawiają się, że będą źle wyglądać lub zostaną ukarani, jeśli nie dotrzymają terminu
• Programiści nie doceniają szkodliwych długoterminowych skutków pracy w nadgodzinach.