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 →

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 →

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 →

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ę …

Czytaj dalej →

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 →

Pytanie niby absurdalne ale właściwie niektóre dyskusje skłaniają mnie do pochylenia się nad tym tematem. Otóż kiedy remontujemy mieszkanie i zapraszamy fachowców do wykonania usługi to zwykle dyskutujemy zakres prac i przedstawiamy nasze wyobrażenia na temat tego co chcemy uzyskać. Wtedy czasami (pomijam scenariusze typu nieuczciwy/leniwy fachowiec) możemy usłyszeć sugestie typu „w tym miejscu będzie to niewygodne” albo „to będzie dużo kosztować” itp.

Czytaj dalej →

Tym razem chciałbym się pochylić nad tematem Scrum Master kontra Team Leader. W Scrum wiadomo jak jest – nie da rady. Nie da rady, bo Scrum Master ma być głównie rolą wspomagającą zespół i jego podstawowym zadaniem jest wspomaganie samoorganizacji zespołu. Team Leader to gość, którego głównym celem jest rozdzielanie zadań, pilnowanie postępu, projektowanie, narzucanie terminów i inne ładne funkcje. Czyli widać, nijak się nie klei.

Czytaj dalej →

W tej odsłonie bloga chciałbym zająć się tematem backlog-u a konkretnie elementów backlog-u. Jest wiele opracowań mówiących o elementach backlog-u ale trochę gorzej z praktycznymi poradami jak sobie radzić i wykrywać problemy. Pominę tu oczywiste aspekty opisane w Scrum Guide jak to, że elementy backlog-u powinny być czytelne, ułożone w celu maksymalizacji wartości itp. Również problemem w pisaniu ogólnych wskazówek jest fakt, że każdy produkt, zespół i właściciel produktu jest inny więc stworzenie ogólnego przewodnika jest niemożliwe. Więc chciałem tylko wrzucić kilka porad z mojej praktyki co jest sygnałem, że backlog można byłoby poprawić.

Czytaj dalej →

W pierwszej odsłonie mojego bloga chciałbym dotknąć jednego z bardziej istotnych i nurtujących wszystkich tematów, czyli jak przekonać zarząd lub klienta do podejścia Agile. Inspiracją do tego artykułu jest argumentacja, której sam użyłem wobec zarządu oraz interesująca dyskusja, jaką miałem podczas konferencji Agile Update.

Czytaj dalej →