Jestem programistą pracującym nad nową aplikacją mobilną na Androida i iOS z dużym komponentem zaplecza. Byliśmy w trzech sprintach tego projektu i używamy Scruma podczas wszystkich jego ceremonii (udoskonalanie, planowanie, dzienniki, retrospektywy itp.).

Podczas dwóch sprintów zespół musiał pracować (nieodpłatnie) w godzinach nadliczbowych i weekendach, ponieważ kierownictwo było bardzo zaniepokojone, że nie dotrzymamy zobowiązania do sprintu na czas. Wszyscy ciężko pracowali, ale niektóre zewnętrzne zależności i optymistyczne szacunki sprawiły, że mieliśmy trudności z ukończeniem wszystkich historii sprintu.

Z mojego doświadczenia wynika, że ​​niewielki odsetek historii, które nie zostały ukończone podczas niektórych sprintów, jest nieco normalny i można je rozwiązać w następnej. Ale nasz kierownik projektu mówi, że to nasza wina, ponieważ sami dokonaliśmy oceny, więc powinniśmy ukończyć wszystkie elementy w sprincie.

1. Czy to akceptowalna / powszechna odmiana Scrum, o której nie wiem?

2. Jak sugerujesz, żebym działał w tej sprawie?

Kilka rzeczy mnie wyróżnia.

Pomysł, jaki ma kierownictwo, że zespół angażuje się w zbiór prac, jest niezgodny z najnowszymi wersjami Przewodnika Scrum. Słowo „zatwierdzenie” lub „zobowiązanie” jest używane tylko dwa razy w najnowszej wersji Przewodnika Scrum (listopad 2017 r.) - raz przy wymienianiu Wartości Scrum i raz, aby wskazać, że „ludzie osobiście zobowiązują się do osiągnięcia celów Zespołu Scrumowego „.

Idea celów jest ważna dla Scruma. Organizacje i zespoły mają nie tylko ogólne cele, ale w Scrumie każdy Sprint ma Cel Sprint zdefiniowany w Sprint Planning jako współpraca między właścicielem produktu a zespołem programistycznym. Cel sprintu jest realizowany poprzez wdrożenie elementów z rejestru produktu, ale nie jest to po prostu „ukończenie tej pracy” i często nie reprezentuje pełnego rejestru sprintu. Oznacza to, że powinieneś być w stanie osiągnąć cel sprintu bez ukończenia każdego elementu Backlogu Produktu wybranego dla Sprinta lub każdego elementu w Backlogu Sprintu. Moje obecne myślenie jest takie, że praca potrzebna do osiągnięcia celu sprintu powinna wynosić około 60-70% pojemności twojego zespołu, jednak to ty bierzesz pod uwagę pojemność. Różne organizacje będą jednak różne, ale to „

Praca w godzinach nadliczbowych i weekendach jest również praktyką przeciwdziałającą zwinnemu programowaniu. Jedną z podstawowych zasad jest to, że wszystkie zainteresowane strony są w stanie pracować w zrównoważonym tempie. Długie dni i weekendy, nawet jeśli zostały opłacone, nie są w stanie utrzymać zespołu.

W tym momencie jest kilka kolejnych kroków. Zespół Scrum Master powinien edukować kierownictwo w zakresie wartości i zasad Scrum i Agile Software Development (takich jak „zaangażowanie” i „zrównoważone tempo”). Zespół powinien pracować nad swoją zdolnością do prognozowania pracy i negocjować zakres z właścicielem produktu. Zespół powinien również zidentyfikować i pracować nad rozwiązaniem lub zapobieganiem przeszkodom, które doprowadziły do ​​tej sytuacji (wyeliminowanie lub ograniczenie wpływu zależności zewnętrznych).

Opisana przez Ciebie sytuacja, w której kierownictwo wymaga, aby zespół pracował w nadgodzinach, aby ukończyć wszystkie zaplanowane historie, jest jednym z powodów, dla których literatura Scrum przestała używać terminu „zobowiązanie”. Prawdziwe zobowiązanie można dać tylko wtedy, gdy wyeliminowana zostanie wszelka niepewność, w tym niepewność co do zależności osób trzecich, ile pracy zajmuje każdy element, ile czasu każdy będzie dostępny biorąc pod uwagę chorobę itp.

Jedną z podstawowych idei Scrum jest to, że zespół pracuje w zrównoważonym tempie, co zasadniczo oznacza normalne godziny pracy bez nadgodzin (płatne lub nieodpłatne). To bezpośrednio oznacza, że nie występuje akceptowalna odmiana Scruma.

Co możesz z tym zrobić, zależy od twojej roli.

Jeśli jesteś programistą, najlepsze, co możesz zrobić, to

• (wspólnie jako zespół programistów) odmawiają „angażowania się” w więcej pracy, niż jesteś absolutnie pewien, że możesz wykonać w trakcie sprintu. Prawdopodobnie będzie to znacznie mniej niż to, co kierownictwo chce, abyś zrobił.
• skupiaj się na zakończeniu pracy, a nie na nowych zadaniach. Jeśli zauważysz, że niektórych prac nie można ukończyć, zaznacz to jak najwcześniej, aby umożliwić dostosowanie planów.

Jeśli jesteś mistrzem Scrum, możesz naprawdę udowodnić swoją wartość, kształcąc kierownictwo na temat Scrum. Niektóre punkty, które mnie wyróżniają:

• Jak stwierdzono w akapicie pierwszym, zespół nie zobowiązuje się podczas planowania sprintu, ale podaje prognozę prac, których wykonania oczekuje się zakończyć.
• Chociaż zespół powinien unikać niedokończonej pracy pod koniec sprintu, sytuacja ta jest prawie nieunikniona na początku projektu (lub po zmianie składu zespołu). Ile pracy zespół może realistycznie wykonać podczas sprintu, można ustalić wyłącznie na podstawie historycznych danych z kilku ostatnich sprintów zespołu w tym składzie. Na początku projektu takie historyczne postacie po prostu nie istnieją, więc zespół osiągający w pierwszych 3 sprintach dokładnie to, co zaplanowano dla każdego sprintu, jest bardziej wypadkiem niż dobrym planowaniem. Po około 5 sprintach w zrównoważonym tempie jest wystarczająca ilość danych, aby uzyskać rozsądny pomysł, ile pracy zespół może realistycznie wykonać w ramach sprintu.

Twój premier nie ma nic wspólnego z twoim scrumem.

Twój premier nie ma interesu w proszeniu o nieodpłatne nadgodziny.

Oczywistą rzeczą jest oszacowanie wszystkich zadań w taki sposób, aby zagwarantować, że zostaną one wykonane na czas. Następnie powinieneś być w stanie pójść do pubu w drugi sposób, ponieważ oczywiście, jeśli niedocenianie zadania oznacza, że ​​kończysz je za darmo, to przeszacowanie oznacza, że ​​masz czas bez pracy.

Jest w tym wiele aspektów, ale na wysokim poziomie tak - premier będzie absolutnie chciał jasno zrozumieć, dlaczego planowane prace nie zostały zakończone. Jednak powinno to zostać poruszone (i rozwiązane) w retrospekcji. Od strony deweloperów istnieje wiele czynników, które mogą przyczynić się do niepowodzenia w sprincie.

Niektóre rzeczy, które warto rozważyć:

Za dużo w sprincie

Jeśli regularnie angażujesz się w zbyt dużo pracy, sprinty się nie powiodą. Prędkość sprintu należy śledzić w czasie, aby dowiedzieć się, jaka jest optymalna liczba punktów (lub dni).

Alokacja zasobów

Upewnij się, że planowanie sprintu odpowiednio uwzględnia działania niezwiązane z rozwojem, takie jak ceremonie, wakacje, szkolenia, administracja, wsparcie i inne projekty itp. Automatyczne zakładanie, że wszyscy rozwijają się z każdą minutą każdej godziny, gdy są fizycznie w biurze, jest po prostu niepraktyczne i natychmiast postaw cię na tylnej stopie od samego początku.

Oszacuj zmienność

Robisz wyrafinowanie, ale czy są jakieś zadania, które zawsze się przekraczają? Często są to spowodowane brakującymi lub niejasnymi wymogami. Jeśli wymagania są wełniste, historia nie powinna nawet przejść do sprintu, chyba że zostanie odpowiednio udoskonalona lub zaplanowano skok.

Prędkość

Jeśli prędkość jest właściwie śledzona, prawdziwa liczba opowieści powinna być wyraźna. Nie oznacza to, że zawsze będą wykonywane na czas, ale powinno to znacznie ułatwić sprawę.

Życzliwość

W każdym projekcie dobra wola jest ograniczona. Jeśli ciągle pracujesz nad godzinami, aby dostarczyć, morale ucierpi, a deweloperzy wypalą się - jest to błąd zarządzania projektem . Jak już wspomniałem, upewnij się, że planowanie sprintu planuje tylko realistyczną liczbę historii przy użyciu prędkości i skoków, które pomogą ci po drodze.

Kolce

Jeśli przedmiot jest źle dopracowany lub po prostu wełniany, nie bój się postawić kolca, aby lepiej oszacować późniejsze sprinty. Tak, niektórzy ludzie są po prostu źle oszacowani, ale przez większość czasu, pełne fakty po prostu nie są w tym czasie znane. Najlepiej byłoby, gdyby to było ujęte w udoskonaleniu lub odebrane wcześnie przez PO, ale czasami mogą prześlizgnąć się do sprintu. Deweloperzy powinni odpierać te trudne kroki, ponieważ mogą łatwo zepsuć sprint, który w przeciwnym razie przebiega dobrze.

Nie, to nie jest rozpoznawalna forma Agile , z jednego bardzo ważnego powodu: jeśli zobowiązujesz się do dostarczania wszystkiego , nie robisz Agile, robisz Wodospad - i jeśli myślisz, że robisz Agile , prawdopodobnie źle sobie radzisz z Wodospadem . Jestem pewien, że słyszałeś starą piłę „dobrze, szybko, tanio, wybierz dowolne dwa”, prawda? Wraz z rozwojem oprogramowania jest to bardziej jak „wszystkie funkcje dostarczone na czas, w ramach budżetu, wybierz pierwszą lub dwie pozostałe”. Waterfall wybiera pierwszą, a Agile drugą.

Jeśli chcesz być zwinny , potrzebujesz elastyczności, aby usuwać Historie z Sprintu, których nie możesz ukończyć na czas. Jednym z możliwych sposobów jest poproszenie właściciela produktu o ocenę historii przy użyciu priorytetów MoSCoW. Oznaczałoby to wybranie nie więcej niż 60% opowieści (według łącznej liczby punktów opowieści) jako Must Haves, które zostaną ukończone, 20% jak Haves, które powinieneś ukończyć w ramach projektu, a minimalny dostępny produkt zostanie wydany, 20% jako Czy Haves może zostać ukończony, jeśli masz czas, i cokolwiek poza zakresem obecnej wersji jako Won't Haves. Ważne jest również, aby pamiętać, że po połączeniu Must Haves powinny mieć wystarczającą ilość mięsa do kości, aby stworzyć minimalny żywotny produkt bez konieczności dołączania żadnych przedmiotów z innych kategorii.

Ustalenie, czy upuścić elementy z rejestru sprintu jest obowiązkiem właściciela produktu, po tym, jak zespół poprosi o to, a wszelkie przedmioty, które zostaną upuszczone z rejestru sprintu, zostaną ocenione przez właściciela produktu, a następnie są albo zostało całkowicie usunięte z projektu lub umieszczone w Backlogu Projektu na odpowiednio uszeregowanej pozycji.

W takim przypadku zgaduję, że Twój Właściciel produktu jest Twoim Project Managerem, prawda? Jego zadaniem będzie ustalenie, które zadania należy porzucić, więc z pewnością nie powinien winić cię za nadmierne zaangażowanie, ponieważ jego zadaniem byłoby porzucenie zadań, aby to zrekompensować, i wygląda na to, że tego nie robi.

Ma rację, że między sprintami nie powinno być żadnych przeniesień. Zespoły Scrumowe mające przeniesienie między sprintami to anty-wzór, a nie coś, co kanoniczny Scrum akceptuje jako ważny wynik.

Ale jego podejście nie jest dobre.

Podczas sprintu zespół powinien stale monitorować wykonywane prace i czy mogą kontynuować swoje zaangażowanie w planowanie sprintu dotyczące ukończenia wybranych historii. Jeśli drużyna stwierdzi, że nie jest w stanie ukończyć wszystkich historii, powinna spotkać się z PO i wybrać historię do usunięcia ze sprintu. W ten sposób wszyscy ZATRZYMUJĄ SIĘ PRACĄ NA HISTORII i skupiają się na wykonaniu pozostałych historii. Pamiętaj: zawsze lepiej jest ukończyć jedną historię w pełni, niż mieć dwie historie w połowie ukończone.

Problemy zewnętrznych zależności i nieprecyzyjnego oszacowania są dokładnie tym, dlaczego istnieją Retrospektywy. Podczas Retro zespół powinien zastanowić się i zidentyfikować te problemy. Zespół powinien następnie znaleźć i wdrożyć rozwiązania tych problemów. Szacunki mogą być dokładniejsze dzięki lepszej znajomości systemu i prostemu doświadczeniu. Zależności zewnętrzne są trudniejsze, ale nie niemożliwe do naprawienia.

Twój PM ( co w ogóle robi PM w zespole Scrum? ) Nie powinien pozwolić Scrum Master na zmuszanie cię do ukończenia wszystkich historii. Zamiast tego, jeśli narzeka, powinien zatrzymać je na retrospekcję. Co więcej, powinno być częścią rozwiązywania problemów, które uniemożliwiały ukończenie opowieści na czas.

Czy to akceptowalna / powszechna odmiana Scrum, o której nie wiem?

Nie . To całkowicie źle. Mogłabym być może poprzeć płatne godziny nadliczbowe, jeśli OP popełnił błąd, podając szacunki jako fakty przed końcem sprintu, ale nieopłacone godziny nadliczbowe są całkowicie absurdalne i sprawiłyby, żebym szukał innej pracy jak najszybciej.

Jak sugerujesz, żebym postąpił w tej sprawie?

Z mojego doświadczenia wynika, że ​​ludzie, którzy są aż tak szynowi, nie będą słuchać logicznych argumentów. Jedynym sposobem, aby przekonali się, jak bardzo jest uszkodzony, jest pokaz , a nie opowiedzenie. Więc następnym razem, gdy oszacujesz i zatwierdzisz, dokonaj najmniejszej możliwej kwoty . Zobowiązaj się do ukończenia małego biletu przed końcem sprintu. Można to zrobić w ciągu jednego dnia. Zobacz, jak reaguje Twój PM. Następnie rozpocznij dyskusję od tego, do czego służy system i do czego system powinien być używany.

Ogólnie rzecz biorąc, na początku projektu, kiedy decydujemy o prędkości zespołu, wybieramy konserwatywną (niższą niż zwykle) liczbę, biorąc pod uwagę fakt, że jest to nowy zespół, zajęłoby mu to trochę czasu , rozumiemy się wzajemnie, rozumiemy wymagania funkcjonalne i NFR itp. Zasadniczo po kilku pierwszych sprintach optymalizujemy prędkość zespołu i oczywiście prędkość poprawi się tylko od tego momentu.

Nie ma sensu zwiększanie prędkości na początku i rozciąganie zespołu, aby to osiągnąć.

Jeszcze jedną rzeczą jest to, że w jednorazowym scenariuszu, w którym istnieje zobowiązanie do dostarczenia, którego nie można przeoczyć, menedżerowie projektów mogą wywierać presję na zespół, aby rozciągał się, pracował do późna i pracował w weekendy. Ale to należy uznać za wyjątek, a nie normę działania. Takie działanie może zwiększyć prędkość w krótkim okresie, ale w dłuższej perspektywie przyniesie efekt przeciwny do zamierzonego, ponieważ może to spowodować problemy z jakością kodu, problemy z wypaleniem zespołu, niezadowolony zespół o niskiej motywacji itp.

FAQ dotyczące zobowiązań

Czy to zachowanie jest normalne?

Nie jestem pewny.

Czy to zaskakujące

Nie. Niektórzy ludzie zawsze rozumieją „zobowiązanie”, co oznacza, że ​​wszystko w zobowiązaniu musi zostać wypełnione.

Czy to dobry pomysł?

Nie. Zwinne projektowanie ma zrównoważony rozwój jako główny temat: Pracuj tylko tyle / długo / ciężko, ile możesz zrobić w nieskończoność. W większości przypadków jest to rozsądny pomysł. (Jeśli kierownictwo tego nie zaakceptuje, nie powinno nazywać swojej organizacji sprawną).

Co powinniśmy zrobić?

• Wyjaśnij, że zawartość sprintu jest oparta na oszacowaniu . „Oszacowanie” oznacza, że ​​tylko czasami będzie poprawne - i zwykle błędne. Kiedy jest źle, czasami jest za niska, a czasem za wysoka.
• Wyjaśnij, że o wiele łatwiej jest zmienić zachowanie szacunkowe niż prędkość pracy.
• Wyjaśnij, że gdy zespół zostanie ukarany za zbyt wysoką ocenę, po prostu oszacuje niższą wartość, a kierownictwo straci w ten sposób znacznie więcej postępów, niż od czasu do czasu przesuwając część treści z jednego sprintu na drugi.

Zaletą jest: Twój kierownik projektu będzie już wiedział te wszystkie rzeczy i uzna je za słuszne. Tylko w krótkim okresie można je zignorować.

Nie zgadzam się z twoim zespołem zarządzającym. Nie powinni byli zmuszać cię do nadgodzin do ukończenia sprintu.

Jednak pomysł, że zobowiązania nie są możliwe, wynika z nieporozumienia dotyczącego rozwoju oprogramowania. Widziałem wiele zespołów próbujących przewidzieć historie, które mogą ukończyć w sprincie na podstawie liczby punktów historii, które ukończyły w poprzednich sprintach. Gdyby to było możliwe, oznaczałoby to, że tworzenie oprogramowania jest liniowe, tzn. Jeśli pracuję dwie godziny, robię dwa razy więcej niż w ciągu godziny.

Tworzenie oprogramowania jest kreatywne, a zatem nie liniowe. Lepiej jest, aby zespół powiedział zarządowi, co może zrobić w sprincie, a następnie opowiedział te historie. Jeśli konsekwentnie nie wywiązujesz się ze swoich zobowiązań, albo nie masz pojęcia o zakresie historii na początku, albo jesteś zmuszony przez właściciela produktu, by przejął więcej.

W pierwszym przypadku musisz upewnić się, że rozumiesz zakres historii, zanim zgodzisz się na jej wzięcie. Jeśli tak jest, masz problem kulturowy i niewiele można zrobić.