Wiem, że właściciel produktu powinien napisać historię użytkownika w scrum.

Historia użytkownika opisuje funkcję dla użytkownika końcowego.

Ale kto opisuje, co należy opracować technicznie i jak należy go wdrożyć

i gdzie przechowywane są te informacje dotyczące scrum?

To mnie naprawdę zainteresuje!

Widzę duży brak wiedzy w naszej firmie, gdy deweloper zaczyna wdrażać historię, ale nie wie JAK ją wdrożyć!

Na przykład muszą poradzić sobie ze starszym interfejsem COM i nie mają pojęcia, jak sobie z tym poradzić, lub nie mają wystarczających umiejętności technicznych w zakresie WPF / WEB lub czegokolwiek.

W jaki sposób scrum pomaga tym ludziom zacząć od historii użytkownika?

Nienawidzący tutaj nienawiści. Uzgodnienie szczegółów implementacji i określenie zadań, które należy wykonać, odbywa się podczas spotkania planowania sprintu, które zamieni historie użytkowników w rzeczywiste zadania / wymagania dla sprintu. Niepowodzenie wielu zwinnych procesów polega na tym, że spotkanie planowania sprintu powinno być w dużej mierze wykonane przez programistów ... jeśli są to tylko właściciele produktów, po prostu zdecydują się wziąć księżyc. Oto wymyślenie (raczej mglistej) historii użytkownika, takiej jak:

As a non-technical user, I need to have a simpler interface with the API

Podczas gdy właściciel produktu określa, które historie użytkowników mają najwyższy priorytet, programiści biorą te priorytety i przekształcają je w listę zadań (zwaną zaległością sprintu). To tutaj masz pomysł na to, jak zamierzasz wdrożyć różne rzeczy ... zaległości sprintu mogą być tak techniczne, jak tylko chcesz. Tutaj również dowiesz się, „aby uzyskać prostszy interfejs API, będziemy musieli zmienić ten szalony interfejs API COM. Czy ktoś wie, jak go używać?”. Kiedy odpowiedź brzmi „Hell No”, zobaczysz, że zakres tej historii użytkownika może być większy, niż się wydaje. Biorąc to pod uwagę, powinieneś podzielić historię użytkownika na zadania:

• Dokumentuj i rozumiem bieżący interfejs API
• Zaprojektuj nowy interfejs API
• Zaimplementuj nowy interfejs API
• Cokolwiek...

Biorąc to pod uwagę, można negocjować historie użytkowników, aby podzielić je na mniejsze zmiany. Zwinna metodologia oznacza, że ​​chcesz podejść do tego, co dana osoba krok po kroku. Możesz więc powiedzieć „Hej, spójrz. Nie możemy dokonać przeglądu interfejsu API za pomocą tylko jednej iteracji. Podzielmy go na„ Jako klient nietechniczny potrzebuję dobrze udokumentowanego interfejsu API ”.

Krótka odpowiedź

Zespół deweloperów pisze rzeczy techniczne. Scrum pomaga ci trochę, ale niewiele, w przypadku awarii technicznej. pierwsze kroki w historii użytkownika. Scrum jest prawie wyłącznie w What-World . Podział techniczny to How-World .

Podział zapewniony przez Scrum to:

• Historia użytkownika -> Kryteria akceptacji

Podział, którego często używają ludzie, to:

• Epicka -> Historie użytkowników
• Historia użytkownika -> Podzadania
• Kryteria akceptacji -> Testy akceptacyjne

Ponadto zespół może pisać zadania techniczne dotyczące rzeczy, które według nich należy wykonać (tj. Zainstalować IntelliJ IDEA dla wszystkich na początku projektu), ale które nie mają wartości biznesowej.

W celu uzyskania dalszych wskazówek dotyczących podziału pracy, zwróć uwagę na XP (Extreme Programming), Clean Code , Pragmatic Programming , Engineering Software , CRC-Cards , OOP / OOA / OOD , Pattern Design , Refactoring , Working Effective with Legacy Code , TDD ( Test-Driven Development), BDD (Behavior-Driven Development), ATDD (Acceptance-Test Driven Development).

Długa odpowiedź

Jak myśli Scrum

Jaki świat i jak świat

Istnieje What-World i How-World . Jak dobrze się czujesz, User Story jest dla użytkowników , generujących wartość biznesową, czyli wartość wtórną w What-World . Scrum jest przeważnie tylko w What-World. Mówi niewiele o How-World , w zasadzie nie więcej niż „How-World jest obowiązkiem zespołu deweloperów”.

Historia użytkownika a zadanie

Zazwyczaj elementy zaległości dla How-World nie są nazywane Historią użytkownika, ale Zadaniem technicznym lub Podzadaniem . Wiele narzędzi pozwala na podzielenie historii użytkownika z What-World na podzadania w How-World .

Jak Scrum pomaga i gdzie kończy się ta pomoc

Pomoc Scrum dla How-World kończy się w kilku punktach na spotkaniu dotyczącym planowania sprintu :

• [Spotkanie dotyczące planowania sprintu] Zespół odkrywa nieporozumienie związane z historią, jeśli różni koledzy z zespołu przedstawią różne oszacowania Punktów Story podczas Planning Poker -> Dyskusja.
• [Definicja gotowości] Zespół nie akceptuje historii użytkowników, które są zbyt duże (punkty historii są zbyt wysokie). W wielu Definicjach Gotowości przyjęto ogólną zasadę, że Punkty Story muszą być mniejsze niż połowa prędkości drużyny.
• [Definicja gotowości] Zespół nie akceptuje historii użytkowników bez wystarczającego opisu kryteriów akceptacji. Kryteria akceptacji są wystarczające, jeśli zespół ma wystarczającą pewność co do rozpoczęcia pisania Testów akceptacyjnych.

Kilka wskazówek na temat poziomu Scrum

Uznałem, że pomocne było podzielenie historii użytkowników na podzadania podczas spotkań w celu uzupełnienia zaległości lub przynajmniej drugiej części spotkania planowania sprintu (w przypadku niektórych zespołów spotkania planowania sprintu 2 ).

Z niedoświadczonymi zespołami przydały mi się Atomowe Historie Użytkowników podczas Udoskonalania Backlog i Planowania Sprintu. Atomowa historia użytkownika to historia użytkownika, której nie można podzielić na mniejsze historie użytkowników bez całkowitej utraty wartości biznesowej. Ogólnie rzecz biorąc, Historie użytkowników nie muszą być Atomowe, właśnie odkryłem, że pomaga mi to w niedoświadczonych zespołach.

I nie rób "(Architektura | Projektowanie | Implementacja | Test) funkcji X" jako historie użytkowników. Polecam nawet spróbować tego uniknąć jako podzadania.

Jeśli mam Atomowe historie użytkowników i wydają się one wymagać dalszego podziału oprócz Kryteriów akceptacji, które mają zostać wdrożone, oznacza to dla mnie, że coś nie działa na optymalnym poziomie. Albo architektura jest zła / zbyt skomplikowana, tzn. Techniczna zamiast zorientowana na biznes. Lub zespół jest niedoświadczony. Lub obie. W każdym razie konieczne byłoby podjęcie działań w celu poprawy sytuacji poprzez szkolenie i rozpowszechnianie wiedzy.

Beyond Scrum

Scrum Master poza Scrumem

Dzisiaj Scrum Master jest w większości rozumiany jako rola menedżerska , a to bzdury. Początkowo Scrum Master był, a ja to zalecam , rolą techniczną , a nie rolą kierowniczą, podobnie jak trener w XP .

Zbyt łatwo jest polegać na Scrumie i Scrum Masterie, a zatem wpaść w ogromną lukę, ponieważ Scrum prawie nic nie mówi o How-World.

Rotating Scrum Master

Idealnie, Scrum Master działa rotacyjnie wśród doświadczonych programistów, którzy mają również wystarczające umiejętności kierownicze i komunikacyjne, dopóki wszyscy w zespole nie przeżyją „Kontroli i dostosowania” tak głęboko na pamięć, że Scrum Master stanie się zbędny; nikt i wszyscy nie byliby jednocześnie Scrum Master.

Ale uwaga, Scrum Mastery bardziej przypomina gotowanie, a nie czyszczenie stołu i zmywanie naczyń. Możesz obracać, kto czyści stół i myje naczynia, ponieważ każdy może to zrobić. Ale nie chciałbyś obrócić gotowania na wszystkich, ponieważ są ludzie, którzy nie mogą gotować lub nie lubią gotować, a ty chcesz jeść dobre jedzenie.

Dobrą rzeczą w obracaniu Scrum Master pomiędzy ekspertami jest to, że zespół ma większe szanse na poznanie większej liczby metod.

Zespół samoorganizujący się

Z punktu widzenia Scruma zespół musi się przekonać, najlepiej z pomocą Mistrza Scruma .

Scrum mówi również o zespole deweloperów . Role takie jak Architekt lub Główny Inżynier nie istnieją w Scrumie. To nie znaczy, że są zabronione, to tylko oznacza, że ​​Scrum nic o nich nie mówi. Scrum ogłasza zespół samoorganizujący się , co oznacza, że ​​jeśli zespół ogłosi Architekta, zespół ma Architekta. Nie jest to zdefiniowane przez Scrum, ale jest zgodne ze Scrum. Nie ogłaszam oddanych Architektów (pracowałem jako Architekt od lat i chociaż mi się podobało, zasadniczo jestem przeciwny pomysłowi mianowania Architekta), podając tylko przykład.

Test wstępny

Historie użytkowników mają kryteria akceptacji . Te kryteria akceptacji są przekształcane w testy akceptacji

Inne rzeczy

Aby uzyskać więcej informacji na temat podziału, zobacz Jak podzielić projekt programistyczny na zadania dla innych programistów?

Mam nadzieję że to pomoże.

Ten, kto jest najlepiej wykwalifikowany w zespole, musi podzielić wymagania właścicieli produktów na historie użytkowników, które można wykorzystać. Z mojego doświadczenia wynika, że ​​zastosowaliśmy następujące podejście:

• Zawsze programista pisał historie na podstawie dyskusji z właścicielami produktów.
• Historie te są następnie szacowane (na podstawie punktów lub czasu) przez programistów
• Właściciele produktu decydują o tym, w jaki sposób sprawy mają priorytet.

Jeśli programiści nie wiedzą, jak zaimplementować historię, może to być jeden z tych przypadków:

• Zadanie może nie być wystarczająco jasne (dodaj więcej szczegółów / zrzutów ekranu / makiet)
• Należy go dalej podzielić, aby określone zadania były jaśniejsze
• Potrzebuje więcej czasu, aby programista mógł przeprowadzić badania i dowiedzieć się, jak go wdrożyć. (Szacując to zadanie, dodaj więcej czasu na rozliczenie tego)
• Deweloper nie ma wystarczających kwalifikacji, aby go wdrożyć i może być konieczne przypisanie go do kogoś innego lub deweloper musi być wspomagany przez kogoś innego.

Możesz wziąć udział w tym kursie na SCRUM w Udemy za darmo i dowiedzieć się o poszczególnych aspektach procesu SCRUM - https://www.udemy.com/scrum-methodology/

Krótka odpowiedź brzmi: właściciel produktu jest odpowiedzialny za tworzenie historii, które zespół musi przedstawić. To zespół decyduje, jak przekazać historie. Jeśli część dostawy obejmuje pewne historie techniczne, to zespół pisze te historie. Zespół następnie współpracuje z właścicielem produktu w celu ustalenia priorytetu.

Ponownie PO decyduje, co zbudować, zespół decyduje, jak wdrożyć te historie.

To nie jest problem zwinny. Problem polega na tym, że zespół nie ma wystarczającej wiedzy technicznej, aby ukończyć historię użytkownika (zwinna) lub wymaganie (tradycyjne). Czy Agile może pomóc w tej sytuacji? Nie, jeśli zespół nie został starannie wybrany i nikt w zespole nie ma wystarczającego doświadczenia technicznego, aby wykonać swoje zadania. Tak, jeśli niektórzy członkowie zespołu mają dobrą wiedzę techniczną, która może pomóc innym członkom zespołu w wykonywaniu ich zadań. Ten zespół musi się samoorganizować i powinien znać swoją siłę i słabości.

pamiętaj o następującej zwinnej zwinności.

„Najlepsze architektury, wymagania i projekty powstają z samoorganizujących się zespołów”

Dzieje się tak, ponieważ w środowisku Agile zaufanie zespołu jest wysokie i delegują pracę między sobą.