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?

Podobał Ci się wpis? Podziel się ze znajomymi:


Najnowsze wpisy

Teoria vs. Praktyka

Kto z Was nigdy nie zastanawiał się nad tym, czy teoria jest do czegoś potrzebna, niech pierwszy rzuci we mnie „Testowaniem oprogramowania”.

CzytanQA: Trzy książki, bez których nie mogę się obejść

Książka Adama Romana pt. „Testowanie i jakość oprogramowania” jest jedną z trzech, których od długiego czasu nie odkładam nawet na półkę i do których zaglądam niemal codziennie.

Narzędzia, które ułatwiają mi (testerski) żywot

Stawiam, że każdy z Nas zna kilka takich aplikacji, które choć do testów czy programowania nie są zbyt potrzebne, to ułatwiają nam życie i które są jednymi z pierwszych instalowanych na świeżym systemie.