Bieżączka
- Przewlekła choroba, która wyczerpuje organizm Zespołu Developerskiego niestrawnościami pochodzącymi ze środowiska produkcyjnego.

Objawy bieżączki

syzyf-mleczkoTrochę podobnym problemem do wcześniej omówionych wrzódek, jest bieżączka. Przewlekła choroba, która wyczerpuje organizm Zespołu Developerskiego niestrawnościami na produkcji. W praktyce to oznacza, że Zespół Developerski w każdym Sprincie równocześnie zajmuje się rozwojem nowych funkcjonalności produktu jak i utrzymaniem produkcji. Czy utrzymanie produktu w tym samym zespole jest niezwykłe lub niepożądane? Niekoniecznie. Nie ma dobrego powodu, dla którego miało by tak nie być. Sytuacja, w której inny zespół zajmuje się utrzymaniem i naprawianiem tego, co Zespół Developerski wytworzył, może prowadzić do dysfunkcji. Na przykład bardzo szybko dochodzi do braku przejmowania się tym czy system jest stabilny lub wysokiej jakości. Jak to Anglicy mówią, trzeba tylko przerzucić świnię przez mur, a to, że połamie sobie nogi, to już nie nasz problem. Poza tym Product Owner jest odpowiedzialny za Całkowity Koszt Posiadania (ang. Total Cost of Ownership), więc tak czy inaczej powinien ponosić również koszty utrzymania. Z resztą mamy całą filozofię DevOps, która ma na celu zbliżenie, jeśli nie pełne połączenie zespołów developerskich i utrzymaniowych w dużych organizacjach. Można mierzyć w czasie Innovation Rate jako stosunek pracy rozwojowej do utrzymaniowej, żeby zobrazować co się dzieje. Także podsumowując taka sytuacja może mieć miejsce. Problem robi się dopiero wtedy, kiedy ilość pracy związanej z utrzymaniem jest duża. Moim zdaniem następuje to, kiedy ilość pracy deweloperskiej taka sama lub większa jak praca rozwojowa. Oczywiście problem jaki pojawi się tutaj dla Zespołów Developerskich to trudność zaplanowania Sprintów. Jeśli nie wiadomo dokładnie ile problemów pojawi się na produkcji w trakcie Sprintu, to cieżko przewidzieć co realnie uda się ukończyć.

Leczenie bieżączki

Znam dwa sprawdzone sposoby radzenia sobie z tym problemem. Pierwszy polega na uwzględnienie stałego bufora w capacity zespołu na utrzymanie, np 30%. Jeśli pracy utrzymaniowej jest mniej, to Zespół Developerski pracuje nad zawartością Sprintu. Drugi sposób to poświęcenie jednego członka Zespołu Developerskiego do pracy utrzymaniowej i nie liczenie go w capacity Zespołu Developerskiego na planowaniu. Kiedy pojawia się zadanie związane z utrzymaniem, to pracuje wyznaczona osoba. Kiedy nie pojawia się taka praca, to ta osoba pracuje w Sprincie tak samo jak reszta Zespołu Developerskiego. Dobrą praktyką jest rotowanie tej roli w Zespole, żeby nie doszło do sytuacji, że zawsze jedna osoba sprząta. Dobrze jest też wyraźnie zasygnalizować kto jest wyznaczony w tym Sprincie przez odpowiedni token taki jak maskotka na biurku, koszulka itp.
Oprócz leczenia symptomów i ograniczania szkód warto zastanowić się nad leczeniem przyczyn. Zwykle przyczyną będzie dług techniczny, albo słabej jakości wymagania.

W kolejnym poście dowiesz się jak wygląda późna cofka