Czy Agile jest do bani?

W swojej karierze miałem okazję pracować lub przyglądać się wielu różnym projektom o bardzo różnej skali trudności i wielkości. Od jedno lub dwuosobywych poprez małe zgrane kilkuosobowe zespoły aż do wielkich przedsięwzięć realizowanych przez dziesiątki programistów.  Ale tak naprawdę do napisania tego cyklu artykułów sprowokowała mnie publikacja na którymś portalu społecznościowym (bodajże linkedin) w której autor opisywał, że jest zmęczony Agile. W treści było jeszcze, że woli zorganizowany chaos jak nazwał sposób developmentu w małej grupie programistów bez ceremonii Agilowych

Czytaj dalej

Jak bezsensowne wymagania niszczą współpracę

Ostatnio spotkałem się z ciekawym problemem (zasłyszanym). Otóż PO sprecyzował wymagania do dosyć prostego mechanizmu po czym dołożył stopień komplikacji zmieniający proste krzesło w krzesło elektryczne. Przy czym nie chodzi tutaj o morderczą naturę tego drugiego tylko o stopień komplikacji rozwiązania. I teraz pytanie jak to ugryźć bo oczywiście na spotkaniu natychmiast pojawił się tajemniczy pomruk (i nie był to pomruk podziwu dla sprytu PO bynajmniej).

Czytaj dalej

Agile, Kanban, Scrum i inni

Trochę tym razem chciałbym podsumować moje własne poglądy na całość zbioru pod tytułem Agile. Wszyscy o tym wiedzą, ale dla własnego zsumowania wiedzy pokrótce chciałbym się podzielić moim aktualnym zdaniem na ten temat. Aktualnym, bo oczywiście poglądy ewoluują i niekoniecznie zgodzę się z samym sobą np. za rok czy dwa.

Agile jako całość – zaczynając od agile manifesto mówi o dopasowywaniu produktu do wymagań klientów i robieniu tego w trakcie tworzenia rozwiązań informatycznych. Czyli nic nie jest wyryte w kamieniu, jeśli na którymkolwiek etapie stwierdzimy, że coś jest nie tak, to nie brnijmy w to. Nie brnijmy tylko dlatego, że ktoś kiedyś wpisał to do projektu, planu, excel-a lub czegokolwiek innego. I w sumie chyba już na tym poziomie poważny zgrzyt. Bo niby to takie proste a chyba najtrudniejsze do zrozumienia – i do wdrożenia w życie.

Czytaj dalej

Scrum Master o technicznym rodowodzie

Przez wzgląd na różne zawirowania związane ze zmianą pracy trochę zaniedbałem bloga. Było to po części związane z moim aplikowaniem do Toptal i Crossover (o czym napiszę osobno), ale częściowo również związane z faktem „odkurzania” moich technicznych umiejętności – przed wszystkim Angular i WebAPI (o czym również stworzę osobne wpisy). W związku z poszukiwaniem pracy odbyłem kilka rozmów kwalifikacyjnych na Scrum Mastera, przeglądnąłem dziesiątki ogłoszeń i w trakcie tych rozmów pojawiły się ciekawe przemyślenia w tytułowym temacie.

Czytaj dalej

Podejście Waterfall raz jeszcze

W sumie poruszałem już ten temat we wpisie Agile vs Waterfall – jak przekonać zarząd i klienta, ale ponieważ znowu odbyła się ciekawa dyskusja na ten temat, to chciałbym jeszcze raz do tego wrócić może na bardziej konkretnym poziomie. Bo czasami zbyt wysoki poziom abstrakcji powoduje trudności w zrozumieniu tematu.

Początkiem dyskusji była opinia, że mimo wszystko czasami lepiej jest przygotować projekt z góry, opisać architekturę, wymogi itp. Takie podejście powinno pomóc uniknąć pułapek, które mogą pojawić się w trakcie tworzenia systemu, zaprojektować architekturę, przewidzieć technologię …

CC BY-NC-ND 2.0

Czytaj dalej

Szacowanie – story point i velocity

Chciałbym podsumować trochę wiedzę zdobytą w trakcie rozmów z trenerami Scrum na temat szacowania. Dyskusja z zespołami dostarczyły następnych ciekawych przemyśleń. A generalnie wiąże się to również z powszechnymi próbami przeliczania story pointów na dni robocze i odwrotnie. Wiadomo, że nie powinno się tak robić ale uzasadnienie i zrozumienie dlaczego jest trudniejsze.

Z punktu widzenia logiki jak i statystyki jest to jak najbardziej uzasadnione. Jeśli przeliczmy story pointy na dni to tak naprawdę przestajemy już estymować tylko dokonujemy wyceny czasochłonności. A estymaty służą do czegoś innego – ocenienia jak dużo pracy trzeba wykonać w konkretnym user story. Przecież warunki będą się zmieniać, istnieją urlopy, zwolnienia, może się zmieniać skład zespołu i tak można by wymieniać.

Czytaj dalej

Potyczki z Selenium część 2

W drugiej części wpisu chciałbym dodać trochę szczegółów technicznych, które pominąłem w pierwszej części (patrz Potyczki z Selenium część 1) dla przejrzystości. Więc zaprezentuję jak wyglądają niektóre pliki konfiguracyjne i skrypty, których używamy do resetowania testowych node’ów. Forma jest bardzo skondensowana ale mam nadzieję, że w połączeniu z pierwszą częścią nie powinno być problemów ze zrozumieniem.

Jeszcze tytułem wyjaśnienia – testy automatyczne wykonują się podczas uruchomiania procesu build-a na TFS, a resetowanie node’ów następuje przed wykonaniem testów jak i po ich zakończeniu. To dlatego, że lokalnie podczas uruchamiani testów również czasami używamy node’ów. Po wykonaniu paczki testów automatycznych wykonujemy również podczas nightly build-a przywrócenie bazy danych do pierwotnego stanu, aby system na środowiskach testowych był wyczyszczony z danych testowych produkowanych przez testy automatyczne.

Czytaj dalej

Potyczki z Selenium część 1

W tej odsłonie bloga chciałbym się podzielić doświadczeniami z uruchamianiem automatycznych testów. W kwestii technicznej używamy SpecFlow wraz z Selenium do tworzenia BDD i chcieliśmy dołączyć uruchamianie testów automatycznych do naszej ciągłej integracji. W części 1 opiszę naszą drogę do uzyskania środowiska wraz ze ślepymi uliczkami które sprawdziliśmy nie wnikając bardzo w techniczną stronę zagadnienia. W 2 części wpisu podzielę się również skryptami power shell i konfiguracją, której używamy finalnie.

W sumie początki wydawały się proste i obiecujące – choć nie bezbolesne. Na początku dało nam się we znaki stworzenie driver-a we frameworku do testów jako statycznej zmiennej. To bardzo szybko wywołało konieczność większego refactoring-u bo uniemożliwiało uruchamianie równoległe testów (wtedy jeszcze nie wiedzieliśmy, że temat równoległości zajmie nas na dłuższy czas).

Czytaj dalej

Software Developer a ropa naftowa

Bieżąca sytuacja na rynku IT skłoniła mnie do zastanowienia się nad przyszłością w branży. Jak jest obecnie – wszyscy wiemy. Firmy IT „zasysają muł z dna”. Brak dostępnych pracowników o wysokich kwalifikacjach powoduje niesamowitą konkurencję na rynku pracy. Kandydaci dostępni mają bardzo wysokie oczekiwania finansowe, więc często zatrudnia się osoby o niższych kwalifikacjach lub oferuje niebotyczne kontrakty, żeby ściągnąć pracowników do projektów. Z punktu widzenia firm – koszmar, z punktu widzenia pracowników IT – El Dorado. (Nie mylić z San Escobar!)

Czytaj dalej

Potyczki z SonarQube

W ramach podnoszenia jakości kodów zdecydowaliśmy się na uruchomienie SonarQube dla naszych projektów. Oczywiście początki okazały się trudne, bo jak każda nowość również statyczna analiza kodów na początku wydaje się być przeszkodą a nie pomocą. Jednak praktyka pokazuje, że była to bardzo dobra decyzja. Sporą ilość czasu poświęconą na konfigurację i wstępne wyczyszczenie kodu wynagradza z nawiązką wymuszanie dobrych standardów, jak również czasami wykrywanie błędów w kodzie. Chciałbym pokrótce opisać co uruchomiliśmy w naszym projekcie i jak osiągnęliśmy użyteczność narzędzia.

Czytaj dalej