Czy Scrum może korzystać ze specyfikacji technicznych z Backlogu Produktu, a nie z historii użytkowników?

W firmie, dla której obecnie pracuję, rozpoczęliśmy realizację projektów Scrum. Nietrudno było przekonać menedżerów do przejścia z wodospadu do Scrum. Realizujemy projekt, w ramach którego odbudowujemy naszą platformę od podstaw. Tak więc (większość) funkcjonalność jest znana, a większość ulepszeń jest raczej technicznych.

W tym przypadku uzasadnione mogą być zadania techniczne, a nie historie użytkowników. Nasze zaległości obejmują różnego rodzaju zadania techniczne, takie jak:

• Przepisz klasę DB z MySQL do PostgreSQL.
• Wdrożenie logowania do systemu.
• Przepisz pamięć podręczną obiektów.

Do rzeczy, które pojawiają się podczas pojedynków, potrzebne są długie „zadania badawcze”, ale nigdy nie są one wykonywane. Ponadto członkowie zespołu twierdzą w środku sprintu, że należy dodać nieplanowane zadania.

Jak Scrum Master powinien sobie z tym poradzić? Czy to możliwe, że w przypadku tego rodzaju projektów Scrum NIE jest właściwą drogą?

TL; DR

Scrum nie nakazuje korzystania z historii użytkowników; są po prostu przydatną zwinną praktyką. Podczas gdy Właściciel produktu mógłby z pewnością wykorzystać specyfikacje techniczne zamiast historii użytkowników do zbudowania Backlogu Produktu, większość innych problemów związanych z procesem wynika z tego, że nie przyjęto skutecznych praktyk Scrum i zwinnych.

Różne problemy z procesem

Twój Scrum wydaje się być uszkodzony na wiele różnych sposobów, w tym:

1. W twoich specyfikacjach brakuje wyraźnego punktu widzenia lub propozycji wartości.
2. Twoje elementy zaległości nie są powiązane z celami sprintu.
3. W procesie przygotowywania zaległości brakuje całkowicie lub nie można utworzyć szczytów historii dla zaległości produktu.
4. Twój proces planowania sprintu nie rozkłada odpowiednio elementów rejestru produktu na elementy rejestru sprintu.
5. Twój zespół nieprawidłowo uwzględnia niepewność dotyczącą pozycji zaległości w swoich prognozach planowania sprintu.
6. Twój zespół nie przestrzega podstaw boksu czasowego ani integralności Sprint.

Chociaż Scrum nie zawsze jest odpowiedni dla każdego projektu, w tym przypadku bardziej trafne byłoby stwierdzenie, że Scrum nie działa, ponieważ zespół tak naprawdę nie robi Scruma. Twoje pytanie o historie użytkowników to tylko niewielka część większych problemów procesowych, przed którymi staje Twój zespół.

Dlaczego zwinni programiści wykorzystują historie użytkowników

Specyfikacje techniczne to zasadniczo zepsuty sposób komunikowania wymagań. Wymagania, które nie są zakotwiczone z punktu widzenia, nie dostarczają żadnych przydatnych wskazówek dla programistów. Korzystając z opublikowanych przykładów:

• Przepisz pamięć podręczną obiektów. Dlaczego? Jaki jest cel? Kto otrzymuje zasiłek? Kto może udzielić wyjaśnień na temat zadania? Jeśli wiąże się to z niefunkcjonalnym wymogiem, jaki cel projektu spełnia ten cel?
• Wdrożenie logowania do systemu. Dlaczego? Kto będzie czytał dzienniki? Jakie informacje muszą zawierać dzienniki? Skąd będziesz wiedzieć, czy format dziennika lub dane dziennika są przydatne?

Z perspektywy dewelopera niemożność odpowiedzi na tego rodzaju pytania prowadzi do dokładnie tego rodzaju problemów procesowych, które opisujesz. To właśnie robią historie użytkowników: zapewniają bardzo potrzebny kontekst i pełnią rolę elementów zastępczych dla dodatkowych rozmów z interesariuszami lub użytkownikami końcowymi na temat określonych funkcji.

Nie powinieneś używać historii użytkowników, ponieważ uważasz, że jest to wymóg ramowy lub ponieważ jest to powszechnie akceptowana zwinna praktyka. Zamiast tego powinieneś pracować nad ich efektywnym tworzeniem i używaniem, ponieważ ułatwia to programowanie zadań, a zawód programisty sprawia więcej radości. Twój przebieg może się oczywiście różnić.

Nie sądzę, że problemem jest Scrum jako taki, myślę, że problem polega na tym, że nie ma jasno określonego rezultatu projektu i (doświadczyłem tego wiele razy) nie ma jasnego kierunku.

Myślę, że twoje zadania techniczne są w porządku, być może z dużej strony, ale mierzalne i możliwe do zdefiniowania, więc absolutnie w porządku dla historii.

Zadania badawcze są dla mnie ogromną czerwoną flagą w Scrumie, ponieważ przynoszą one niewiele widocznych korzyści i mogą spowodować ogromny wzrost zasięgu. Opowiadam się za ograniczeniem tych z góry w sprincie, nie należy ich dodawać, a na pewno nie należy ich dodawać kosztem oddanych celów. Jeśli są one potrzebne do wykonania uzgodnionego zadania sprintu, to zależność ta powinna być wyraźna przy planowaniu (w przeciwnym razie, co szacowali?).

Z mojego doświadczenia wynika, że ​​projekty z wieloma „skokami dochodzenia” są przykrywką dla programistów, którzy nie robią nic dobrego i chcą spędzić czas na poznawaniu nowej błyszczącej fajnej rzeczy, zamiast tworzyć wartość biznesową. Nie sugeruję, aby twój zespół to robił, ale projekt potrzebuje jasnych celów, a jeśli programiści mają swobodę „badania”, będą to robić i będą to robić tak długo, jak na to pozwolisz.

Scrum mówi, że lepiej mieć produkt dostarczany klientowi. Chodzi jednak o to, że nie określa produktu dostarczanego i klienta .

Innymi słowy, w konkretnym przypadku możesz zdefiniować swój produkt dostarczany jako ulepszenia kodu, zmiany platformy, przepisywanie i przeprojektowanie itp., A także uważać swojego kierownika technicznego za swojego klienta.

To ma dla mnie 100% sens. Tworzysz backlog, który opowiada historie użytkownika twoich produktów i kim on jest? Menedżer techniczny. Zatem przedmioty takie jak:

1. Jako kierownik techniczny chcę, aby moja baza danych zmieniła się z MySQL na X, aby zwiększyć skalowalność
2. Jako programista chcę kompleksowego systemu rejestrowania, aby móc skuteczniej diagnozować

A tym, co dostarczasz swojemu klientowi (kierownikowi technicznemu), jest system rejestrowania.

Jednak jeśli chodzi o zadania badawczo-rozwojowe, o których mówiłeś, polecam przeczytać o skokach w Scrumie. Są to zasadniczo mini-zadania z ograniczeniami czasowymi, które pomagają określić czas potrzebny na wykonanie większych, nieznanych zadań.

Jako Scrum Master możesz rozważyć dłuższe sprinty ze względu na charakter pracy. To da ci trochę więcej bufora dla zadań „badawczych”. Myślę jednak, że musisz upewnić się, że zadania generują jakiś rodzaj pracy / dowodu koncepcji w kodzie. Czego oczekujesz od programisty? Poproś ich, aby znaleźli coś do pracy i wykorzystali te informacje, aby ustalić, czy A: robi to, co chcemy B: działa lepiej C: Jak długo potrwa, aby uzyskać więcej prędkości i zacząć wiedzieć, jak długo to potrwa wziąć coś zrobić.

Jeśli odkryjesz, że nie wiesz tyle, ile myślałeś o bieżącym przepisywaniu, możesz przejść do krótszych cykli sprintu. Nie bój się dostosowywać ich w miarę postępów; to właśnie oznacza zwinność. Po badaniach możesz również zdecydować się na nową technologię. Może to być kolejny powód do skrócenia sprintu, zanim wymknie się spod kontroli. W trakcie sprintu możesz odkryć, że nowe rzeczy nie będą działać. Zatrzymaj sprint i dostosuj go do starej technologii. W końcu programiści powinni móc porównywać i kontrastować stare i nowe metody.

Żonglujesz potrzebami swoich programistów i w tym przypadku przepisujesz aplikację. Zgaduję, że istnieją Właściciele Produktów, którzy chcą, aby ten projekt został ukończony wcześniej niż później i nie zaakceptują potrzeby „badań” jako długoterminowej wymówki.

Niektóre z poniższych strategii mogą pomóc,

1. Tak, możesz mieć zaległości z historiami technicznymi .

   Podobnie jak historia użytkownika, powinny to być również Historie techniczne, koncentrujące się na korzyściach, jakie przyniesie użytkownikowi końcowemu. Oto kilka wskazówek, jak to napisać. Są to historie, które wniosą istotną wartość do produktu, tak jak chcesz przejść do lepszego zaplecza itp.

2. Do zadań dochodzeniowych (badawczych) Użyj Spike

   Skok jest eksperymentem, który pozwala programistom dowiedzieć się wystarczająco dużo o czymś nieznanym w historii użytkownika, np. Nowej technologii, aby móc oszacować tę historię użytkownika. Kolec musi mieć przedział czasowy. Określa maksymalny czas, który zostanie poświęcony na naukę i ustala szacunkową wartość szczytową.