Wątek przeniesiony 2022-05-18 15:54 z Kariera przez somekind.

Awaria "na produkcji" w czasie sprintu

0

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)?

7

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

0

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.

2

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.

1

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ń

10

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.

0

Slowo na dzis: Backlog.

0

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.

0

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.

1
  • 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.

4

Zależy od firmy. Jedne robią oprogramowanie, drugie burndowncharty.

1 użytkowników online, w tym zalogowanych: 0, gości: 1