Jak możemy skrócić czas przestoju po zakończeniu iteracji?


56

Tam, gdzie pracuję, ćwiczymy zwinnie kierowane scrumem z 3-tygodniowymi iteracjami. Tak, byłoby miło, gdyby iteracje były krótsze, ale zmiana nie jest w tej chwili opcją.

Pod koniec iteracji zwykle stwierdzam, że ostatni dzień biegnie bardzo powoli. Rzeczywista praca została już ukończona i zaakceptowana. Odbyło się kilka spotkań (retrospektywa i kolejne planowanie iteracji), ale poza tym niewiele się dzieje.

Jakich technik możemy użyć jako zespół, aby utrzymać tempo przez ostatni dzień? Czy powinniśmy usuwać wady? Zresztą i tak zaczynasz pracę nad kolejną iteracją? Coś innego?


3
Głosuję za wczesnym rozpoczęciem. Właśnie to robimy.
Job

14
Głosuję za wcześniejszym powrotem do domu. Tak bym zrobił.
kirk.burleson

@Kirk 11 rano może być trochę za wcześnie. ;)
Adam Lear

Jeśli retrospekcja zajmie tylko półtorej godziny ((11–8 rano) / 2 spotkania), być może powinieneś sprawić, by była bardziej zabawna. :)
bzlm

Odpowiedzi:


68

Ostatnio zmagam się z tym samym pytaniem. Zaczynamy od następnej iteracji, ale czuję, że to usuwa satysfakcję z dobrze wykonanej iteracji.

Zastanawiam się nad opcją pozostawienia go programistom, z zastrzeżeniem „o ile intencją jest przyniesienie korzyści firmie”.

Przykłady:

  • Spędź dzień, ucząc się czegoś
  • Wydaj go na projekt czasu innowacji
  • Poświęć na uporządkowanie tego irytującego fragmentu kodu, którego nigdy nie ominiesz
  • Dobrze przejrzyj aplikację pod kątem UX (co nigdy nie wydaje się, że możemy zrobić inaczej)

Cokolwiek motywuje programistę, stanowi dla niego zachętę do terminowego wydania wersji.


14
Podoba mi się twój pierwszy pocisk „Spędź dzień na uczeniu się czegoś” na dłuższą metę, to może przynieść OGROMNE korzyści nie tylko deweloperowi, ale także firmie.
Unkwntech

1
Aby uzyskać ciekawe podejście do swoich przykładów, dni fedex ( blogs.atlassian.com/rebelutionary/archives/000495.html ) są bardzo interesującym pomysłem. Zbuduj, co chcesz, ale dostarcz go w ciągu 24 godzin.
Steven Evers

Uczenie się nowych rzeczy może być ogromnym wzrostem morale. Upewnij się tylko, że znajduje się w sferze nieco związanej z działalnością firmy
Rudolf Olah,

22

Wziąć dzień wolnego. Wykonałeś pracę, którą miałeś wykonać, więc dlaczego nadal pracujesz?

Jeśli zmiana procesu była możliwa, rozważ pomijanie iteracji, ciągłe publikowanie i po prostu wyciągaj historie z zaległości. Ale czy nie zasługujesz na trochę przestoju?


8
Ponieważ wierzcie mi, gdy sprinty wymagają późnej pracy - spóźnisz się :)
Spedge

14

Zauważyłem ten sam problem (czasem używamy 2-tygodniowych sprintów, co jeszcze bardziej go zaostrza). To, co staram się robić w tych dniach (dzień przeglądu sprintu i dzień planowania sprintu), to zaoszczędzić trochę pracy, o której wiem, że będę chciał ją wykonać, ale nie wymaga dużo planowania lub komunikacji intramowej, takich jak błędy o niskim priorytecie, polski, lub ulepszenia narzędzi. Czasami staje się to rzeczywiście pozytywne, ponieważ stwarza dobry czas na wykonanie ważnej, ale nie seksownej pracy, na którą w innym przypadku trudno byłoby znaleźć czas.


7

Nawet jeśli nasze historie użytkowników prawie zawsze kończą się pod koniec iteracji, zawsze mamy długą listę „miłych do zrobienia” na końcu, wraz z listą znanych błędów. Więc kiedy ludzie kończą swoje historie, zawsze jest wiele do zrobienia.

Myślę, że spotkanie retrospektywne jest królem, nawet jeśli w większości pojawiają się te same problemy, bardzo ważne jest, aby poświęcić trochę czasu na zastanowienie się, jak poszła iteracja, jak się uczyć, jeśli nie zdajesz sobie sprawy ze swoich błędów i rzeczy, które poszły dobrze.

Jeśli wszystkie błędy zostaną usunięte, zostanie zrobiona długa lista rzeczy do zrobienia, wraz z punktami akcji, myślę, że miło jest zebrać zespół przed dużym ekranem i spróbować bawić się oprogramowaniem, które został zbudowany wraz z niektórymi piwami. Nie jest bardzo produktywny, ale miło jest rozmawiać o tym, co zostało zaimplementowane i jak to działa.

Jeśli masz dni, to spróbuję znaleźć coś nowego do nauczenia się i spróbować się z tym bawić, być może będzie to kolejna wielka rzecz. Ale z drugiej strony, jeśli są dni, prawdopodobnie zaległa jest historia użytkownika


5

Nasze iteracje kończą się w czwartki, aby w piątek naprawić każdy problem z ostatniej chwili. Ale te piątki (co 2 tygodnie) pokrywają się z naszymi piątkowymi piwami, więc staramy się przyjmować to dość spokojnie. Napraw kilka drobnych błędów, poświęć trochę czasu na czytanie rzeczy (książek, StackExchange, blogów itp.) I zrelaksuj się przy piwie pod koniec dnia. W przeciwnym razie nie osiągniesz poczucia ukończenia lub zamknięcia, a zamiast tego poczujesz się jak chomik obracający się bez przerwy w kole.


5

Nie jestem pewien, czy chcesz zawsze kończyć dokładnie na czas. Wykonanie pracy nieco wcześniej pozwala pomyśleć o przyszłych historiach, możliwościach i funkcjach. Daje ci to trochę przerwy po dobrze wykonanej pracy, która może być bardziej satysfakcjonująca niż wcześniejsze rozpoczęcie pracy lub zaangażowanie się w więcej opowieści i zawsze przenoszenie pracy.

Ken Schwaber stwierdza na swoim blogu http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

„Boże, pomóż nam. Ludzie znaleźli sposoby na poluzowanie się w wodospadzie, odpoczynek i kreatywność. Dzięki Leanowi i Kanbanowi te kryjówki zostały usunięte. Mamy teraz progresywny marsz śmierci bez przerwy”.


2
Dokładnie. Wpis PO wydaje się być przeciwieństwem tego, czym powinien być. Mówi w zasadzie: „Jak możemy wykonać więcej pracy po tym, jak skończymy wcześnie?” zamiast mówić „Skończyliśmy wcześnie, zrelaksujmy się trochę”.
Wayne Molina

3

W moich projektach podczas planowania iteracji zawsze wybieramy dodatkowe zadania i oznaczamy je jako „zadania dodatkowe”, nad którymi pracujemy, jeśli wszystko w iteracji zostanie zakończone. Pragmatycznie, te „zadania dodatkowe” są na ogół nad tym, nad czym najpierw pracowałby w następnej iteracji, ale psychologicznie nazywanie ich „zadaniami dodatkowymi” działa o wiele lepiej, niż po prostu zawsze mając więcej zaplanowanej pracy, którą można wykonać.

W przypadku innych rzeczy, takich jak czas na naukę lub innowacje, po prostu pozwalamy każdemu programistowi poświęcić na ten dzień do tygodnia na normalne działanie. Może to być dowolny dzień tygodnia (tzn. Nie musi to być koniec każdego tygodnia).


Fajnie - jakkolwiek je nazwiesz, powinno być absolutnie jasne, że jest to dodatkowa praca podjęta. Nie ma nic bardziej demoralizującego niż sprint oznaczony jako nieudany, ponieważ obiecana praca nie została ukończona.
Robbie Dee,

2

Wszyscy programiści w moim zespole wykorzystują wolny czas pod koniec sprintu (pod warunkiem, że wszystkie zadania sprintu zostały zakończone) jako „czas Google”.

W tym miejscu każdy programista pracuje nad własnym pomysłem / projektem, o ile przynosi korzyść firmie. Zdecydowanie sugeruję wprowadzenie takiego systemu, który naprawdę podniósł poziom zadowolenia z pracy w naszym zespole.


2

Jeśli ciągle kończysz trzy dni wcześniej, sugeruje mi to, że nie planujesz wystarczającej ilości historii na sprint.

Jednym z celów scrum jest zwiększenie produktywności - nie zrobisz tego, jeśli strzelasz do każdego sprintu.

Aby rozwiązać ten problem, zaplanuj więcej historii niż byłeś. Przyzwyczaj się tylko do swojej poprzedniej prędkości, ale jeśli skończysz, te historie zaczną działać na dodatkowych. Jeśli wykonasz więcej, zwiększ swoją prędkość do następnego sprintu. Zawsze planuj trochę więcej, niż zobowiązujesz się, lub przynajmniej ustaw kilka historii w szeregu, na wszelki wypadek.


1

To jeden z powodów, dla których przeszliśmy na Kanban. Wszystkie zalety scrum bez konieczności zerwania z projektem.


0

Podoba mi się odpowiedź Todda na zrobienie sobie dnia wolnego, jednak powiedziałbym, że próbuję rano zaplanować sprint i retrospektywę i postawić sobie wyzwanie, aby zrobić to na czas na lunch, a następnie wziąć długi lunch jako zespół. Podczas lunchu zachęcaj do dyskusji na temat sprintu, aby uzyskać nieformalną retrospektywę za darmo.

Jeśli nie możesz wtedy oddać popołudnia (a mam na myśli to, że wracasz do domu wczesnym popołudniem, a nie wyznaczasz sobie własnych celów po południu), to rozwiąż problem techniczny, ponieważ jest to jedna rzecz, która bardziej przygnębia programistę niż cokolwiek innego (źródło : moja opinia) konieczności obejścia długu technicznego, gdy dokładnie wiedzą, jak go rozwiązać i ułatwić sobie życie.


0

Osobiście uważam, że retrospektywy nie są naprawdę warte spędzania czasu, zwykle istnieje kilka typowych powtarzających się tematów (słabe historie użytkowników, złe oszacowania itp.), A ty akceptujesz je jako obszary problemowe i idź dalej. Staramy się również radzić sobie z problemami w miarę ich pojawiania się, zamiast czekać na retrospektywę (co mieliśmy tendencję do zrobienia na wczesnych etapach przyjmowania Scruma).

Teraz zamiast mieć retrospekcję, każda para programistów wybiera wyjątkowy element z istniejącego backlogu i pracuje nad nim.

Utrzymujemy również bieżące zaległości w zadłużeniu technicznym, które działają jako elementy bonusowe do sprintu (jeśli firma nie jest gotowa na wdrożenie czegoś z zaległości przed czasem).

To już okazało się całkiem pozytywne, ponieważ wszystkie drobne przedmioty, które po prostu bulgoczą, podbijają każdego dnia sprintem.


Jak długo zajęło ci porzucenie typowych problemów retrospektywnych (złe historie, szacunki)? Czy nigdy nie przeprowadzasz retrospekcji, przenosząc całą dyskusję na mniejsze w trakcie całego sprintu?
cringe

-1

Weź udział w sesji poświęconej projektowaniu tablicy i podziel się pomysłami na temat wdrażania ciekawych historii dotyczących nadchodzącego sprintu. Zrób to po sesji planowania i oddziel od sesji, w których historie wciąż zawierały szczegóły i były oceniane na podstawie szacunkowych punktów lub rozmiaru koszulki. Zachowaj nieformalną sesję i zachęcaj do kreatywności.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.