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


9

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

  • A) Jak radzisz sobie z zależnościami w planowaniu sprintu? EDYCJA: Czy projektowanie / UX historii użytkownika może przebiegać w tym samym sprincie co implementacja?
  • B) Jak mam teraz podejść do sprintu? Ponownie oszacuj bieżącą historię użytkownika i zobacz, jak wypalenie przekształca się w wypalenie i być postrzeganym jako niekompetentny / nieproduktywny? Lub dodaj nowe zadanie do bieżącego sprintu zgodnie z zasadą „pomóż projektantowi stworzyć odpowiedni projekt”


  • Warto wspomnieć, że twoje pytanie w temacie jest bardzo różne od pytań na dole tekstu. Byłoby pomocne, jeśli edytowałeś to, aby wybrać jedno lub drugie.
    pdr

    Odpowiedzi:


    14

    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.


    Dziękuję za odpowiedź. Aby się rozwinąć, mój mistrz scrum chce, abyśmy byli naprawdę zwinni, abyśmy mogli zmieniać / iterować historię użytkownika, gdy tylko zostanie ona zakodowana. Dlatego nie lubi zbytnio wstępnej dokumentacji / projektu, a zamiast tego mamy kodować / planować w trakcie pracy. Oczywiście prowadzi mnie to do sytuacji, w której się znalazłem. Zwinny manifest zdaje się jednak potwierdzać jego stanowisko. Czy to dlatego, że jesteśmy zbyt zwinni dla własnego dobra?
    Allan

    Przykładem może być jedna z naszych historii użytkowników: „Użytkownik chce móc grać przeciwko innemu graczowi”. Podczas planowania sprintu prawdopodobnie podzieliłbym to na kilka zadań, takich jak: pokaż serwery, wybierz serwer, z którym chcesz się połączyć, połącz się z serwerem. Projektant najlepiej wtedy powiedziałby mi, jak wyświetlane są serwery, jakie filtry list są dostępne, co się stanie, jeśli nie ma serwerów itp. Oczywiście ta lista rzeczy jest dostępna tylko po zaprojektowaniu jej i w tym przypadku ma miejsce w tym samym sprincie. Ta lista może również ulec zmianie / iteracji podczas sprintu.
    Allan

    1
    @Allan: Mistrz scrum nie rozumie tego, że jeśli projektant musi ukończyć pracę, zanim programista może rozpocząć pracę, to jest to projekt z góry. Sprawienie, by stało się to w trakcie sprintu, nie eliminuje kosztów wstępnego projektu, ale czyni go mniej widocznym ORAZ utrudnia oszacowanie rozwoju. Jeśli możesz znaleźć sposób na iterację ze swoim projektantem, to świetnie, włącz go do sprintu i podejmuj wysiłek odpowiedni do wspólnego zadania. Ale z góry jest OK, o ile jest uczciwy i najlepiej zrobić to przed sprintem.
    pdr

    Jeśli jest to typowe dla twoich historii użytkowników, argumentowałbym, że twoje historie są zbyt duże. Biorąc pod uwagę twój przykład, spodziewam się, że „użytkownik może zobaczyć listę serwerów”, „użytkownik może połączyć się z serwerem i zobaczyć listę dostępnych przeciwników” jako historie.
    Jules

    6

    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.


    To też była dobra odpowiedź. Gdybym mógł oznaczyć dwie odpowiedzi jako poprawne, zrobiłbym to.
    Allan

    3

    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.


    Dzięki Darhazer. Tak, scrum master jest także managerem projektu. Scrum Master stwierdził, że musi być minimalne planowanie i dokumentacja. Zamiast tego mamy budować funkcje na bieżąco, z ciągłymi przeglądami podczas sprintu, aby iterować / zmieniać to, co zostało zbudowane zgodnie z ustaleniami menedżera projektu (stąd projekt i implementacja zachodzące w tym samym sprincie). Wywodząc się z roli, w której projekt był dość solidny, z trudem dostosowuję się do tej kultury kodowania.
    Allan

    3
    „... scrum master jest także kierownikiem projektu”. - niedobrze. „... minimalne planowanie i dokumentacja ...” - co dokładnie JEST w twoich Definicjach Gotowych i / lub Gotowych? „... przegląda podczas sprintu, aby iterować / zmieniać to, co zostało zbudowane zgodnie z ustaleniami kierownika projektu ...” - taka powinna być decyzja Zespołu, nie mistrza scrum, z pewnością nie kierownik projektu i (jeśli MUSI to być ktoś ) powinien być właścicielem produktu!
    Phill W.,

    @PhillW. Nie mamy definicji gotowej. Po prostu mamy zaległości z różnymi stanami szczegółowości dla danej funkcji. Szczegóły stają się dopracowane w miarę upływu czasu. Zrobione jest oficjalnie, gdy interesariusze się wypisają, ale tak naprawdę jest to dla kamieni milowych i to menedżer / scrum master / producent (ta sama osoba) mówi, kiedy to się skończy. Pracuję teraz „scrum” od roku, niedługo po rozpoczęciu, sam zacząłem uczyć się na scrum, ponieważ czułem, że nasza droga była dziwna. Im więcej czytam, tym bardziej mam wrażenie, że wykonujemy scrum „Cargo kult”. Ale polityka utrudnia mi robienie czegokolwiek ...
    Allan

    1

    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.


    0

    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 :))

    Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
    Licensed under cc by-sa 3.0 with attribution required.