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

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?

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.

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.

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.

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ń.

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.

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.

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ąć.