Scrum: Czy projektowanie / UX historii użytkownika może przebiegać w tym samym sprincie co implementacja?

Jestem obecnie w sprincie (dwa tygodnie), w którym projektant ma za zadanie zdefiniować wymagania i UX konkretnej historii użytkownika.

W tym samym sprincie mam zaimplementować ten projekt. Podczas planowania sprintu musiałem zgadywać, jak długo potrwa ta niezdefiniowana historia użytkownika.

Dzisiaj w końcu otrzymałem projekt. Niestety projekt jest niepełny / niejasny i bardziej przypomina wymagania klienta niż projekt. Jednak z tego wciąż widzę, że nie oszacowałem wystarczająco dużo.

Co gorsza, nie jest to pierwszy raz. W ostatnim sprincie wydarzyło się dokładnie to samo. Oflagowałem to w naszej retrospektywie, a mistrz scrum nie miał odpowiedzi na pytanie, jak to rozwiązać, zamiast powiedzieć „to dla ciebie tylko rozwój”. Jak na ironię denerwuje go, jeśli spalenie nie jest na celu ...

Teraz będę musiał poprosić / współpracować z projektantem, aby wykonał swoją pracę. To mnie powstrzyma, ponieważ wykonałem wszystkie inne zadania.

Więc moje pytanie brzmi

jak radzisz sobie z zależnościami w planowaniu sprintu?

Najlepiej byłoby, gdyby przed planowaniem sprintu były obsługiwane zależności niezwiązane z programowaniem, aby mieć dobrą definicję elementu zaległości, na podstawie którego można oszacować wysiłek.

Ale jeśli to był sprint „tylko dla ciebie” podczas ostatniego sprintu, to prawdopodobnie byłby to tylko rozwój dla ciebie podczas tego sprintu, więc naprawdę powinieneś był zwiększyć swoje szacunki tam, a następnie na nadchodzące zadania, które są w podobnym stanie. Nie jest to mściwe i błędem byłoby pozwolić, by tak się stało.

To, co robi, pokazuje niepewność oszacowania bez względnie solidnego projektu do oszacowania. Być może zachęci to kierowników do upewnienia się, że element zaległości w produkcie jest poprawnie zdefiniowany; ale w najgorszym wypadku zakryje twoje plecy. Nikt nie narzeka, gdy praca jest w niepełnym budżecie.

Jednak tego nie zrobiłeś, a teraz twoje pytanie brzmi ...

jak mam teraz podejść do sprintu?

Głównym celem Scrum jako narzędzia do zarządzania projektami jest wczesne identyfikowanie problemów, które już zrobiłeś. Zgłoś to do swojego kierownictwa, pozwól im zdecydować, co zrobić ze sprintem. Jeśli próbują cię winić, bądź pokorny i zapytaj, jak sugerują podejście do podobnych sytuacji w przyszłości, aby uniknąć tego samego problemu, nawet jeśli naprawdę nie wierzysz, że jest to sprawiedliwe.

Na koniec są to problemy z zarządzaniem projektami, a jeśli spróbujesz je rozwiązać we własnej bańce, zaczynasz ponosić porażkę. A kiedy to zrobisz, będziesz zły, ponieważ spadnie on na ciebie, a nie na menedżerów, którzy nie rozwiązali problemu, kiedy zgłosiłeś im to.

Po pierwsze, istnieje duża różnica między zależnościami między historiami / zadaniami a niepewnością co do zakresu / wysiłku historii / zadania.

Zależności są obsługiwane przez nadanie zależnemu zadaniu / historii niższego priorytetu niż zadanie / opowieść, od której zależy, i być może adnotację, że nie można rozpocząć przed wykonaniem innego zadania / historii.

Niepewność należy rozwiązać na spotkaniu planistycznym, wyjaśniając prace, które należy wykonać w związku z historią. Jeśli usunięcie niepewności nie jest możliwe, historia najprawdopodobniej nie spełnia twojej „Definicji gotowości” i nie powinna zostać zaakceptowana do sprintu.
Jeśli z jakiegoś powodu historia naprawdę musi przejść do sprintu, jedyną dostępną opcją jest dodanie bufora ryzyka do oszacowania.

Na bieżący sprint, jeśli nie możesz pracować nad historią, po prostu zgłoś to na następnym codziennym spotkaniu i wykonaj wszelkie możliwe prace, aby osiągnąć ogólny cel sprintu zespołu. Możesz także dodać adnotację, że historia jest zablokowana i przez co.
Po rozpoczęciu sprintu w zasadzie nie można dodawać nowych zadań do sprintu.
Ponadto, jeśli zadanie okazuje się więcej pracy niż szacowane, nie zmieniasz oszacowania, ale wiernie raportujesz, jaki jest postęp i pozostały wysiłek związany z zadaniem.

W końcu w Scrumie zespół obiecuje coś dostarczyć. Jeśli obietnicy tej nie da się złożyć, oznacza to porażkę całego zespołu, nigdy żadnej osoby w zespole.

Podczas planowania sprintu musiałem zgadywać, jak długo potrwa ta niezdefiniowana historia użytkownika.

To błąd, który popełniłeś. Nikt nie może zmusić zespołu do przyjęcia zadania w sprincie, a Twoim zadaniem jest stwierdzenie, że zadania nie można oszacować i zaakceptować w sprincie, chyba że jest co najmniej szkielet (na przykład). Wygląda na to, że Twój Scrum Master jest menedżerem projektu, co tylko pogarsza sytuację.

Jak podejść do takiego zadania, jeśli jest to konieczne do wykonania w sprincie (z ważnych powodów biznesowych)? Cóż, najpierw musisz ustalić termin projektu, po którym nie będziesz w stanie go wdrożyć. Na przykład: historia jest akceptowana, ale projekt powinien zostać dostarczony w ciągu pierwszego tygodnia i wdrożony w ciągu drugiego. Następnie musisz ściśle współpracować z projektantem, aby upewnić się, że będzie możliwe wdrożenie go w sprincie. Scrum zakłada interdyscyplinarny zespół i do Ciebie należy organizacja pracy z projektantem. To powiedziawszy, jeśli zaakceptujesz zadanie w sprincie - decyzja należy do zespołu - zespół musi zarządzać pracą w sposób, w jaki jest ona wykonywana w sprincie, i zarządzać związanym z tym ryzykiem. Nie powinieneś czekać, aż inny dokończy swoją pracę, aby wykonać zadanie. Możliwe, że wkrótce ujawnisz większą dysfunkcję w swojej organizacji.

Czy zadania związane z projektowaniem są wyrażane jako historie i jakie są definicje Twojego zespołu

• historia jest gotowa
• historia jest skończona

Każda historia powinna mieć własne wymagania i warunki akceptacji, ale myślę, że dobrą praktyką jest zestaw zasad, które mają zastosowanie do wszystkich historii. Na przykład historia jest gotowa, jeśli (i tylko jeśli!): Kompleksowe badania architektury są zakończone, projekt jest dostępny, historia została oszacowana przez zespół. Minimalne warunki akceptacji mogą być: automatyczny test jest zakończony, OK i został zintegrowany z kombinezonem testowym, przegląd kodu jest zakończony.

Jeśli historia nie jest gotowa, nie osadzaj jej w sprincie. Jeżeli warunek przyjęcia nie jest spełniony, to nie jest on ukończony.

W twoim przypadku zespół może zdecydować, że aby być gotowym, historia rozwoju musi mieć kompletny projekt (przynajmniej szkielet, dostosuj to do własnej rzeczywistości). Jeśli tak, nie możesz poradzić sobie z projektowaniem i programowaniem w tym samym sprincie. Zespół może również zdecydować, że historia UX / design powinna przynajmniej wytworzyć projekt szkieletowy. Jeśli tak nie jest, historia nie jest akceptowana i dlatego nie można rozpocząć historii zależnych od niej.

Powinieneś łatwo przekonać swoich menedżerów, że posiadanie silnych zasad gotowości jest dobrą rzeczą: ponowna ocena złożoności podczas sprintu jest złą praktyką. Oznacza to, że prędkość zespołu jest niepewna, a następnie, że jako menedżerowie mają złą wizję pracy zespołu i przyszłości.

Sprint zwykle rozpoczyna się, gdy historia jest jasna - na tym etapie Backlog Produktu jest ustalany i traktowany priorytetowo. Jeśli zacząłeś bez projektu, to powinno być jasne, co można zrobić bez projektu, a co nie ...

Jeśli musisz improwizować, gdy projekt „uderza” między klientem a PO, wówczas Twój PO musi poinformować zespół o wszelkich nowych funkcjach, gdy tylko się pojawią: to jest znaczenie „elastyczności” w Scrumie - dostosuj się do bieżących sytuacja. Zespół programistów, Scrum Master i właściciel produktu muszą komunikować się na stałe, w przeciwnym razie nie będzie reakcji w czasie rzeczywistym na zmianę.

Więcej treningów nie zaszkodzi ... Być może praca z projektantem byłaby dla ciebie okazją do zdobycia nowych umiejętności UX? ... to obserwuje, że szklanka jest w połowie pełna zamiast w połowie pusta :))