Temat: Agile a zarządzanie zmianą
@Łukasz
Jeśli takie sytuacje są częste, to restartowanie sprintu będzie bardzo frustrujące dla zespołu. Taką akcję można zrobić raz na rok, ale nie ciągle.
@Rafał
Cel istnienia sprintów niemodyfikowalnych pod względem zakresu pracy jest taki, żeby:
- zespół mógł spokojnie i równomiernie wykonywać swoją pracę, a więc dostarczać lepsze oprogramowanie
- zespół mógł dawać wiarygodne informacje co do tego na kiedy co jest w stanie dostarczyć (mierzenie prędkości), ale również sam wiedział "gdzie jest"
- budować zaufanie między zespołem a biznesem co do terminowości, jakości, pewności oprogramowania itp.
Robiąc niekontrolowane i nieoszacowane "wrzutki" zaburzacie rytm pracy zespołu (obniżając jego wydajność) oraz tracąc transparentność niszczycie statystyki służące mu do długoterminowego szacowania oraz budowania pewności i zaufania. Czyli podcinacie gałąź na której siedzicie.
Oczywiście bywają sytuacje, że inaczej nie można (np. oprogramowanie strasznie buggy, a spełniające krytyczne funkcje) i wtedy można albo zrestartować sprint (tak jak radził Łukasz) jeśli to jednorazowa operacja, albo założyć, że zespół zobowiązuje się do np. 10% mniej niż uważa że może i te 10% wykorzystuje na takie rzeczy - jako taki bufor. Jak nie ma nic do robienia, to zespół wykorzystuje ten czas do poprawiania jakości projektu - skoro macie potrzebę robienia takich rzeczy, to prawdopodobnie jest co poprawiać...
A jaką długość sprintu ma zespół? Może "po prostu" wystarczy skrócić sprinty i mieć pewność, że łatka zostanie dostarczona np. najpóźniej za tydzień. Zawsze najlepiej jest mieć takie rzeczy oszacowane i widoczne w statystykach, bo wtedy też można mierzyć ile czasu zespół poświęca na poprawki / wrzutki. To też bardzo ważna informacja z punktu widzenia planowania.
Paweł Lipiński edytował(a) ten post dnia 17.05.10 o godzinie 10:17
пропозиції роботи
