SCRUM od zera, bez ustalonej podstawy?

11

Jesteśmy małą grupą 5 osób, która wkrótce rozpocznie nowy projekt. Jest to pierwszy projekt, w którym skupimy się na scrum.

Trochę zmagamy się z tym, jak ustanowimy bazę dla projektu (ramy i tym podobne). Takie zadania nie są czymś, z czego użytkownik skorzysta bezpośrednio, więc mamy trudności z ustaleniem, w jaki sposób piszemy dla nich historie użytkowników.

Więc ogólnie, jak używasz scrum, kiedy zaczynasz projekt od zera, bez ram i bez biblioteki podstawowej?

Niklas H.
źródło

Odpowiedzi:

7

Nie sądzę, że wiele zwinnych metod dobrze radzi sobie z działaniami, które zazwyczaj są częścią tworzenia projektu. Wiele popularnych frameworków (XP, Scrum, Kanban) nie rozwiązuje tego problemu, ale niektóre skalowane frameworki (Disciplined Agile Delivery, SAFe) robią to do pewnego stopnia.

Niektórzy opowiadają się za koncepcją początkowego przyrostu (w Scrumie, sprincie), który ma na celu skonfigurowanie twojego projektu. Jest to często nazywane zerowym przyrostem (lub, w Scrumie, Sprint 0). Jednak nie jest to formalna część Scruma i puryści twierdzą, że pierwszy przyrost powinien być potencjalnie możliwy do uwolnienia.

Taki przyrost służy do konfigurowania środowiska zespołu - konfigurowania środowiska programistycznego, testowego i produkcyjnego, konfigurowania narzędzi pomocniczych i skryptów oraz tworzenia środowisk roboczych za pomocą wykresów wypalenia i zaległości. Jeśli ktoś w zespole nie jest zaznajomiony z używanymi narzędziami programistycznymi, w tym miejscu uczy się podstaw funkcjonowania i zaczyna generować wyniki w pierwszej iteracji.

Oprócz tego często zaczynasz pisać pierwsze historie użytkowników i nadać priorytet zaległościom produktowym, ponieważ w tym momencie nie ma zaległości sprintu. Ktokolwiek jest właścicielem produktu, będzie wymyślał historie. Jeśli ta osoba jest nowa w Scrumie, uczy się, jak pisać dobre historie użytkowników, z którymi zespół może również współpracować. Nie kładź nacisku na zbieranie wszystkich historii, ale będziesz mieć dość czasu, aby rozpocząć pierwszą iterację rozwoju.

Różne zespoły inaczej traktują Sprint 0. Niektórzy mogą odtwarzać go w tym samym czasie, co każdy inny sprint. Inni mogą ją nieco wydłużyć lub skrócić w zależności od potrzeb zespołu. Ponieważ jest to Twoja pierwsza próba Scruma, mogę ją wydłużyć, szczególnie jeśli masz krótsze iteracje w ramach swojego cyklu rozwoju. Jeśli planujesz iteracje dwutygodniowe, zrób to 3 tygodnie.

Jeśli chodzi o formułowanie zadań, niekoniecznie musiałbym je formułować jako historie użytkowników. Możesz, z perspektywy członków zespołu i różnych ról (Właściciel produktu, ScrumMaster, programista, tester, projektant, pisarz techniczny i tak dalej). Sprint 0 jest jednak przeznaczony dla zespołu, a nie dla klienta lub użytkownika. Wystarczyłaby prosta lista zadań i czynności.

Thomas Owens
źródło
3
Sprint 0 jest przeznaczony bezpośrednio dla zespołu, ale pośrednio przynosi korzyści klientowi, ponieważ stanowi podstawę przyszłych prac sprinterskich. Świetna odpowiedź, sprawiasz, że brzmi to łatwo i nie tak chaotycznie, jak zwykle myśli Sprint 0.
wałek klonowy
Każde uruchomienie projektu jest zazwyczaj w pewnym stopniu chaotyczne, w zależności od zespołu. Zwykle występują nie tylko problemy techniczne z przygotowaniem wszystkiego, ale także problemy osobiste między członkami zespołu i problemy z procesem, które pozwalają ustalić, jak najlepiej radzić sobie z pojawiającymi się problemami.
Thomas Owens
Innym narzędziem w pasku narzędzi Scrum jest seria „skoków” (historie badań), w których wynik zasadniczo określa, jakie opcje są dostępne i co zespół wybrał jako preferowane rozwiązanie. Oznacza to, że gdy nie są używane frameworki, możesz mieć sprint, aby określić, które (jeśli w ogóle) framewory pomogłyby ci zbliżyć się do użytecznego produktu. Brak struktury jest zawsze opcją, szczególnie w przypadku małych, jednorazowych narzędzi.
Berin Loritsch
1

Są to wymagania wstępne, które ustaliliśmy przed wdrożeniem SCRUM w naszym zespole. Gdy skończysz z listą, możesz uruchomić proces i narzędzia do faktycznego scrum.

  1. Członkowie zespołu mają wysokie lub umiarkowane umiejętności.
  2. Zespół jest ściśle związany.
  3. Wymiana informacji między członkami zespołu przebiega szybko, spójnie i swobodnie.
  4. Zespół znajduje się w tej samej lokalizacji.
  5. Biznes jest bardzo zaangażowany w zespół.
  6. Architektura (biznesowa, informacyjna i techniczna) jest dobrze zdefiniowana.
  7. Infrastruktura jest uruchomiona - środowisko deweloperskie, testowe i UAT.
  8. Zautomatyzowana kompilacja i wydanie.
  9. Wysoki poziom automatyzacji testów.
  10. Zależność drużyny od świata zewnętrznego jest minimalna (najlepiej zero).
  11. Liczba uczestniczących systemów jest minimalna.
  12. Wymagania są stabilne na wyższych poziomach, więc zaległości produktu mają minimalne zmiany.
  13. Członkowie zespołu są niezależni w podejmowaniu decyzji, która historia użytkownika powinna być częścią sprintu / scrumu, a także całkowitą liczbę scrumów / sprintu potrzebną do osiągnięcia określonego celu.

Pozostałe dwie ważne części:

  1. Wybierz osoby dla ról (Scrum master, właściciel produktu i zespół)
  2. Przygotuj białą tablicę i naklejki.
java_mouse
źródło
Co masz na myśli z numerem 11?
Matt Grande,
3
Z mojego doświadczenia wynika, że ​​jeśli aplikacja zależy od systemów zewnętrznych lub jest z nimi połączona, SCRUM nie działał dobrze. Uzależnienie od innych zespołów zmniejszyło wydajność naszego procesu. Być może był to tylko nasz projekt ...
java_mouse
No dobra, więc chodziło o systemy, które wymagały modyfikacji. Pomyślałem, że to systemy, które zostały uwzględnione, stąd zamieszanie. W przeszłości udało nam się to dzięki dwóm „poziomom” scrum. Poziom niższy dla każdego systemu i poziom wyższy dla całego projektu, obejmujący wszystkie zespoły.
Matt Grande