O tym, dlaczego wolę metody zwinne

17 grudnia 2017 | Słowotok, czyli felietony, Zwinny tester

Przyznam szczerze, że chyba przeżywam kryzys pisarski, ewentualnie końcówka roku daje mi się mocno we znaki. W każdym razie pustkę mam straszną w głowie, zero pomysłów o czym pisać. A każde zdanie rodzi się w bólach.

Ale! Obiecałam że notka będzie, to słowa dotrzymuję. Jest to wpis zupełnie subiektywny, nie będzie tu nic o tym, że się opłaca, że szybciej się błędy znajduje, a już na pewno nie o tym, że metody agile są cool, jezzy, foxy i trendy. Bo to każdy wie, a nawet jak nie wie, to pewnie lada moment i tak się dowie. Będzie o tym, dlaczego wolę pracować w metodach zwinnych. A jako że wena postanowiła się udać na nieplanowany urlop, to będzie też krótko.

Był taki czas, że pracowałam w waterfallu. Był też taki czas, że pracowałam w czymś, co Jacek Walkiewicz nazwał: “pożar w burdelu – nikt nie wie o co chodzi. Trzeba biegać”. Ale na szczęście, sporą część kariery (może niezbyt imponującej, ale jednak!) przepracowałam w Scrumie bądź Kanbanie, bądź w Scumbanie. I tak pracuje mi się najlepiej. A dlaczego, dowiecie się z aż trzech poniższych punktów 🙂

Wymiana wiedzy w zespole

Zespoły scrumowe są interdyscyplinarne. W tych, w których ja pracowałam zwykle był przynajmniej jeden: front-endowiec, back-endowiec i tester/QA. Poza swoją pierwotną specjalizacją każdy ma też różną wiedzę z innych dziedzin czy narzędzi. I tak jeden doskonale zna GITa, ktoś inny ogarnia Jenkinsa, a jeszcze inna osoba wyszukuje nowinki technologiczne. Dzięki temu mamy zawsze pod ręką najwydajniejsze źródło wiedzy. Żeby tylko dać jeden przykład – niedawno spiesząc się przy rebase’owaniu coś mocno namieszałam 🙂 Zaczęłam googlować i okazało się, że problem wcale nie jest trywialny. Ale na szczęście był taki dla jednego z kolegów z zespołu. W kilka minut naprawił problem, powiedział mi co było nie tak. Dzięki temu zaoszczędziliśmy sporo czasu w sprincie (sama robiłabym to pewnie z 3 godziny, a przy tym ja urwałabym sobie palce, a mi ktoś głowę), a ja już więcej nie popełnię tego samego błędu. Dla porównania gdy pracowałam w zespole testerskim w projekcie kaskadowym na postawienie środowiska straciłam prawie dwa tygodnie. Tylko dlatego, że w tym czasie programiści, którzy mogli zrobić to od ręki, zajęci byli… programowaniem.

Stałe tempo pracy

To, co najgorzej wspominam z waterfalla to potworna nuda. Choćby nie wiem co, nie dało się tak zrobić, żeby praca była “just in time”. Coś, co miało planowo trafić do testów w listopadzie, pojawiło się dopiero w połowie grudnia. I fakt, sporo w tym czasie się nauczyłam. A że jeszcze wtedy studiowałam, to był to mój najlepszy semestr 🙂 Ale jednak wydaje mi się, że jeśli ktoś nie zatrudnia to nie po to, abym sama wymyślała sobie co robić. W scrumie są sprinty, więc nawet jeżeli wypadnie taki mniej pracowity, to już w następnym będziemy wiedzieli, żeby wziąć trochę więcej story pointów. Z kolei kanban, który z założenia został wymyślony po to, aby zmniejszyć przestoje zasobów (brr, paskudne słowo), wymusza jak najszybsze i najwydajniejsze dowożenie.

Szybka nauka na błędach (i sukcesach)

Dzięki regularnym retrospektywom o tym, co zrobiliśmy niezupełnie dobrze dowiadujemy się już po dwóch tygodniach, przy dłuższych sprintach po miesiącu. Możemy szybko nanosić zmiany na nasz proces i ulepszać go. A jeśli zmiana była nietrafiona – wrócić do stanu pierwotnego. Proces cały czas ewoluuje, dostosowuje się do zespołu i warunków. Pracując w projekcie waterfallowym wnioski przychodzą zwykle już po zakończeniu projektu. A do tego czasu i tak każdy zdąży zapomnieć co go bolało, a przypomni sobie o tym dopiero wraz z trwaniem nowego projektu. I tak często błędy są powielane.

Tych powodów jest znacznie, znacznie więcej. I pewnie wrócę jeszcze do tego tematu, żeby go rozwinąć. Jak tylko moja wena wróci na swoje miejsce 🙂

A wy wolicie metody zwinne czy kaskadowe?

Najnowsze wpisy

Czy testowanie jest dla każdego?

Do tego wpisu zainspirowała mnie dyskusja, jaka rozgorzała wokół gościnnego wpisu Marcina, który jakiś czas temu opublikowałam. Pytanie o to, czy testowanie oprogramowania jest dla każdego, pojawia się często w kończących się gorącymi wymianami zdań wątkach na grupie facebookowej Testowanie Oprogramowania.

KISS, czyli nie komplikuj, głuptasku

Łapka w górę, kto słyszał o regule KISS. Oczywiście nie mogę Was widzieć, ale wyobrażam sobie, że zgłosiłby się każdy, kto już dłuższy czas pracuje przy wytwarzaniu oprogramowania, a ten, kto pisze automaty i programuje już na sto procent.

“Mindset” to nie wszystko

Sporo czasu zabierałam się do tego, by napisać dzisiejszy wpis. I nie, wcale nie chodzi mi o to, że powinnam była go wrzucić wczoraj, ale o to, że trochę obawiam się wsadzania kija w mrowisko.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!