SCRUM od zera, bez ustalonej podstawy?

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?

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.

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.