Przejdź do treści

Co tak naprawdę robi Scrum Master?

Na piętnastu stronach Scrum Guide’a – podstawowego dokumentu opisującego ten framework – roli Scrum Mastera poświęcona jest jedynie jedna strona. Na tej stronie znajdziemy kilkanaście punktów opisujących, w jaki sposób Scrum Master (albo pisząc krócej: SM) wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację oraz przeczytamy definicję, iż SM to „servant-leader” zespołu. Tylko tyle.

Osobiście mam poczucie, że wyobrażenie o sposobie działania SM wśród znanych mi deweloperów jest bardzo różne. Niektórzy wyobrażają sobie SM jako osobę, która organizuje spotkania, inni jako osobę która usuwa przeszkody z drogi zespołu, inni jako kierownika-bez-prawa-do-podpisywania-urlopów, jeszcze inni jako osobę, która chodzi i sprawdza czy wszystkie zadania są wpisane w odpowiednie miejsca. Te wyobrażenia często mocno bazują na tym, co usłyszeliśmy o roli SM albo na tym, jakich SM w swoim życiu spotkaliśmy. A bazowanie na wyobrażeniach może łatwo doprowadzić do nieporozumień…

Może więc warto poświęcić kilka akapitów na przybliżenie tej roli?Czytaj dalej »Co tak naprawdę robi Scrum Master?

Jak to się robi w Story Point’ach

Jeżeli używamy tradycyjnych metod rozwoju oprogramowania, najczęstszą jednostką szacowania pracy jest osobodzień, osobogodzina czy osobomiesiąc. Przy szacowaniu jakichś zmian czy projektów możemy usłyszeć: „ta zmiana to trzy dni pracy” lub „ten projekt to pięć miesięcy pracy dla jednej osoby”.

Jeżeli wprowadzamy w organizacji metody zwinne, to prędzej czy później zjawia się jakiś TrueAdżajMaster, który mówi: „proszę państwa, osobodni są już passe, to jest przestarzały waterfall, prehistoria i epoka kamienia łupanego, prawdziwy AdżajDeweloper szacuje wyłącznie w Story Pointach!”Czytaj dalej »Jak to się robi w Story Point’ach

Szewc bez butów chodzi, czyli coś o narzędziach w IT

szewc_bez_butow_r0Firmy z branży IT, szczególnie w momencie szybkiego wzrostu z małego przedsiębiorstwa do korporacji, stoją przed wyzwaniem i pytaniem: “jak efektywnie zorganizować pracę?”.

Przy gwałtownym wzroście nieformalne metody współpracy i posługiwanie się skrzynką pocztową do zlecenia zadań przestają działać. Rozwiązaniem jest wprowadzenie narzędzi wspierających.
Czytaj dalej »Szewc bez butów chodzi, czyli coś o narzędziach w IT

Kontrakt świadczenia usługi

Historia pewnego kontraktu

horse

Rys. Jaki koń jest każdy widzi

Wyobraź sobie, że wdrażasz system CRM w dużej firmie telekomunikacyjnej. Jesteś na spotkaniu z klientem omawiając wymagania do modułu zarządzania kontem. Klient chciałby, żeby pod informacjami dotyczącymi konta była możliwość łatwego przeglądania listy faktur wraz z kwotą do zapłaty i datą wystawienia faktury. Dodatkowo widok listy faktur powinien umożliwiać otwarcie dokumentu faktury.

Czytaj dalej »Kontrakt świadczenia usługi

Mitologia rekrutacji programistów

Mainpage_Slider_Greek_Mythology_GodsChoć jest przynajmniej kilka znanych i całkiem dobrych tekstów nt. rekrutacji programistów (kilka linków podałem niżej), postanowiłem podzielić się swoim – bardzo subiektywnym – doświadczeniem w tej dziedzinie. Niniejszy tekst piszę z perspektywy osoby, która rekrutuje programistów, jednak spostrzeżenia i porady pomocne mogą być zarówno dla innych rekruterów jak i kandydatów do pracy. Swoje przemyślenia zebrałem w formie kilku “mitów”, które udało mi się gdzieś usłyszeć lub przeczytać. Nazywam się je mitami głównie dlatego, że w całości lub przynajmniej częściowo się z nimi nie zgadzam… i staram się niżej wyjaśnić dlaczego. Dodatkowo chciałbym uprzedzić – tekst dotyczy weryfikacji zdolności, umiejętności i wiedzy technicznej – a nie całokształtu znajdowania idealnych pracowników do danego zespołu. Nie aspiruję do tego aby być ekspertem od psychologii, HR czy zaawansowanego managementu. Interesuje mnie głównie to, aby ludzie techniczni – programiści i architekci, mieli możliwość dobierania sobie współpracowników poprzez udział w rekrutacji i żeby robili to kierując się sensownymi kryteriami.

Czytaj dalej »Mitologia rekrutacji programistów

Badając zwinność

agilecatW kwietniu i maju bieżącego roku BPM Laboratory uniwersytetu w Koblenz przeprowadziło badanie zatytułowane Status Quo Agile. Celem badania było zebranie doświadczeń różnych organizacji w zakresie wykorzystania zwinnych metod zarządzania projektami. W ankiecie wzięło udział ponad 600 respondentów, a opracowanie jej wyników można pobrać ze strony http://www.status–quo–agile.net/.

Dlaczego to badanie jest ciekawe? Dlatego, że mówiąc o zwinności w organizacjach, zazwyczaj wypowiadamy się na temat kilku-kilkunastu projektów, które dane nam było prowadzić czy zobaczyć. Tutaj zaś mamy zebrane z opinie z wielu różnych firm i organizacji.

Celem tego artykułu nie jest streszczanie 142-stronicowego raportu lecz wybranie z niego kilku fragmentów, które wydają mi się najciekawsze.Czytaj dalej »Badając zwinność

Od menedżera do właściciela produktu

darth_vader_product_ownerDzień był szary, deszczowy i mglisty. Wystarczyłaby chwila spojrzenia na zasłonięty mgłą świat, aby zadumać się nad jesienią, przemijaniem i sensem… Na szczęście nikt w wielkim budynku biurowca nie miał czasu na patrzenie za okno – klimatyzacja utrzymywała stałą temperaturę 22 stopni Celsjusza, grube szyby broniły przed deszczem, a ludzie wpatrzeni byli w niebieskie ekrany monitorów, które wyświetlały raporty, maile, kody oraz – od czasu do czasu – zdjęcia małych kotków.

Do pokoju Stefana, młodego i zdolnego menedżera projektu, wszedł dyrektor działu rozwoju oprogramowania, przysunął sobie krzesło, usiadł na nim i powiedział tak:

– Słuchaj, jest taka sprawa. Centrala chce bardzo, żebyśmy byli adżajl i żebyśmy teraz projekty robili w skramie. Wybraliśmy twój projekt jako pilotaż, bo kiedyś mówiłeś, że coś o tym słyszałeś. Także zróbcie szybko tego skrama, wprowadźcie te biegi czy sprinty. Oczywiście cała zmiana nie może mieć wpływu na budżet – jest już ustalony z klientem, terminy są napięte, także nie możemy już niczego przesuwać. Tak za miesiąc potrzebuję prezentacji, która podsumowuje zalety skrama, będzie to rekomendacja dla pozostałych projektów.Czytaj dalej »Od menedżera do właściciela produktu

Dlaczego Scrum nie działa?

Scrum FailPewien zespół programistów postanowił wdrożyć w swojej pracy framework Scrum. Jedna z osób w tym zespole przeczytała książeczkę pod tytułem Scrum Guide i opowiedziała innym jak ten cały Scrum wygląda – opowiedziała o tym, że są sprinty, że ostatnio cały świat tak robi, że będą bardziej efektywni oraz że w ogóle będzie miło i przyjemnie.

Zabrano się do pracy. Ustalono role – Franek został Właścicielem Produktu, zaś Marek został Scrum Masterem. Ustalono, gdzie będzie trzymany backlog oraz nauczono się, że gotowe zmiany w kodzie od teraz nazywają się inkrementem. Ustalono długość sprintu, w kalendarzach pojawiły się nowe spotkania pod tytułem planowanie sprintu, codzienny scrum, przegląd oraz retrospektywa. Wszystko zaczęło się toczyć, właściciel produktu priorytetyzował zadania w backlogu, backlog produktu zmieniał się w backlog sprintu, backlog sprintu zmieniał się w inkrement, a wykresy spalania poruszały się to w górę, to w dół.

Wszystko miało być pięknie. Jednakże po pewnym czasie członkowie zespołu doszli do wniosku, że w zasadzie nic się nie zmieniło. Zadania są takie same, jakość dostarczanego produktu w zasadzie cały czas pozostawia sporo do życzenia, a odbiorca cały czas jest tak samo niezadowolony. I w zasadzie to po co nam ten cały Scrum, więcej z niego kłopotu niż pożytku…Czytaj dalej »Dlaczego Scrum nie działa?