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.