-
Nagranie o „best practices”
-
Andy jedzie czyli vlog
Jak widać na blogu nie pojawiają się ostatnio wpisy. Brak czasu. Ale znalazłem sposób jak przekazać to, o czym myślę: nagrywając filmiki. Poniżej dwa pierwsze. Miłego oglądania.
-
Czy Scrum Masterem trzeba się urodzić?
Czasem spotykam się z opinią, że Scrum Masterem to trzeba się urodzić, że właściwie nie można się tego nauczyć – można tylko rozwinąć już otrzymany dar. Oczywiście, jest w tym stwierdzeniu pewna doza (tzw. źdźbło) prawdy. Jak w każdej pracy konieczne są pewne predyspozycje – i jedni je mają w stopniu dużym, inni przeciętnym, a inni nie mają ich wcale i lepiej, żeby się daną dziedziną nie zajmowali. Niemniej bycie Scrum Masterem to praca jak większość innych, składająca się w przytłaczającej większości z rzeczy, których można się nauczyć. Dobrą analogią jest tutaj bycie kierowcą. Są ludzie, którzy z różnych powodów w ogóle nie powinni prowadzić samochodów – mają za wolną…
-
Gdy masz tylko młotek….
Pracując jako doradca i ekspert od metod zwinnych nieustannie spotykam się pewnym nieporozumieniem, które najkrócej streścić można w jednym zdaniu: „Agile to Scrum”. Innymi słowy polega ono na z gruntu błednym przekonaniu, że tak zwana „transformacja Agile” (czyli zmiana organizacji w nowoczesną, zwinną, sprawnie zarządzaną) polega na… wdrożeniu Scruma. Sprowadza to duży temat jakim jest Agile i w ogóle nowoczesne zarządzanie do jednej tylko metodyki pracy zespołowej, która choć bardzo dobra nie jest ani jedyną metodą Agile ani nie załatwia wszystkich problemów (zwłaszcza na skalę organizacji). Nieporozumienie to wydaje się dość niewinne – ot, typowe niezrozumienie tematu przez osoby, dla których jest nowy. Niestety, przekonanie, że „Agile == Scrum” jest…
-
Nigdy nie będzie dobrze
Postanowiłem się dziś podzielić obserwacją tak oczywistą, ale najwyraźniej nie na tyle by była ona powszechnym rozumieniem. Otóż: nigdy nie będzie dość szybkich zespołów developerskich. Dlaczego? Ano dlatego, że wymyślanie potrzeb oraz funkcji w oprogramowaniu, które mogłyby je zaspokajać jest bardzo szybkie. Sam pomysł to krótki błysk w duszy i przebieg impulsów po neuronach – jest! Eureka! Zapisanie go, ew. przedyskutowanie to kwestia godzin. Ale realizacja może trwać dni, tygodnie, miesiące nawet. Jeśli dodamy do tego dość typową sytuację, kiedy wymyślających (zwanych elegancko „interesariuszami”) jest istotnie więcej od implementujących widać wyraźnie, że jest niemożliwością doprowadzenie do sytuacji, w której każdy pomysł („wymaganie”) jest realizowane bez oczekiwania. Z tego właśnie powodu…
-
Kwestia perspektywy
Na jednym z ostatnich warsztatów zderzyłem się z pewnym problemem – uczestnicy zupełnie nie rozumieli po co komuś w biznesie jakieś oszacowania, a w szczególności informacja ile mniej-więcej będzie „to coś” kosztować. Przecież mamy Agile, się zrobi – się zobaczy. Dyskusja toczyła się przez jakiś czas, zanim do mnie dotarło, że problemem jest brak w życiu osób, z którymi rozmawiam, doświadczenia, do którego mogliby się odnieść. O jakie doświadczenie mi chodzi? O doświadczenie wydawania pieniędzy na produkt software-owy lub choćby jakieś jego funkcje. Najlepiej własnych pieniędzy we własnym biznesie albo przynajmniej powierzonego (i nietrywialnego) budżetu w firmie. Znajdując się w takiej sytuacji można podjąć trzy decyzje – wydać pieniądze na…
-
Lokalne optymalizacje
Na każdą organizację można spojrzeć jako na system, który przetwarza pewne sygnały wejściowe na jakieś produkty wyjściowe. W tym sensie organizacja jest zbiorem procesów, mniej lub bardziej powtarzalnych, w których przepływają pewne zlecenia. W przemyśle mają one charakter materialny, namacalny. W pracy intelektualnej (mylonej czasem z biurową) są najczęściej tylko pojęciami takimi jak pojedyncza sprawa, zlecenie, „ficzer” itp. Umownie możemy je nazwać „jednostkami pracy”. Tak patrząc na dowolną firmę o jej sprawności świadczą dwa najważniejsze parametry: przepustowość (liczba jednostek pracy w jednostce czasu, które firma przetwarza) oraz średni czas przetwarzania (czyli średni czas jaki upływa od rozpoczęcia do zakończenia pracy nad jednostką pracy – oczywiście patrząc z perspektywy odbiorcy). Efektywność…
-
Jak dobrze budować systemy rządowe?
Właśnie w ostatni weekend kolejny raz wyszły na jaw istotne niedociągnięcia w ważnym państwowym systemie informatycznym – okazało się, że system ePUAP (platforma przez którą obywatele mogą załatwić elektronicznie sprawy urzędowe) nie posiadał możliwości automatycznego przejęcia obsługi przez serwery zapasowe w razie awarii serwerów podstawowych. Wymagało to ręcznej pracy administratorów i w konsekwencji zajęło cały dzień jak ujawniła Minister Cyfryzacji. Więcej o sprawie można przeczytać na blogu Niebezpiecznik.pl. Czytając tą relację warto zwrócić uwagę na dwie rzeczy. Po pierwsze audyt tegoż systemu zamówiony przez nową Minister Cyfryzacji (którego fragmenty publikuje Niebezpiecznik.pl) koncentruje się na dokumentacji. Rzecz typowa dla audytorów, którzy najczęściej pochylają się właśnie nad szeroko rozumianymi „kwitami” co nie…
-
Moc etykiet
Dowiedziałem się ostatnio o dość zaskakujących badaniach, które dobitnie pokazują jaki wpływ na postrzeganie ma język. Mianowicie pewien badacz zauważył, że w starożytnych dziełach nie ma słowa na określenie koloru niebieskiego – a w szczególności nigdzie nie ma wzmianek o tym, by niebo miało jakiś szczególny kolor. Jest to jeszcze ciekawsze, jeśli połączymy to z badaniem pewnego współcześnie istniejącego w Afryce plemienia, które w swoim języku też słowa na określenie niebieskiego nie ma. Jak pokazały eksperymenty (polegające na pokazywaniu na ekranie kwadracików o różnych kolorach i proszeniu o ich rozróżnianie) ludzie z tego plemienia po prostu niebieskiego nie widzą – a ściślej nie rozróżniają od zielonego. Na tej podstawie postawiono…
-
Czemu programiści nie chcą testować?
Taka dość typowa historia: w pewnym zespole programiści nie chcą zajmować się testami. Ba, Scrum Master, który jednocześnie jest też programistą przygotował nawet specjalną prezentację na ten temat by opowiedzieć o tym innym Scrum Masterom. Wynikało z niej, że testować ogólnie nie warto, bo programista przecież wie, że to co zrobił działa, więc to dla niego jest stratą czasu a poza tym programiści są od programowania, testów nie lubią. zresztą testy to coś pośledniejszego i oni się źle czują taką gorszą pracę wykonując. Więc nie będą. Historię tą opowiedział mi niedawno zaprzyjaźniony Agile Coach z pytaniem dość oczywistym: co z takim przypadkiem robić? Oczywiście coś doradziłem (m.in. zasugerowałem szersze pochwalenie…