Jestem wielkim fanem zwinnego rozwoju i wykorzystałem XP w bardzo udanym projekcie kilka lat temu. Uwielbiałem wszystko, iteracyjne podejście do programowania, pisanie kodu wokół testu, programowanie w parach, posiadanie klienta na miejscu, przez który wszystko działa. Było to bardzo produktywne środowisko pracy i nigdy nie czułem się pod presją.
Jednak kilka ostatnich miejsc, w których pracowałem, używało / używałem Scruma. Wiem, że jest to obecnie dziecko plakatu do sprawnego rozwoju, ale nie jestem w 100% przekonany, że jest zwinny. Poniżej znajdują się dwa główne powody, dla których po prostu nie czuję się zwinny.
Kierownicy projektu to uwielbiają
Kierownicy projektów, którzy ze swojej natury mają obsesję na punkcie czasu, wszyscy wydają się kochać Scrum. Z mojego doświadczenia wynika, że wykorzystują dziennik sprintu jako narzędzie do śledzenia wymagań czasowych i prowadzenia rejestru ilości czasu poświęconego na dane zadanie. Zamiast używać tablicy wszyscy używają arkusza programu Excel, który każdy programista musi wypełnić religijnie.
Moim zdaniem jest to zdecydowanie za dużo śledzenia dokumentacji / czasu dla zwinnego procesu. Dlaczego miałbym marnować czas na szacowanie, jak długo zajmie mi zadanie, kiedy mogę po prostu zająć się samym zadaniem. Lub podobnie, dlaczego miałbym marnować czas na dokumentowanie, ile czasu zajęło zadanie, kiedy mogę przejść do następnego dostępnego zadania.
Spotkania standupowe
Spotkania standup w poprzednim miejscu, w którym pracowałem, były koszmarem. Codziennie musieliśmy wyjaśniać, co zrobiliśmy wczoraj i co zamierzamy zrobić tego dnia. Gdybyśmy przeszli do „oszacowania” czasu dla zadania, kierownik projektu wywołałby smród i odniósł się do rejestru sprintu jako sposobu pokazania, że jesteś niekompetentny za nieprzestrzeganie linii czasu.
Teraz rozumiem potrzebę komunikacji, ale z pewnością ton codziennych spotkań powinien być beztroski i koncentrować się na dzieleniu się wiedzą. Nie sądzę, że powinno to zmienić się w farsę w stylu pracy domowej. Z pewnością punktem zwrotnym zwinności jest zmiana osi czasu, nie należy ich ustawiać w kamieniu.
Wniosek
Ideą zwinności jest ulepszenie oprogramowania poprzez ułatwienie życia programistom. Dlatego moim zdaniem wszelkie zwinne procesy stosowane przez zespół powinny być prowadzone przez programistów. Nie sądzę, aby kierowanie projektem korzystało z procesu, który nazwali „zwinnym”, aby śledzić projekt, ma to coś wspólnego z zwinnym rozwojem.
Myśli ktoś?