Jak koordynować czas programistów między dwoma różnymi projektami w Scrum?

40

Zostałem mistrzem scrum w nowo powstałym zespole, który jest odpowiedzialny za tworzenie oprogramowania ORAZ utrzymywanie innych wdrożonych aplikacji. Zasadniczo każdy członek zespołu ma zadania rozwojowe i operacyjne.

Obserwowałem ich działanie w ciągu ostatnich kilku tygodni i zauważyłem, że zespół ma problemy z koordynacją tych zadań. gdy programista koncentruje się na kodowaniu, zostaje mu przerwane, aby rozwiązać problem podniesiony w produkcji, i ciężko jest mu skoncentrować się na poprzednim zadaniu.

Próbowałem przeznaczyć% czasu programisty na prace operacyjne, ale najwyraźniej nie rozwiązuje to problemu. Chciałbym usłyszeć od mistrzów scrum, którzy wcześniej spotkali się z tą sytuacją, jak sobie z tym poradziłeś i jakie są twoje rekomendacje?

Shadin
źródło
1
Najpierw ustaw priorytet i usuń krytyczny błąd produkcyjny, a następnie wznów normalne projektowanie. Obie w tym samym czasie proszą o popełnienie błędu.
Mark Rogers,

Odpowiedzi:

60

Ten problem jest tak stary jak Scrum. Jest rozwiązanie, ale ci się nie spodoba.

  • Umieść nowe zadania w zaległościach.
  • Nie przeszkadzaj programistom.
  • Poczekaj na następny sprint.

Umieszczenie programistów w więcej niż jednym scrumie, posiadanie dwóch osobnych zaległości lub przydzielenie tylko procentu ich czasu do sprintu, wszystko działa przeciwko temu, co scrum próbuje osiągnąć, tj. Konsekwentnemu przepływowi ukończonych zadań.

Jeśli spróbujesz tego typu rzeczy, w zasadzie wrócisz do metodologii rozwoju „chaosu” lub „JFDI” ze wszystkimi towarzyszącymi temu problemami, np.

  • Deweloper ma do dyspozycji dziesięć zadań jednocześnie. Nikt nie wie nad czym pracują ani kiedy to się skończy.
  • Nieznany czas na zakończenie projektu, ponieważ zależy to od tego, jakie inne projekty dzieją się w tym samym czasie.
  • Brak spójnego poglądu na priorytet projektu. Inni menedżerowie kierują programistów do swoich domowych projektów.

Oczywiście zwykła odpowiedź na tę radę brzmi: „Ale nie mogę tego zrobić! Firma potrzebuje tych błędów produkcyjnych, aby jak najszybciej naprawić!”

Ale to nie jest tak naprawdę prawda.

Jeśli naprawdę masz tyle faktycznych błędów, które wpływają na działalność firmy w takim stopniu, musisz stać się profesjonalistą i poprawić swoje testy. Po prostu pracuj nad błędami i automatycznymi testami, dopóki nie naprawisz ich wszystkich. Zatrudnij zespół kontroli jakości i wypróbuj wszystkie nowe wersje.

Bardziej prawdopodobne jest jedno z poniższych:

  • Błędy to problemy operacyjne, brak miejsca na dysku, brak DR, brak kopii zapasowych, brak przełączania awaryjnego itp. Uzyskaj zespół OPS.

  • Błędy polegają na tym, że użytkownicy nie rozumieją, jak powinien działać system „To się stało! Czy to błąd?”. Uzyskaj pomoc i szkol użytkowników, pisz dokumentację.

  • Strach przed cofnięciem. Uruchomiłeś nową funkcję, która coś zepsuła, nie próbuj spieszyć się z naprawą. Przywróć poprzednią wersję i umieść błędy w zaległościach.

Ewan
źródło
5
jak długi jest twój sprint? Przejdę do jednego tygodnia
Ewan
3
Możesz uciec od nie przeprowadzania recenzji i retro, może robisz to raz w miesiącu. Projektowanie (projektowanie interfejsu?) Jako osobny zespół / sprint to dobry pomysł. Mam nadzieję, że przez większość czasu projekt jest wykonywany przed rozpoczęciem dev i nie zmienia się zbytnio
Ewan
3
Właściciel produktu chce, aby programiści porzucili wszystko i pracowali nad błędami produkcyjnymi, zatrzymali bieżący sprint, naprawili błąd i rozpoczęli kolejny sprint po zakończeniu. Takie decyzje mają konsekwencje, dzięki czemu właściciel produktu uświadomi sobie wpływ na natychmiastowe poprawki błędów. Będą musieli zachować większą dyskrecję, gdy sprawy będą uważane za nagłe. Możesz też poczekać i zająć się nimi podczas następnego wstawania. W ten sposób możesz zobaczyć, kto ma dodatkową przepustowość i nie zakłócać przepływu deweloperów.
JeffO,
5
Jeśli pominiesz recenzję i retro i projektujesz w osobnym sprincie, tak naprawdę nie ma już Scruma ...
Erik
6
Twoje rozwiązanie to: „zdobyć najwyższy autorytet w firmie, a następnie wydać dużo pieniędzy, tworząc trzy zupełnie nowe zespoły”?
Wyścigi lekkości z Monicą
25

Próbuję tutaj myśleć nieszablonowo.

Ponieważ może nie być możliwe, aby właściciel produktu zobaczył rzeczy po swojemu. Nadal mogą występować błędy krytyczne, które po prostu nie mogą się doczekać, spotykając się z klientami, w których potrzebna jest pomoc programisty itp., W których trzeba na chwilę usunąć jednego programistę ze sprintu.

Dlaczego nie spróbować tego przewidzieć i wykorzystać to dla własnej korzyści?

Będziesz potrzebować zespołu 5+, aby być może realistycznym.

Ale dlaczego nie wziąć jednego programisty na każdy sprint (obracanie się między programistami, każdy dostaje swoją kolej).

Ponieważ najprawdopodobniej nie ma wystarczającej liczby błędów, aby użyć pełnego programisty do poprawek, istnieją inne problemy lub zadania, które można wykonać.

  • Uruchamianie testów w celu zidentyfikowania wąskich gardeł wydajności lub problemów ze skalowalnością
  • Utrzymanie systemu kompilacji
  • Spotkania z klientami
  • Badanie nowych frameworków / bibliotek
  • Poznaj funkcje językowe, których chcesz użyć
  • Czytanie o kwestiach bezpieczeństwa
  • Utrzymanie bazy danych
  • Utrzymanie serwerów

Prędkość zespołu może wzrosnąć, stres może spaść, konflikty z zarządem mogą spaść, faktycznie masz czas na poprawę swojej wiedzy.

Zgięty
źródło
3
Myślałem o tym samym - obróć jednego programistę, aby wykonał „prace domowe” (problemy związane z produkcją), a ponieważ nie wykona on wiele prawdziwej pracy, pozwól mu również przeprowadzić badania / eksplorację / inne nieregularne rzeczy. I dobrze przeanalizuj przyczynę każdego problemu produkcyjnego, aby liczba ich spadła.
RemcoGerlich,
1
To naprawdę bardzo dobry pomysł! Będę musiał zatrudnić jeszcze jednego lub dwóch programistów, ale uważam, że warto. Wielkie dzięki!
Shadin
1
W naszym projekcie do pewnego stopnia sformalizowaliśmy to stanowisko. W każdym zespole mamy starszego programistę, który jest wyznaczony jako Lead Tech w zespole scrum. TL robi wiele rzeczy (mentorzy młodsi programiści, robią „plany 4 + 1” przed produkcją, rozwiązują problemy dla innych deweloperów, gdy tylko pojawią się itp.), Ale jedną z rzeczy, które są związane z byciem TL, są problemy z produkcją gorących ziemniaków i wady o wysokim priorytecie. Oczywiście, LOT zależy od twojego systemu produkcji / filozofii, ale TL może interweniować, aby „osłonić” resztę zespołu i pozwolić im skupić się na historiach użytkowników.
JBiggs,
14

Skuteczne rozwiązanie do zarządzania wysiłkami programistów w przypadku naprawdę istotnych problemów produkcyjnych, z których korzystałem, to „podejście Batmana”.

Kosztownym aspektem odpowiedzialności za wsparcie produkcji przy opracowywaniu nowej funkcjonalności jest przełączanie kontekstu, więc powinieneś dążyć do ograniczenia tego.

Przy zakupie zespołu utwórz listę członków zespołu i przejdź przez nią, aby każdego dnia nowa osoba była uznawana za „Batmana” na spotkaniu stojącym i odpowiadała na istotne problemy produkcyjne tego dnia. Pozostała część zespołu może pozostać skoncentrowana na rozwoju bez konieczności zmiany kontekstu i wszyscy mają spory udział w bólu wsparcia. Z zespołem 5 osób, to jeden dzień w tygodniu, w którym programista może zostać przerwany, i 4 dni nieprzerwanego, przewidywalnego czasu programowania.

Ma to tę zaletę, że wiedza / doświadczenie są dzielone między zespół, więc nie masz jednej osoby odpowiedzialnej za naprawianie konkretnych problemów i stawanie się pojedynczym punktem awarii i sprawiedliwym podziałem problemów wsparcia.

StuperUser
źródło
Bardzo ciekawe podejście i uważam, że ma ono zastosowanie w naszej sytuacji teraz! Wielkie dzięki!
Shadin,