W Scrumie, jak radzić sobie z rywalizacją / obciążeniem na końcu sprintu

8

Mój zespół zaczął używać Scruma kilka sprintów temu. Nasz projekt obejmuje budowę oprogramowania współpracującego z urządzeniami fizycznymi (myślą o robotach i czujnikach), a nasze typowe zaległości produktowe zwykle stanowią dodanie urządzenia sterującego do całego systemu.

Tutaj podzieliliśmy zadanie blisko przykładu . Każda funkcja integracji urządzenia jest podzielona na kod, testy, testy integracyjne, wzajemną ocenę itp. Oczywiście istnieje pewna sekwencja związana z każdym elementem rejestru produktu. Zazwyczaj nasze sprinty trwają 2 tygodnie, a zespół liczy od 4 do 6 członków.

Na koniec sprintu napotykamy 2 problemy:

  • Pierwszy polega na tym, aby wszyscy byli zajęci pod koniec sprintu.
  • Drugim (powiązanym) jest rywalizacja o system. W ostatnich dniach sprintu prawie się integrujemy. Mamy tylko jeden system integracji, więc ludzie często nie mogą kontynuować pracy nad swoim zadaniem, ponieważ nie mają dostępu do systemu. Ponieważ jest to koniec sprintu, w zaległości sprintu nie pozostało wiele do zrobienia. Nad czym ci ludzie powinni pracować? Odbiór przedmiotów z górnej części rejestru produktów nie jest dobrze odbierany od właściciela produktu, ponieważ bieżące przedmioty nie są gotowe. Praca nad długiem technicznym pomoże projektowi jako całości, ale nie pomoże ukończyć sprintu.

Czy są jakieś najlepsze praktyki dotyczące strukturyzacji sprintu, aby uniknąć tych problemów? Wskazówki dotyczące negocjacji z właścicielami produktów?

Vincent Hubert
źródło
7
Przychodzi na myśl zwrot „Ciągła integracja” .
Robert Harvey
1
Ciągła integracja to wszystko, co robi system integracyjny, gdy integratorzy zintegrują na nim każde urządzenie. Niestety, dzięki naszej konfiguracji nie jest to tak proste, jak sprawdzenie kodu, potrzebujemy fizycznej konfiguracji połączeń z silnikami i kartami I / O, a co nie. Upewnienie się, że nowe urządzenie działa w środowisku CI, samo w sobie jest zadaniem, które powoduje konflikt. Co ciekawe, wzięcie wszystkiego na system CI i umieszczenie go na prawdziwej maszynie jest dość trywialnym procesem - udowadniającym, że CI jest tego wart.
Vincent Hubert
2
Dlaczego musisz czekać na rzeczywiste urządzenie integracyjne? Czy nie masz symulatorów (przynajmniej funkcjonalnych, jeśli nie całościowych), których można użyć do przeprowadzenia co najmniej podstawowego testu i integracji oprogramowania przed przejściem na sprzęt?
Thomas Owens

Odpowiedzi:

6

pod pewnymi względami dobrze jest, że jesteś pod koniec sprintu powolny, co oznacza, że ​​dobrze oceniasz i nie angażujesz się zbytnio w zespoły scrumowe, nad którymi pracowałem, zawsze dodawaliśmy zadania badawcze do tego, co będzie dalej sprint.

Może to być sprawdzanie koncepcji nadchodzących rzeczy lub sprawdzanie, gdzie ponownie uwzględnić istniejący kod, praca nad uzyskaniem lepszego pokrycia testowego kodu itp.

Bob The Janitor
źródło
2
Naprawianie błędów było kolejnym zadaniem, które utrzymywało nas pod koniec sprintu.
Sjoerd,
5

Powinieneś naprawić swój system integracji, aby twój zespół mógł zintegrować swoją pracę, jak tylko każde zadanie zostanie ukończone, zamiast czekać na wielki wybuch na koniec sprintu.

Polecam pracę z historiami użytkowników wystarczająco krótkimi, aby zakończyć je w ciągu kilku dni. Zakończone tutaj oznacza kod kompletny, przetestowany i zintegrowany.

Martin Wickman
źródło
2
W rzeczywistości integrację można przeprowadzić w systemie w dowolnym momencie. Problem polega na tym, że nie ma nic do zintegrowania, zanim zadania znajdą się na etapie integracji i większość z nich dociera do tego etapu pod koniec sprintu, stąd spór.
Vincent Hubert
1
Wydaje się, że moje zalecenie dotyczące skrócenia zadań pomogłoby tutaj, nie?
Martin Wickman,
4

Pamiętając, że jest to odpowiedzialność całego zespołu do wydania, a nie poszczególni członkowie, per se , jest to możliwe, aby wszystkie czterech do sześciu członków prace nad każdym razem zadanie - wcisnąć każdy przez proces i przejść do następnego. Na początku może się to wydawać nieefektywne, ale jeśli wąskie gardła, które widzisz, są tak złe, może to być poprawna opcja.

Możesz także przyjrzeć się teorii ograniczeń ( cel Goldratta ) i zobaczyć, jak najlepiej przeanalizować, dlaczego i gdzie masz te wąskie gardła integracji.

Matthew Flynn
źródło
3

Rozwiązaliśmy ten problem, przyjmując podejście Kanban.

W naszym oprogramowaniu śledzącym (Jira) mamy kolejki z minimalnymi i maksymalnymi wartościami.

Pielęgnujemy „w razie potrzeby”. Może być raz w tygodniu, może być 3 razy, zależy od limitów i pracy, którą należy wykonać.

Pomoże Ci to skoncentrować właściciela produktu na utrzymaniu kolejki z dużą ilością rzeczy do zrobienia i może zmniejszyć mikro-zarządzanie poszczególnymi biletami. Pamiętaj tylko, że jak zawsze zmiana zajmie trochę czasu.

Nadal demo co dwa tygodnie i wydajemy co tydzień.

Michael Durrant
źródło
2

Wow, jeśli nie powiedziałeś robotów, zakładałbym, że jesteś teraz w moim zespole. Mamy dokładnyten sam zestaw problemów. Po pracy nad wieloma zwinnymi projektami o różnym stopniu wierności manifestowi i różnym stopniu powodzenia, moja analiza jest taka, że ​​naszym problemem jest zbyt krótki sprint. Robimy dwutygodniowe sprinty, co powoduje kilka problemów. Po pierwsze, jesteśmy zbyt ostrożni w planowaniu i często kończymy martwymi dniami. Drugi to ogromny podsłuch przeglądu, retrospekcji i planowania, który zajmuje 1-2 dni z dwóch tygodni. Innym jest, jak powiedziałeś, konieczność integracji w ostatniej chwili i często nieskuteczne godziny przed recenzją. Mój pierwszy i odnoszący największe sukcesy projekt zwinny miał czterotygodniowe sprinty, które według mnie są dość duże jak na standardy branżowe, ale zadziałały doskonale dla nas.

EDYCJA: Pamiętam jeszcze jedną rzecz z pierwszego projektu, która była dobrodziejstwem. Zawsze mieliśmy w pełni zaległe zaległości produktowe i dawaliśmy programistom swobodę pobierania z nich zadań, jeśli ich zadania sprintu były kompletne i żadne inne zadania sprintu nie były dostępne.

nerwowy
źródło
„podsłuchanie recenzji, retrospekcji i planowania” - jeśli uważasz, że retrospekcja jest tak uciążliwa, nie musisz tego robić przy każdym sprincie. Planowanie powinno zależeć tylko od tego, co planujesz, więc nie powinno być mniej przy dłuższych sprintach.
sleske,
0

Drugi problem jest prawdopodobnie konsekwencją próby rozwiązania problemu bez problemu nr 1. Powinieneś pozyskać ludzi, którzy nie są zajęci, aby pomóc swoim rówieśnikom; zamiast pracować nad zadaniami niezwiązanymi z sprintem, które powodują rywalizację o ograniczoną integrację.

Nie powinieneś także integrować się na końcu sprintu, ale w sposób ciągły.

Bruno Guardia
źródło
0

Właśnie zaczynasz. Daj zespołom szansę samodzielnego rozwiązania tego problemu poprzez proces retrospektywny.

Po drugie, właściciel produktu powinien zaufać zespołowi, który najlepiej wie, jak się zorganizować i zoptymalizować. W zamian zespół ufa organizacji, która wie najlepiej, czego potrzebuje klient.

Są to bardzo częste wyzwania dla nowych zwinnych zespołów. Wspaniale jest zobaczyć, kiedy zespół zaczyna burzyć własne silosy i rosnąć.

Kris Van Bael
źródło