Jak spokojny (lub nie) powinien być sprint?

Jakie powinno być podejście do robienia opowiadań przypisanych do sprintu? Oczywiście chcesz priorytetowo potraktować je podczas sprintu, ale dla mnie cała zwinność polega na dynamice: nie chcesz celowo zwlekać lub sprawić, że „ok” przegapisz ukończenie historii użytkowników w sprincie, ale na w tym samym czasie, gdy pojawiają się nieoczekiwane rzeczy, a te historie nie są ukończone i zostają zepchnięte do następnego sprintu, nie chcesz, abyś poczuł, że zrobiłeś coś złego. To nie powinno być przerażające lub negatywne doświadczenie, prawda?

Czy negatywne / przerażające doświadczenia są dopuszczalne w przypadku nieodebranych zobowiązań w zakresie sprintu? Czy programiści powinni ponosić odpowiedzialność za brakujące zobowiązania do sprintu, gdy pojawiają się nieoczekiwane zadania, którymi należy się zająć (np. Wsparcie produkcji)?

Powinieneś bezwzględnie dążyć do wykonania przedmiotów w trakcie sprintu.

Jedną z głównych zalet SCRUM jest to, że nadaje projektowi „bicia serca”.

Priorytetyzujesz, wybierasz przedmioty z listy, dostarczasz je, demonstrujesz, zastanawiasz się, jak poszli, a następnie robisz to ponownie w wiarygodnych cyklach.

Wszystkie planowanie, szacunki i ustalanie priorytetów oparte są na tej koncepcji. To, że możemy i przyznamy punkty X w sprincie, i z czasem możemy ustalić prędkość, z której będziemy mogli korzystać do lepszego planowania.

Jeśli jesteś zbyt swobodny w kwestii treści i zobowiązań swoich sprintów, SCRUM po prostu rozpada się i moim zdaniem tracisz wiele z korzyści.

Oczywiście prawdziwy świat czasami ma coś do powiedzenia na ten temat, ale powinien to być raczej wyjątek niż reguła ...

Kluczem jest to, że nie musi być odpowiedzialność wokół nie dostaję historie pełne.

Oznacza to, że powinien istnieć solidny powód, dla którego historia nie była kompletna, i że powód ten został uwzględniony w planie projektu na przyszłość, aby się nie powtórzył.

Ten powód musi być czymś więcej niż niejasnym „pojawieniem się rzeczy”.

Na przykład, jeśli historia nie była kompletna, ponieważ członek zespołu musiał pracować nad problemem związanym z produkcją, tę możliwość należy rozwiązać w przyszłych iteracjach - albo planując mniej godzin od tego członka zespołu, albo organizując inne relacje.

Gdyby tego powodu można było uniknąć z większą starannością lub ciężką pracą z góry, to tak, ta odpowiedzialność może być trochę bolesna. Mamy nadzieję, że ból polega na tym, że „Właśnie to musimy zrobić lepiej następnym razem”, a nie odmianie „Nie wykonujesz swojej pracy”.

To nie powinno być przerażające lub negatywne doświadczenie, prawda?

Jeśli zdarzy się to raz lub dwa, nie, nie powinno to być negatywne doświadczenie. Jeśli zdarza się to regularnie, masz problem. Zespół jest wtedy zawsze przeważający. Bądź lepszy w szacowaniu i pomyśl dwa razy o tym, co popełnisz podczas sprintu, ale nie denerwuj się.

Rozluźnione sprinty oznaczają, że miałeś zbyt małe zaangażowanie.

Niespełnione sprinty oznaczają, że miałeś nadmierne zaangażowanie.

Po prostu dostarczam to, co popełniam, i staram się poprawić swoje zaangażowanie. Tylko w szczególnych okolicznościach mógłbym przenieść historię na kolejny sprint. Wolę mieć niewielką presję każdego dnia niż piekło presji na krótko przed upływem terminów.

W oparciu o moje doświadczenie - jak wszystko inne w zwinnym, dostosowujemy się do systemu ciągłego sprzężenia zwrotnego, w tym oceny.

Można spóźnić się na termin pierwszego sprintu (początek projektu), ale NAUKAsz od tego, co poszło nie tak (niedoszacowanie, brak wiedzy o sile drużyny itp.). Następnie zbierasz informacje zwrotne i podajesz je do następnego sprintu, aby uzyskać lepszą ocenę.

Z mojego doświadczenia wynika, że ​​minęło 11 miesięcy w moim nowym zwinnym projekcie , rzadko kiedy teraz nie dotrzymujemy terminu, jeśli w ogóle go brakuje. Spóźniliśmy się jednak na termin pierwszego sprintu, ponieważ nie znaliśmy tempa i siły członków naszego zespołu.

Niektórzy twierdzą, że „przeznaczają” więcej czasu na pierwszy sprint, aby pokonać problem z pierwszym sprintem.

Ciekawie jest zobaczyć odpowiedzi / komentarze tutaj. Przy każdym zwinnym (typowym) projekcie, nad którym pracowałem, podstawową zaletą było rozłożenie presji terminu na wiele krótkich terminów zamiast marszu śmierci na koniec projektu. IMO, sprinty należy traktować poważnie. Wszelkie niedociągnięcia w dostarczonym terminie lub dostarczonej funkcjonalności należy postrzegać jako potencjalne problemy zarówno w zarządzaniu projektem, jak i rozwoju.

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ść. - Zasady Manifestu Zwinnego

Jeśli jest to przerażające lub negatywne doświadczenie i zdarza się cały czas, masz problem. Tworzenie oprogramowania powinno być zabawne. Nie negatywne ani przerażające.

Jednak jeśli zespół zobowiązuje się do ukończenia niektórych historii w sprincie i ciągle nie dostarcza, masz również problem. Ten problem prawie na pewno nie zostanie rozwiązany poprzez zwiększenie nacisku na zespół, aby ukończył opowiadania. Jeśli problem wynika z czynników zewnętrznych, należy nimi zarządzać. Jeśli zespół nadmiernie się angażuje, ScrumMaster może poprowadzić go w kierunku zmniejszenia liczby punktów fabularnych. Przyczyn może być wiele i każdy z nich może wymagać innego rozwiązania. Energiczny i zmotywowany zespół powinien mieć dużo motywacji, aby iść do przodu.

Idealnie, bez względu na problem, jest podnoszony podczas retrospekcji i naprawiany.

Zespół nie powinien być tak skomplikowany, aby dowiedzieć się, co mogą osiągnąć podczas stosunkowo krótkiego okresu sprintu, a następnie go zrealizować (okazjonalna historia, która zostaje popchnięta do następnego sprintu, jest OK, prędkość może się zmieniać, rzeczy się zmieniają itp. .). Jeśli po kilku sprintach nie da się tego zrobić dość płynnie, robisz coś złego.

To zależy od twojej osi czasu.

Czasami POTRZEBUJESZ wykonać wszystkie historie lub większość z nich. Podczas gdy Agile zapewnia pewną elastyczność, będziesz również musiał wykonać projekt, być może na napiętym harmonogramie. Tak więc, mając większość historyjek, pozwoli Ci to zrobić na czas.

Powiedziawszy to, pojawią się rzeczy, które nie pozwolą ci na ukończenie każdej historii, każdego sprintu.

Jeśli produkt znajduje się na osi czasu, a kluczowe historie są pomijane, może to spowodować spóźnienie produktu. Produkt spóźniony w niektórych przypadkach może zaszkodzić pozycji konkurencyjnej firmy. W takim przypadku możesz chcieć, aby brakowało historii, ponieważ może to być negatywne doświadczenie - może to sprawić, że zrobisz to następnym razem.

Przy prawidłowym dawkowaniu stres jest dobry. Nie chcesz usuwać stresu, po prostu chcesz rozłożyć go bardziej równomiernie w czasie. Nawet podczas gry w ulubioną grę odczujesz stres i negatywne uczucia. Dostajesz z tego więcej energii.

Zespół powinien naprawdę czuć się źle z powodu pominiętych historii. Daje im energię do zmiany czegoś następnym razem (pracuj inaczej lub planuj mniej historii, obie są dobre). Oczywiście powinni też czuć się dumni, kiedy tworzą swoje historie.

Wspominasz także o nieoczekiwanych zadaniach (wsparcie produkcji). To podnosi ze mną czerwoną flagę. Powinien być uzgodniony przedział czasowy na wszystkie kwestie niezwiązane z opowiadaniami. W przeciwnym razie gra nie jest sprawiedliwa, zespół czuje się bezradny, a negatywne uczucia nie są wykorzystywane do poprawy.

Powinieneś spojrzeć na czynniki, które powodują, że twoje zobowiązania się nie udają i spróbować je naprawić. Duża liczba przypadkowych zdarzeń będzie popsuć sprinty, dzięki czemu Twoja prędkość będzie nieprzewidywalna. Napraw przyczyny tego lub wprowadź luz w sprintach. Wolę naprawiać.

Tak czy inaczej, zespół nie może zostać pociągnięty do odpowiedzialności, jeśli ich praca zostanie zakłócona przez czynniki zewnętrzne. Skorzystaj z retrospekcji, aby to zbadać.