Co się robi, jeśli w czasie sprintu pojawi się awaria na produkcji? Mamy sytuacje ze np jest dwuosobowy zespół programistów. Zespół robi jakiś sprint i nagle dostają informacje, że u użytkowników pojawił się jakiś błąd. Zakładam, że tu mogą pojawić się dwie ścieżki w zależności od rodzaju błędu. Jeśli bład jest tylko uciążliwy to pewnie ląduje w jakimś systemie zgłoszeń, a jak błąd pododuje, że użytownicy nie mogą pracować, to co się wtedy dzieje? Czy zespół przerywa sprint i zajmuje się naprawą błędu (czy w takim razie tworzy się nowy sprint którego celem jest usunięcie problemu)?
Metodologia jest po to żeby było lepiej a nie gorzej. Jak metodologia przeszkadza w pracy (a zakładanie, że przez czas jednego sprintu nic się nie zmienia jest idiotyczne) to po prostu ją olewasz.
Zaczynając od początku: po co mamy sprint? Żeby góra mogła sobie wybrać czy chce widzieć zaimplementowany ficzer A czy B na koniec sprintu, generalnie jakie są priorytety. Pojawił się nowy problem? Trzeba zapytać góry: chcecie dalej A czy może powinniśmy zająć się produkcją, bo klienci płaczą
Do tego: jest was dwóch. Jeśli projekt nie jest w super kondycji (super testy, idealny monitoring i tak dalej) to musicie planować jakieś 50% czasu albo więcej na maintenance, bo kto wie co się może stać. Biznesowi się to nie podoba? To trzeba zmienić metodykę na bardziej zwinną, skoro scrum nie daje pożądanej wydajności
Można mieć też w ramach sprintu wyznaczony czas na naprawę ewentualnych błędów.
Jeśli tak nie ma, to po pierwsze od razu widać jacy wymiatacze tam pracują, a po drugie, trzeba zapewne jakoś zadania przestawić, żeby zająć się tym co ważniejsze. Po naprawie wraca się do zaplanowanej pracy.
Skoro błąd jest na produkcji, to powinien się tym zająć zespół utrzymania (skoro zespoły wytwórcze/deweloperskie oddały ten kawałek kodu, przeszedł testy to nie powinno być w teorii nic do poprawy). No ale jak naprawa wymaga zmiany w kodzie, to się robi zmianę celu sprintu (replaning) i zajmuje problemem jak zwykłym zadaniem w sprincie. Tu pewnie kwestia premii/bonusów za dowiezienie zadań w sprincie jest kluczowa ;)
PS. oczywiście żartowałem, w dzień się pracuje nad rozwiązaniem problemu, a w nocy nad obecnymi zadaniami w sprincie.
Teoretycznie można przerwać sprint i zaplanować nowy. W praktyce nigdy tego nie widziałem. Najwyżej nie dowozi się tego co się zaplanowało i odwołuje się demo. Dodatkowym problemem jest to że bugi są ciężko estymowalne. Może zajmie dzień a może tydzień
Jeżeli błąd wymaga szybkiego naprawienia to się go naprawia i nie robi się sprintu.
Wtedy zwykle nie dowozi się sprintu ... i wiecie co sie wtedy dzieje?
Nic, absolutnie nic. Czasem przyjdzie policja scrumowa poszczekać.
A wiecie co naprawdę powinno się dziać jak zespół nie dowozi sprintu?
Nic, absolutnie nic.
Sprinty to zabawka dla sado managerów. Im szybciej to wykoleicie tym lepiej dla was i dla projektu. Sprinty/SCRUM w projekcie utrzymaniowym ( istotną część prac stanowi utrzymanie) to już wyższy poziom patologii.
Slowo na dzis: Backlog.
Tak na prawdę wszystko zamyka się jaki impact ma nie dowiezienie sprintu.
W przypadku gdy np zmiany muszą być wdrożone w tym samym czasie przez rozne zespoly to stopuje się aktualny sprint, komunikuje się to podmiotom zainteresowanym i one robią to samo. I po ugaszeniu pozaru robi sie od poczatku przeglad stanu taskow planowanie itd.
W przypadku jeśli tak jak wspomniał @jarekr000000 nie dowiezienie sprintu kończy się tym, że scrumpolicja musi oznaczyć zadanie jako flipover to nie robi się nic :P.
Jeżeli managementowi czy tam komuś zależy na sprintach, ich dowożeniu, a także na naprawianiu bugów, to po prostu tak te sprinty organizują, żeby był czas na naprawianie produkcji.
Tylko to jest znacznie szerszy obszar tzw. kultury w firmie, bo do tego trzeba mieć zarówno sensowne planowanie długo i krótkookresowe, jak i większą kulturę techniczną skutkującą tworzeniem softu lepszej jakości, tak że tych fakapów na produkcji zbyt wielu nie ma.
- Jak masz zaplanowany czas na Oncalla, maintenannce, Keep Stuff Running On etc. to robisz w ramach tego
- Jak da sie szybko naprawic, to po postu naprawiasz i tyle, najwyzej potem wspominasz ze byla taka sytuacja (zakladajac ze nie ma patoplanowania sprintu z dokladnoscia do 15 minut, wtedy zmiana firmy :P)
- jak wyglada na wieksza zabawe, robisz ticket w Jirze i niech sie osoby od priorytetyzowania roboty martwia co dalej. Bierzemy cos np. na 5 punktow, to te 5 punktow wypada gdzie indziej.
@jarekr000000: : przypomniales mi stare wesole czasy jak Scrum wchodzil. Zespol scrumowy liczyl 30 osob, nigdy nie bylo wiadomo ile potrwa standup (przewaznie 1 - 3h) polaczone z checia by estymowac co do 15 minut. A chwile pozniej wpadl projekt z calkowicie obcymi technologiami, bledami w designie (w koncu Scrum to taka nakladka na wielkiego sztywnego Waterfala), sprzecznymi wymaganiami lub ich brakiem + brakiem dostepu do osob decyzyjnych, co spowodowalo ze praktycznie zamiast w SP estymowalismy w iteracjach.
Zależy od firmy. Jedne robią oprogramowanie, drugie burndowncharty.