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?
agile
development-process
scrum
Adam Lear
źródło
źródło
Odpowiedzi:
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:
Cokolwiek motywuje programistę, stanowi dla niego zachętę do terminowego wydania wersji.
źródło
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?
źródło
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.
źródło
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
źródło
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.
źródło
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”.
źródło
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).
źródło
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.
źródło
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.
źródło
To jeden z powodów, dla których przeszliśmy na Kanban. Wszystkie zalety scrum bez konieczności zerwania z projektem.
źródło
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.
źródło
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.
źródło
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.
źródło