W jaki sposób Scrum można dostosować do otoczenia dla wolontariuszy?

Niedawno dołączyłem do młodej hackerspace, która wciąż się przygotowuje. Mamy szczęście, ponieważ przestrzeń ma kilka wewnętrznych projektów, nad którymi trzeba pracować i nie brakuje ochotników do pracy nad nimi.

Odbyło się kilka dyskusji na temat organizacji tych projektów. Moje ostatnie doświadczenie zawodowe związane było ze Scrumem, więc rozważam zastosowanie podejścia Scrum w naszych projektach programowych, ale nie jestem pewien, czy będzie dobrze dopasowane.

Chociaż widziałem, jak Scrum działa dobrze w przypadku małych, pełnoetatowych zespołów, charakter tej organizacji jest inny:

• Członkowie są wolontariuszami . Niektórzy są studentami stacjonarnymi. Inni pracują na pełny etat. Nie możemy oczekiwać od nikogo stałego poziomu wkładu, ponieważ ich prawdziwe życie ma priorytet.
• Podczas gdy prawie wszyscy mają wieloletnie doświadczenie w pisaniu oprogramowania, niewielu członków uczyniło to profesjonalnie lub w zespołach.
• Nie ma właściciela produktu . Wymagania dotyczące tych projektów określa komitet. Członkowie tego komitetu będą również pracować nad wdrożeniem. Oznacza to, że nie będziemy mieć jednego, dedykowanego właściciela produktu.
• Nie mamy terminów (miękkich lub twardych). Projekty zostaną ukończone, gdy zostaną ukończone.

Są to dość znaczące różnice, ale nie jestem przekonany, że będą blokować stosowanie Scruma. Myślę, że drobne poprawki mogą nas pokonać w tej przeszkodzie:

• Jeśli zmienimy Sprinty, aby mieć ustalony rozmiar fabuły, ale czas trwania płynów (czas), nadal będziemy mogli korzystać z iteracyjnych wersji bez wywierania nierealistycznej presji dostarczania na deweloperów ochotników.
• Możemy porzucić wykresy zużycia i obliczenia prędkości . Jeśli dobrze rozumiem, są to narzędzia i wskaźniki, które działają jako pomost między zespołem programistów a zarządem. Służą do zgłaszania postępów w formie, która ma znaczenie zarówno dla programistów, jak i interesariuszy. Biorąc pod uwagę, że nie mamy nikogo, z kim można by się zgłaszać (brak Kierownika Projektu, Właściciela Produktu i zewnętrznych interesariuszy). Uważam, że możemy to całkowicie pominąć.

Rzeczy, które, jak sądzę, moglibyśmy czerpać, nie wymagały poprawiania:

• Wymagania Zbieranie Meeting (S). Tam, gdzie wszyscy siedzą przy stole i omawiają Historie użytkowników, szkicują kpiny z interfejsu użytkownika i tworzą Backlog produktu.
• Retrospektywy Sprint . Będzie to dla nas interesujący sposób na zbliżenie się do procesu rozwoju, który działa dla nas jako zespołu wolontariuszy.

Czego nie jestem pewien:

• Jak należy traktować codzienne stand-upy ? Zastanawiam się, czy w naszym otoczeniu miałyby one jakąkolwiek wartość. Rozumiem rytuał stand-up, ponieważ pomaga on w komunikacji poprzez naturalne rozpowszechnianie informacji w całym zespole. Biorąc pod uwagę fakt, że nasze Sprinty zapewnią znacznie mniej złożoność niż przeciętny Sprint, być może będzie mniej potrzeby być na bieżąco z postępami / postępami innych członków zespołu.
• Czy powinienem naciskać na XP , takie jak ciągła integracja, recenzje kodów i TDD? Obawiam się, że będzie to wiele wymagać. Bardziej kusiłbym, aby wprowadzić te koncepcje w przyszłych projektach, gdy ludzie będą bardziej zaznajomieni ze Scrumem i pracować jako zespół.

Moje pytania:

Czy Scrum można dostosować do środowiska opartego na wolontariacie?
I czy moje planowane podejście idzie jak dotąd we właściwym kierunku?

Spójrz na Kanban. Jest bardziej odpowiedni niż SCRUM dla twoich ograniczeń.

Edycja: SCRUM jest (bardzo z grubsza) uporządkowanym zaległościami ze sprintami i ceremoniami, aby mieć pewność, że „trwająca” praca pozostaje pod kontrolą i ma coś solidnego na końcu każdego sprintu. Jeśli porzucisz ceremonie i kadencję sprintu, skończysz z Kanbanem: uporządkowanym zaległościami i silnym naciskiem na bezpośrednie ograniczenie pracy w toku oraz upewnienie się, że wszystko oznaczone jako „zrobione” zostało wykonane, a nie narzucenie stabilności na końcu każdy sprint.

Nadal zyskujesz zwinne korzyści: uwolnij się w dowolnym momencie, elastyczność, pewną miarę przewidywalności - chociaż SCRUM może cię nieco podnieść w tym aspekcie - i bez ceremonii lub aspektów SCRUM, które nie pasują do luźnego, rozproszonego zespołu bez zaangażowania . Haczyk? Porzucenie ceremonii wymaga większej dyscypliny, więc NAPRAWDĘ musisz zwrócić uwagę na testy, jakość kodu, bieżące prace w toku i upewnić się, że górna część zaległości (rzeczy gotowe do odebrania przez ludzi) jest wystarczająco dopracowana.

Możesz mieć zaległości oparte na głosowaniu, chociaż w środowisku wolontariuszy niektóre osoby pracują tylko nad tym, co chcą.

(I tak, wszystkie pomysły TDD, CI, recenzje i partnerskie programowanie są dobrymi pomysłami).

Aby rozwiązać różnice, które zauważysz najpierw:

• To, że Twoi członkowie są wolontariuszami, nie oznacza, że ​​nie możesz poprosić ich o zaangażowanie. Zwłaszcza przy stosunkowo krótkim czasie sprintu w Scrumie każdy z członków musi mieć możliwość dowiedzieć się, ile czasu może poświęcić na projekt w ciągu najbliższych kilku tygodni. Posiadanie członków zespołu dostępnych przez inny czas każdego sprintu utrudni planowanie, ponieważ trudniej jest ustalić, ile punktów fabularnych jest realistycznych, ale nie uniemożliwia Scruma.
• Właściciel produktu jest odpowiedzialny za konsolidację i przekazanie wizji (i wymagań), które zainteresowane strony mają do produktu zespołowi projektowemu. Część konsolidacyjna jest już prawdopodobnie objęta przez komitet „sterujący”. W części dotyczącej komunikacji mogą oni po prostu delegować jednego ze swoich członków jako głównego rzecznika. Tym, który we wszystkich praktycznych celach będzie właścicielem produktu.
• Brak zewnętrznego terminu nie jest tak naprawdę problemem dla Scruma. Po prostu sprowadza się to do dumy zespołu z produktu, aby go dokończyć. Sam Scrum ma naturalny termin na każdy sprint.

Jeśli chodzi o proponowane dostosowania, szczególnie podczas pracy z wolontariuszami, zdecydowanie zalecam zachowanie stałej długości sprintu. W ten sposób wolontariusze wiedzą zdecydowanie, na jaki okres poświęcają swoje zaangażowanie.

Nie odrzuciłbym też natychmiast wykresów wypalenia. Mogą być również przydatne dla samego zespołu, aby zobaczyć, jak sobie radzą ze swoim zaangażowaniem. Pozostawiłbym zespołowi decyzję o ich zatrzymaniu lub porzuceniu. To samo dotyczy obliczeń prędkości. zwłaszcza przy dużej zmienności dostępnych godzin pracy w każdym sprincie, mogą one okazać się bardzo przydatne (zwłaszcza jeśli obliczymy liczbę punktów ukończonych na roboczogodzinę) w szacowaniu przyszłych sprintów.

Jeśli chodzi o codzienne awarie, nadal będą przydatne w twoim otoczeniu, choćby po to, aby dać znać, co wszyscy robią lub mają problemy (i to niezależnie od złożoności). Ale może być trudniej zrealizować codzienny konflikt, więc może być konieczne kompromis.

Wspomniane praktyki XP można wprowadzić lub nie niezależnie od korzystania ze Scruma i można je również zaproponować podczas retrospekcji.

Zaskakuje mnie, że nikt tego nie zauważył, ale twój projekt wydaje się być większością projektów typu open source. Jeśli obejrzysz bardziej popularne projekty typu open source, możesz znaleźć inspirację. I myślę, że powinieneś zapomnieć o SCRUM i pomyśleć o tym z perspektywy ogólnej zwinności.

Zwinność polega na komunikacji i współpracy. Jest powód, dla którego 2 z 4 punktów w Manifeście Agile mówią o tym.

Osoby i interakcje dotyczące procesów i narzędzi

Współpraca z klientami w zakresie negocjacji umów

A tak, jak opisujesz swój projekt, trudno byłoby mieć bezpośrednią komunikację ze wszystkimi pracującymi nad projektem, co zachęca zarówno Agile, jak i SCRUM. Pierwszą rzeczą, na której chciałbym się skoncentrować, jest ustanowienie kanałów komunikacji dla całego zespołu (zarówno wolontariuszy, jak i komitetu produktu). Rzeczy takie jak wiki, fora, wideokonferencje oraz odpowiedni system śledzenia zaległości, zadań i błędów to świetne sposoby, aby upewnić się, że wszyscy wiedzą, co się dzieje i co należy zrobić.

Drugą rzeczą, na którą chciałbym zwrócić uwagę, to nie po prostu omijanie technologicznych części zwinnych. Wielu uważa (łącznie ze mną), że to oni sprawnie wykonują sprawną pracę, a nie procesową stronę rzeczy. Przegląd kodu jest ważny i większość pracy typu open source polega na tym, że ktoś, kto zna projekt, dokonuje przeglądu zatwierdzeń / zmian, aby zapewnić utrzymanie wystarczająco wysokiej jakości. TDD jest praktycznie podane dla każdego zwinnego projektu. Zapewnia, że ​​wszelkie zmiany w kodzie nie naruszają poprzedniej funkcjonalności, co jest jeszcze ważniejsze w twoim przypadku, gdy wolontariuszom nie przeszkadza naprawa błędów i błędów innych osób. Ułatwia także przeglądanie kodu, ponieważ recenzent może zobaczyć w testach, jaka funkcjonalność została dodana, a uruchamiając je, upewnia się, że funkcjonuje faktycznie zgodnie z przeznaczeniem. Ciągła integracja jest taka sama jak TDD.

Na koniec uważam, że powinieneś mieć co najmniej kilka osób pracujących nad projektem w pełnym wymiarze godzin. Ci ludzie powinni pełnić określone role:

• Właściciel produktu : Choć miło, że masz do tego dedykowany cały komitet, powinna istnieć jedna osoba, która będzie odpowiedzialna za tłumaczenie słów tego komitetu na specyfikację lub historie użytkowników i zapewnienie ich właściwego wdrożenia.
• Koordynator i Scrum Master : Ta osoba powinna być odpowiedzialna za cały proces i dopilnować, aby każdy wiedział o ważnych wydarzeniach w projekcie. Ponadto utrzymuje narzędzia wiki oraz narzędzia do śledzenia zadań i błędów. Jeśli ktoś ma pytanie dotyczące projektu, powinien zapytać o to pierwszą osobę.
• Główny programista i architekt : Osoba, która najlepiej zna kod. Dokonuje przeglądów kodu i upewnia się, że jakość kodu jest wystarczająca do zwinnego programowania.

Nie możesz go dostosować tak, jak to opisujesz i nadal nazywasz to SCRUM. ale moim zdaniem możesz użyć Scruma w następujący sposób do opisanej konfiguracji.

1. Naprawiono iterację. Abyś mógł mierzyć swoje postępy. Nie służy to tylko kierownictwu, ale także zespołowi, aby „wiedzieć”, jak sobie radzą.
2. Poproś wolontariuszy o podzielenie się zdolnościami na początku iteracji. Cały zespół potrzebuje tego, co zobowiązują członkowie, w przeciwnym razie pewien członek może opuścić zespół do pracy wykonywanej bardziej profesjonalnie.
3. Brak terminu jest w porządku. Scrum nie wymusza jednak tego, że to, co robisz na końcu każdej iteracji, powinno być możliwe do wysyłki. Pozwoli ci to zdecydować, co dalej robić na podstawie tego, co zrobiłeś do tej pory (co działa).
4. Brak właściciela produktu również może działać. Możesz mieć jakiś system głosowania, który ustawia zaległości w rankingu i akceptuje / odrzuca wykonane prace.
5. Zbieranie wymagań nie jest częścią Scruma. Możesz to zrobić tak, jak chcesz. Ale nie uwzględniaj tego jako części zakresu iteracji. Mają do tego osobną pojemność. Dlatego w przypadku iteracji zaplanuj tylko te prace, dla których wymagania są jasne, np. Zespół zna kryteria akceptacji.
6. Retrospektywy są dobre. Więc zacznij Scrum jako taki, ale potem, korzystając z retrospekcji, zobacz, co działa, a co nie, np. Możesz potrzebować zmienić rozmiar iteracji, być może będziesz musiał pozbyć się niektórych wolontariuszy, którzy ciągną wszystkich innych ...
7. Codzienny status jest koniecznością. Daje to możliwość zsynchronizowania się zespołu, tzn. Dostosuje swoje wysiłki, aby żadne zadanie nie zostało niepotrzebnie zablokowane z powodu niedostępności produktu innego członka.
8. XP jest dobre. Mieć ścisłą definicję wykonaną na podstawie XP, np. Żaden kod nie wchodzi, chyba że zostanie sprawdzony. Rób mniej, aby więcej ...

Mogę zasugerować inne podejście. Ponieważ masz do czynienia z wolontariuszami, musisz rozważyć kilka kwestii. Twój zespół prawdopodobnie będzie miał duże obroty, życie stanie na przeszkodzie, a ludzie będą rozproszeni. Pozostałych kilku przyczyni się konsekwentnie, ale niezbyt dużo, a na koniec będziesz mieć grupę hardkorową, która naprawdę zatapia zęby w projekcie. Przyjmuję tutaj wiele założeń dotyczących twojej siły roboczej i jeśli uważasz, że moja ocena nie odzwierciedla osób, z którymi współpracujesz, możesz zignorować resztę tego.

Teraz potrzebujesz strategii, która pozwoli osobom, które nie wykonują dużo pracy, na samodzielną pracę, mają tylko tyle czasu na poświęcenie się temu i nie chcesz, aby spędzały większość tego czasu w komunikacji. Osoby bardziej zaangażowane powinny być odpowiedzialne za integrację i realizowanie niektórych bardziej złożonych pomysłów.

To prowadzi mnie do myślenia o procesie rozwoju bardziej skoncentrowanym na szkieletach i prototypach.

Możesz mieć dostęp do puli elementów pracy i zachęcać ludzi do pisania dla nich drucianych ramek. Możesz użyć ich jako Tracer Bullets (terminologia zapożyczona od programisty Pragmatic), aby dopracować pomysł i zapewnić inspirację dla ludzi, na których można budować. Stamtąd możesz przekształcić udane pomysły w prototypy, znowu są to bardzo małe projekty zaprojektowane, aby pomóc ludziom dowiedzieć się więcej o projektach. Potem masz teraz mniejszą część solidnych pomysłów, które zostały stworzone przez wiele osób, które możesz przekazać trochę bardziej aktywnemu zespołowi, który może pracować nad integracją tych pomysłów z twoim systemem.

Myślę, że Kanban lepiej pasowałby do tej sytuacji.

Scrum ma kilka rzeczy, które nie pasują. Pomiary czasu lub zakresu nie są konieczne, a każdy programista ma taką samą wizję produktu podczas spotkań. Odpowiedzialność i konsekwentne przestrzeganie krótkiego planu są celami biznesowymi.

Kanban oferuje wiele takich samych zalet jak Scrum bez jego wad. Może zapewnić szybkie prototypowanie. Protesty można uruchomić przed spotkaniami. Daje także TDD dla zmiennych kodów i testów regresji. Programowanie w parach może ułatwić początkującym i nieregularnym dostęp do bazy kodu poprzez transfer wiedzy.

Kanban ma również unikalne zalety. Jeśli wizja tego, co robią użytkownicy, jest rozwijana równolegle, Kanban działa dobrze. Dowodem na to jest sukces programów dla małych firm. Ponadto, w dniach z kilkoma wolontariuszami, takimi jak trzy osoby, Kanban nadal działałby dobrze. Scrum, mimo że jest lekki, stanowiłby za dużo żółtej taśmy.